Cualquier comentario o consejo sobre OWASP-2013 top 10 número A9

Navega tus respuestas
19

En esta iteración de la lista de las 10 principales vulnerabilidades de seguridad de la aplicación de OWASP ( enlace ), una nueva categoría 'A9 Uso de componentes con vulnerabilidades conocidas' se ha introducido. Esto parece requerir la investigación de todas las bibliotecas y el código importado en cualquier aplicación para garantizar el cumplimiento.

Tengo varios clientes que, debido a sus requisitos de auditoría PCI-DSS, usan el top 10 de OWASP para garantizar la seguridad de sus propias plataformas de software para aquellas partes de su base de código escritas para procesar pagos con tarjeta de crédito. Con este nuevo conjunto de requisitos, parece que tendrían que encontrar / listar todas sus bibliotecas importadas (módulos Perl de CPAN en una instancia, y Java libs en otra) y revisarlas línea por línea, probablemente un millón de líneas de El código de otra persona !.

¡Esto no puede ser práctico o, probablemente, muy útil! ¿Puede OWASP sugerir seriamente que las organizaciones que escriben sus propias aplicaciones, importando bibliotecas comunes, deben revisar todos los códigos de bibliotecas de terceros?

¿Alguien más se ha topado con este problema y cómo crees que puedo lidiar con esto?

    
pregunta David Scholefield 22.09.2013 - 20:17
fuente

3 respuestas

27

En una revisión formal de la seguridad de una aplicación, todas las bibliotecas deben ser revisadas por defectos de seguridad. Sin embargo, este no es el punto de OWASP-2013 A9. El núcleo de OWASP-2013 A9 se trata de tener políticas establecidas para garantizar que una aplicación no se vea comprometida debido a la negligencia. OWASP establece lo siguiente:

  1. Identifique todos los componentes y las versiones que está usando, incluyendo todas las dependencias. (por ejemplo, el complemento de versiones).
  2. Supervise la seguridad de estos componentes en bases de datos públicas, Las listas de correo del proyecto y las listas de correo de seguridad, y mantenerlas     hasta la fecha.
  3. Establezca políticas de seguridad que rijan el uso de componentes, como Requerir ciertas prácticas de desarrollo de software, pasar seguridad.     Pruebas y licencias aceptables.
  4. Cuando sea apropiado, considere agregar envoltorios de seguridad alrededor componentes para deshabilitar la funcionalidad no utilizada y / o asegurar débil o     Aspectos vulnerables del componente.

El número 2 es el más importante. Si depende de una biblioteca o plataforma, estos componentes deben actualizarse periódicamente. Internamente, debe haber un ciclo para revisar todos los componentes y versiones, y asegurarse de que estén completamente actualizados. Un ciclo mensual para revisar estos componentes sería ideal.

En resumen, el número 4 requiere una validación sólida de la entrada a las bibliotecas no confiables . Si una biblioteca no ha sido completamente probada por defectos de seguridad, entonces los datos pasados a esta biblioteca deben ser validados. Es una muy buena práctica de seguridad hacer esto para todos los comentarios. Un ejemplo de esto es utilizar una rutina de validación OWASP ESAPI para todas las entradas. Entonces, si es una dirección de correo electrónico, debe coincidir con una expresión regular para las direcciones de correo electrónico.

    
respondido por el rook 22.09.2013 - 20:30
fuente
4

Desde el punto de vista de un auditor, no espero que pase por cada línea de código de las bibliotecas usadas SI la biblioteca se usa y verifica comúnmente. Si está utilizando un "código aleatorio que encontró en Internet" para un sistema de transacción, espero que haya tenido una revisión del código.

Ahora, para las bibliotecas más usadas y revisadas, simplemente revisaría la versión de la biblioteca y vería si hay vulnerabilidades conocidas. Debe actualizar regularmente sus bibliotecas con al menos todas las actualizaciones de seguridad.

Si no hay una actualización de seguridad disponible para el problema, le pediré que tenga un plan de acción para:

  • controlar si se ha producido una explotación (a veces, una actualización de seguridad puede ser para un componente que no se utiliza)
  • mitigación del riesgo (deshabilitar el componente o alterar el WAV / IPS)
respondido por el Lucas Kauffman 22.09.2013 - 22:50
fuente
0

Rook proporcionó una excelente respuesta a su pregunta, y aunque es ciertamente más fácil monitorear los componentes utilizando bases de datos públicas y otros medios, en lugar de revisar el código de todos los componentes, sigue siendo una tarea importante. ¿Por qué? Debido a que las aplicaciones ahora se componen principalmente de componentes, la investigación muestra que una aplicación promedio ahora consta de 80% o más de componentes de código abierto. Y, no solo se trata de los componentes que incorporas a tu aplicación, también incluye todos los demás componentes dependientes. Dado el volumen, la variedad y la cadencia de lanzamiento (muchos proyectos se actualizan 4 veces al año), es necesaria alguna forma de automatización.

Las tecnologías de seguridad de aplicaciones existentes, como DAST y SAST, están diseñadas para un problema diferente: se centran en el código personalizado que une los componentes. Se necesita un enfoque diferente para mantenerse actualizado: un enfoque que rige todo el ciclo de vida, en comparación con las exploraciones en un momento dado que se entregan al final del ciclo de desarrollo.

Hay 2 informes disponibles que proporcionan más información sobre OWASP A9 y los nuevos requisitos de los componentes PCI 3.0. Además, también está disponible un seminario web sobre este tema que incluye información de Crosskey, una firma de servicios financieros.

enlace

Gracias, Mark Troester Sonatype @mtroester

    
respondido por el user34678 26.11.2013 - 03:16
fuente

Lea otras preguntas en las etiquetas

¿Dónde puedo encontrar un tutorial sólido de BURP? [cerrado] ¿Cómo puedo verificar que el protocolo SSLv3 está deshabilitado?