Fortify360 - Fregaderos y fuentes - Recuento de vulnerabilidad

Casi siempre lo afirmaría como una vulnerabilidad que se muestra en 300 lugares, especialmente si se trata de un informe más amplio en el que puede haber 50, 100 o más vulnerabilidades; de lo contrario, obtendrás un informe tan extenso como un libro. en el que nadie puede actuar.

Piénselo desde el lado de la audiencia: querrán saber su exposición al riesgo y qué pueden hacer al respecto. Su acción será asignar a un individuo o equipo para hacer la corrección, por lo que prefieren que se les diga que hay un problema que deben resolver: las 300 instancias en las que surge pueden hacer que sea una prioridad más alta para ellos que una vulnerabilidad con una instancia visible, pero la solución puede ser la misma.

Reitero la respuesta de AviD: la creación de secuencias de comandos entre sitios generalmente se resuelve mejor como un problema de codificación de salida sensible al contexto, en lugar de un problema de validación de entrada. Si está tratando de resolverlo como un problema de validación de entrada, en muchos casos alentará un enfoque de validación de entrada de lista negra, o si está usando un enfoque de lista blanca, es posible que no pueda obtenerlos como estrechamente apretado como quieras.

Además, lo que necesitará manejar para cada contexto de codificación de salida (HTML, atributos, CSS, JavaScript) será diferente, por lo que le aconsejo que dirija al equipo de desarrollo a algo que haga la codificación para ellos como la de Microsoft. WPL (Biblioteca de protección web) o OWASP ESAPI u OWASP Reform para otros idiomas.

Mi preferencia personal (y tenga en cuenta que trabajo para un proveedor, IBM, pero es mi opinión) es que el método de informe óptimo para la remediación es proporcionar el origen y el sumidero.

Yo diría que este es particularmente el caso en el marco .NET donde diferentes controles de salida (sumideros) codifican los datos que se les pasan de manera diferente y los diferentes controles de entrada (fuentes) no siempre descodifican los datos de su forma codificada en url.

Con Java, por lo general, no se ve tanta variabilidad, sin embargo, creo que aún debe tener en cuenta tanto la fuente como el sumidero antes de decidir una solución óptima.

En mi opinión, importa y no importa dónde se encuentra el XSS y cómo se puede utilizar.

No importa porque cualquier XSS es hasta cierto punto peligroso.

No importa porque un XSS en una URI y una estructura de parámetros de apariencia inocua está destinado a conducir a más phishing. En muchos sentidos (desde una perspectiva de atacante), es mejor tener un XSS disponible en una página que esté disponible para visitantes / usuarios autenticados y no autenticados de una aplicación o infraestructura.

Cuando expresas esto de manera diferente como SQLi en lugar de XSS, la situación se vuelve mucho más relevante y fácil de entender. Cada instancia de SQLi podría convertirse en un ejercicio de explotabilidad. El SQLi ciego a menudo es más difícil de explotar, pero no importa: la clave real es qué datos o accesos no autorizados han sido expuestos por cada falla SQLi individual. CVSS y DREAD vienen a la mente, pero en realidad esto debería optimizarse aún más como CWSS y STRIDE.

Entonces, para responder a su pregunta, la determinación debe ser un ejercicio en la gestión de riesgos de Appsec. Probablemente habrá en algún lugar más de 1 e incluso menos de 300 hallazgos individuales por categoría de vulnerabilidad. Prefiero hablar de ellos como debilidades de software, pero esto puede variar dependiendo de su público objetivo. La personalización para su público objetivo siempre es importante cuando se presenta información, especialmente en los esfuerzos de redacción de informes.

Nuevamente, si la lista de la fuente o el sumidero (o ambos) depende o no de la audiencia objetivo. Si estuviera recibiendo el informe, me gustaría ver las dos, pero eso es porque soy un asesor técnico profundo de las aplicaciones. El sumidero es más útil para la mayoría de los desarrolladores, y puede permitirles centrarse en el problema de la causa raíz, es decir, la codificación (en el caso de XSS y SQLi). Sin embargo, puede haber otras soluciones y defensa en profundidad. estrategias para presentar a los desarrolladores, así como a los administradores de bases de datos, administradores de sistemas, administradores y cualquier otra persona involucrada en los ciclos de vida de la aplicación y el sistema.

Entonces, mi respuesta es que esta respuesta depende en gran medida de miles o millones de otros factores.

La respuesta es: depende.

Una disciplina de diseño es considerar que todos los datos de la base de datos no son fiables y están desinfectados, de modo que es responsabilidad del código que está generando HTML para codificar o escapar de forma adecuada antes de incluirlo en la salida HTML. Si ese es el enfoque que ha tomado su proyecto, entonces esto es 300 errores. Esta es una forma bastante común de estructurar una aplicación web.

Otra disciplina de diseño es sanear todos los datos antes de almacenarlos en la base de datos, para que sepamos que los datos almacenados en la base de datos son seguros para la salida en todos los contextos HTML plausibles (HTML, atributos, CSS, Javascript). Si esta es la disciplina que sus programadores están siguiendo, entonces lo que quiere saber es si hay algún lugar en el código que almacene datos en la base de datos sin primero codificarlos / escaparlos / desinfectarlos adecuadamente. En este caso, es posible que tenga un error o puede tener muchos errores.

Una disciplina de diseño más general es tener un invariante diferente para cada campo en la base de datos: algunos de ellos han sido pre-saneados antes de almacenarlos en la base de datos (y quizás para diferentes contextos: por ejemplo, un campo puede contener pre-escapado o HTML de confianza, otra podría contener una cadena pre-escapada adecuada para su inclusión en Javascript), y algunas no tienen y tendrán que ser eliminadas / saneadas en el lado de la salida. En este caso, deberá observar qué invariante mantiene el programa en relación con el campo en particular en la base de datos que está asociada con las vulnerabilidades XSS que encontró.

Un cuarto enfoque, y probablemente el más común, es no tener ninguna disciplina. Esta es una mala noticia para la seguridad.

Entonces, creo que empezaría por tratar de entender si los desarrolladores del software han adoptado alguna estrategia sistemática para defenderse contra XSS. Si no han adoptado ninguna estrategia sistemática, existe el problema de raíz (puede informar algunos errores, pero son un síntoma de un problema más grave y fundamental: la falta de una defensa disciplinada contra XSS). Si han adoptado una estrategia sistemática, una vez que hayas descubierto cuál fue esa estrategia y cuáles fueron las invariantes previstas, estarás en una mejor posición para escribir informes de errores útiles.

Creo que la pregunta no es si se trata de 300 sumideros o 1 fuente, sino que es que eres vulnerable y debes solucionarlo. Entonces, en lugar de acudir a su cliente para justificar que tenemos una exposición a 300 XSS o 1 vulnerabilidad, debe solucionarlo y no tener ninguna vulnerabilidad. Esa debería ser la postura de un ingeniero de seguridad.