Seguridad de Node.js: lecciones del Grupo de Trabajo de Seguridad de Node.js sobre la clasificación de vulnerabilidades

En una publicación anterior del blog, hablé sobre una divulgación de seguridad del framework Fastify de Node.js al Grupo de Trabajo de Seguridad de Node.js en HackerOne. La divulgación se refería a una vulnerabilidad de inyección de código JavaScript del lado del servidor. La conclusión final fue que el informe no tenía impacto en la seguridad del framework de aplicaciones web Fastify de Node.js ni de su componente de validación de esquemas JSON fast-json-stringify.

¿Por qué un informe de seguridad no se clasificaría como tal?

Para responder a esa pregunta, revisemos rápidamente los hallazgos del informe e identifiquemos algunos de los desafíos que planteó para el equipo de respuesta a incidentes del Grupo de Trabajo de Seguridad de Node.js.

El informe de seguridad describía un ataque de inyección de código que se produce cuando un atacante puede manipular un archivo JSON utilizado como esquema para la lógica de validación de solicitudes. Además, incluía una prueba de concepto que confirmaba el problema de seguridad al iniciar una shell inversa.

Sin embargo, esto no resultó ser un problema de seguridad en Fastify por sí solo, como señaló desde el principio uno de los mantenedores de Fastify: esta vulnerabilidad de seguridad no se produce de forma dinámica ni se debe a un error de seguridad en el código del propio framework. El problema solo ocurre cuando se usa código no confiable como esquema de validación JSON, que suele ser escrito por los propios desarrolladores y no se obtiene de la entrada del usuario.

Este informe de vulnerabilidad destaca varios desafíos que enfrentamos en el Grupo de Trabajo de Seguridad de Node.js como analistas de seguridad que deben responder a incidentes de seguridad:

1. determinar si un informe es aplicable y si corresponde considerarlo un error de seguridad

2. determinar el origen de una vulnerabilidad

Problemas de seguridad de Node.js en zonas grises

Al revisar rápidamente el informe, parece que el problema de seguridad divulgado es un error de seguridad válido. Al fin y al cabo, se proporcionó una prueba de concepto y se confirmó que el escenario de ataque podía reproducirse con el componente mencionado.

Dicho esto, es necesario analizarlo detenidamente para comprender no solo el vector de ataque y los detalles de la vulnerabilidad, sino también el uso previsto del componente vulnerable. En el caso de Fastify, la biblioteca impide deliberadamente el análisis dinámico del esquema JSON que recibe para validar solicitudes, con el fin de mitigar ataques de inyección de código durante la ejecución.

Sin embargo, los desarrolladores aún pueden usar un esquema de análisis JSON que contenga código malicioso, como el que se incluye en la prueba de concepto. Pero ¿se trata realmente de una vulnerabilidad de seguridad?

Aquí es donde la situación se vuelve incierta. El equipo de Fastify ha explicado claramente en la documentación del proyecto las consideraciones de seguridad: la entrada de configuración del esquema JSON debe tratarse como una fuente confiable. Ahora, la responsabilidad recae en el desarrollador y en el equipo que usa esta biblioteca, quienes deben garantizar que la entrada sea confiable.

¿Dónde está la vulnerabilidad de seguridad de Node.js?

Otro desafío que suele pasar desapercibido es determinar el origen de una vulnerabilidad de seguridad. En este informe, por ejemplo, quedaba claro que había dos componentes en cuestión: tanto el framework web de Node.js fastify como la biblioteca de análisis JSON fast-json-stingify. ¿Cuál de los dos debería clasificarse y tratarse como el componente vulnerable en este caso?

Por un lado, fastify es simplemente un componente que usa otro componente para analizar el esquema JSON. Por otro lado, fast-json-stringify no declara que tenga como objetivo protegerse de cualquier tipo de entrada y deja esta responsabilidad en manos del usuario.

Este desafío se entiende mejor con un informe de seguridad anterior que recibimos como ejemplo. En ese caso, se descubrió una vulnerabilidad de cross-site scripting (XSS) en una aplicación que muestra archivos de hojas de cálculo de Excel como contenido HTML y que usa un componente de terceros para analizar los datos de las hojas de cálculo. La vulnerabilidad XSS afecta a la propia aplicación, que no limpia los datos de salida antes de mostrarlos en una página HTML. La vulnerabilidad no está relacionada con el componente de terceros, porque este no puede saber de antemano si los datos de entrada se usarán en un contexto de salida HTML o, quizás, en un archivo CSV sin formato. Por lo tanto, esta clase de vulnerabilidad de seguridad no está relacionada con el alcance de la biblioteca que analiza las hojas de cálculo de Excel.

Resumen

La clasificación de vulnerabilidades de seguridad requiere mucho contexto y experiencia. Además, la conversación entre el investigador de seguridad y el mantenedor del componente vulnerable es fundamental para entender el contexto en el que puede explotarse la vulnerabilidad.

Otro desafío es asignar correctamente las puntuaciones de las vulnerabilidades de seguridad, también conocidas como Common Vulnerability Scoring System (CVSS). Si te interesa saber más sobre este tema para ayudarte a clasificar vulnerabilidades de seguridad de Node.js, anteriormente escribí sobre los desafíos del CVSS y algunos consejos para hacerlo bien.