it-swarm-es.com

Fortify 360 - Sumideros y fuentes - Recuento de vulnerabilidades

En un entorno de seguridad de aplicaciones, uso Fortify360 de Fortify Software a diario.

Uno de mis mayores obstáculos es explicar los números (fuentes vs sumideros)

Fortify marca cada ubicación en el código fuente donde los datos no validados se muestran a un usuario como una vulnerabilidad de Cross-Site Scripting.

Supongamos que hay 300 ubicaciones (sumideros) donde se muestran al usuario datos no validados. De esos 300 receptores, TODOS los datos se extraen de una base de datos que utiliza una función. (fuente)

Fortify informará posteriormente que hay 300 vulnerabilidades de Cross-Site Scripting. Lo que no le dice explícitamente es que 300 de los cuales potencialmente pueden repararse desde la misma ubicación.

Mi pregunta para usted, desde el punto de vista de un ingeniero de seguridad de aplicaciones, ¿luego informa a su cliente que hay 300 vulnerabilidades de Cross-Site Scripting o 1 vulnerabilidad de Cross-Site Scripting? ¿Alguna de esas declaraciones es precisa?

¿Reporta la fuente o el sumidero?

Lo que estoy haciendo actualmente es informar que hay 300 vulnerabilidades POTENCIALES de Cross-Site Scripting que pueden corregirse dentro de una función/método.

¿Es más exacto decir que hay una vulnerabilidad de secuencia de comandos entre sitios que está expuesta en 300 ubicaciones?

Me doy cuenta de que algo de esto es subjetivo, pero estoy buscando información de otros en el campo que puedan arrojar algo de luz sobre sus métodos.

8
Purge

Casi siempre afirmaría esto como una vulnerabilidad que se muestra en 300 lugares, especialmente si esto era parte de un informe más amplio donde puede haber 50, 100 o más vulnerabilidades; de lo contrario, terminas con un informe tan grueso como un libro que no- uno puede seguir adelante.

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 una persona o equipo para que haga la solución, por lo que prefieren que les digan que hay un problema que deben solucionar: 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 remediación puede ser la misma.

3
Rory Alsop

Reitero la respuesta de AviD: Cross Site Scripting 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, alentará un enfoque de validación de entrada de lista negra en muchos casos, o si está utilizando un enfoque de lista blanca, es posible que no pueda obtenerlos como estrechamente restringido como le gustaría.

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 codifique por ellos, como WPL (Web Protection Library) o OWASP ESAPI o OWASP Reform para otros idiomas.

7
Justin Clarke

Mi preferencia personal (y tenga en cuenta que trabajo para un proveedor, IBM, pero es mi propia opinión) es que el método de informe óptimo para la reparación es proporcionar la fuente 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 diferentes controles de entrada (fuentes) no siempre descifran los datos de su forma codificada en URL.

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

4
Aaron

En mi opinión, es importante y no importa dónde está el XSS y cómo se puede utilizar.

No importa porque cualquier XSS es peligroso hasta cierto punto.

Importa porque un XSS en una estructura de parámetros y URI de aspecto inofensivo está destinado a generar más phishing. En muchos sentidos (desde la perspectiva de un atacante), es mejor tener un XSS disponible en una página que esté disponible tanto para visitantes/usuarios autenticados como 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 explotación. SQLi ciego a menudo es más difícil de explotar, pero no importa: la clave real es qué datos o acceso no autorizado ha sido expuesto por cada falla individual de SQLi. Me vienen a la mente CVSS y DREAD, pero en realidad esto debería estar aún más optimizado como CWSS y STRIDE.

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

Una vez más, la inclusión o no de la fuente o el sumidero (o ambos) depende del público objetivo. Si estuviera recibiendo el informe, me gustaría ver ambos, pero eso es porque soy un asesor técnico profundo de aplicaciones. El sumidero es más útil para la mayoría de los desarrolladores, y puede permitirles enfocarse en la causa raíz del problema, es decir, codificación (en el caso de XSS y SQLi), sin embargo, puede haber otras soluciones y una defensa en profundidad. estrategias para presentar a los desarrolladores, así como a los administradores de bases de datos, administradores de sistemas, gerentes 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 quizás miles o millones de otros factores.

2
atdre

La respuesta es, depende.

Una disciplina de diseño es considerar todos los datos de la base de datos como no confiables y desinfectados, por lo que es responsabilidad del código que genera HTML codificarlo o escapar correctamente antes de incluirlo en la salida HTML. Si ese es el enfoque que ha adoptado su proyecto, entonces son 300 errores. Esta es una forma bastante común de estructurar una aplicación web.

Otra disciplina de diseño es desinfectar todos los datos antes de almacenarlos en la base de datos, de modo que sepamos que los datos almacenados en la base de datos son seguros para su salida en todos los contextos HTML plausibles (HTML, atributos, CSS, Javascript). Si esta es la disciplina que están siguiendo sus programadores, entonces lo que desea saber es si hay algún lugar en el código que almacene datos en la base de datos sin primero codificarlos/escapar/desinfectarlos correctamente. 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 se han desinfectado previamente antes de almacenarlos en la base de datos (y tal vez para diferentes contextos: por ejemplo, un campo puede contener HTML pre-escapado o confiable , otro podría contener una cadena de escape previa adecuada para su inclusión en Javascript), y algunos no lo han hecho y necesitarán ser escapado/desinfectado en el lado de salida. En este caso, deberá ver qué invariante mantiene el programa sobre el campo particular en la base de datos que está asociado con las vulnerabilidades XSS que encontró.

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

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

1
D.W.