2008-09-16 10 views
43

Tenemos cientos de sitios web que fueron desarrollados en asp, .net y java y estamos pagando mucho dinero por una agencia externa para hacer una prueba de penetración de nuestros sitios para buscar lagunas de seguridad. ¿Hay algún software (bueno) (pagado o gratis) para hacer esto?herramientas de prueba de penetración

o ... ¿hay algún artículo técnico que me pueda ayudar a desarrollar esta herramienta?

Respuesta

64

Hay dos direcciones diferentes que puede utilizar con herramientas de prueba automatizadas para aplicaciones web.

En primer lugar, están los escáneres web comerciales , de los cuales HP WebInspect y Rational AppScan son los dos más populares. Estas son herramientas "todo en uno", "dispara y olvida" que descargas e instalas en un escritorio interno de Windows y luego le das una URL para arañar tu sitio, busca vulnerabilidades bien conocidas (es decir, las cosas que han llegado a Bugtraq), y exploran las vulnerabilidades de scripts en sitios cruzados y de inyección SQL.

En segundo lugar, están las herramientas de escaneo de código fuente , de las cuales Coverity y Fortify son probablemente las dos más conocidas. Estas son las herramientas que instala en el escritorio de un desarrollador para procesar su código fuente Java o C# y buscar patrones bien conocidos de código inseguro, como una validación de entrada deficiente.

Por último, están las herramientas de prueba de penetración. Con mucho, la herramienta de prueba de penetración de aplicaciones web más popular entre los profesionales de la seguridad es Burp Suite, que puede encontrar en http://www.portswigger.net/proxy. Otros incluyen Spike Proxy y OWASP WebScarab. De nuevo, instalará esto en un escritorio interno de Windows. Se ejecutará como un proxy HTTP, y apuntará su navegador hacia él. Utilizará sus aplicaciones como lo haría un usuario normal, mientras registra sus acciones. A continuación, puede volver a cada página individual o acción HTTP y buscar problemas de seguridad.

En un entorno complejo, y especialmente si está considerando algo de bricolaje, Recomiendo encarecidamente las herramientas de prueba de penetración. He aquí por qué:

Los escáneres web comerciales proporcionan una gran cantidad de "amplitud", junto con informes excelentes.Sin embargo:

  • Tienden a extrañar cosas, porque cada aplicación es diferente.

  • Son caros (WebInspect comienza en los 10 de miles).

  • Paga por cosas que no necesita (como bases de datos de CGI malos de los '90).

  • Son difíciles de personalizar.

  • Pueden producir resultados ruidosos.

Los escáneres de código fuente son más completos que los escáneres web. Sin embargo:

  • Son incluso más caros que los escáneres web.

  • Requieren el código fuente para operar.

  • Para que sean eficaces, a menudo requieren que anote su código fuente (por ejemplo, para seleccionar rutas de entrada).

  • Tienen una tendencia a producir falsos positivos.

Tanto los escáneres comerciales como los escáneres de código fuente tienen la mala costumbre de convertirse en productos de estantería. Peor aún, incluso si funcionan, su costo es comparable a obtener 1 o 2 aplicaciones completas auditadas por una consultoría; si confía en sus consultores, está garantizado que obtendrá mejores resultados de ellos que de las herramientas.

herramientas de pruebas de penetración tienen desventajas también:

  • Son mucho más difícil de usar que dispara y olvida escáneres comerciales.

  • Suponen cierta experiencia en vulnerabilidades de aplicaciones web; debe saber lo que está buscando.

  • Producen poco o nada de informes formales.

Por otro lado:

  • Son mucho, mucho más barato --- la mejor del lote, Burp Suite, cuesta sólo 99EU, y tiene una versión gratuita.

  • Son fáciles de personalizar y se agregan a un flujo de trabajo de prueba.

  • Son mucho mejores para ayudarlo a "conocer" sus aplicaciones desde el interior.

Aquí hay algo que haría con una herramienta de pen-test para una aplicación web básico:

  1. Entrar en la aplicación a través del proxy

  2. crear una "lista negra" de las principales áreas funcionales de la aplicación, y ejercítese una vez.

  3. Utilice la herramienta "araña" en su aplicación de prueba de pluma para encontrar todas las páginas, acciones y manejadores en la aplicación.

  4. Para cada página dinámica y cada formulario HTML que la araña descubra, use la herramienta "fuzzer" (Burp lo llama un "intruso") para ejercitar cada parámetro con entradas no válidas. La mayoría de fuzzers vienen con cadenas de prueba básicos que incluyen:

    • metacaracteres SQL

    • HTML/Javascript escapa y metacaracteres

    • variantes internacionalizados de estos para evadir los filtros de entrada

    • Well- nombres y valores de campo de formulario predeterminados conocidos

    • Nombres conocidos de directorio, nombres de archivo y los verbos de controlador

  5. pasar varias horas filtrando los errores resultantes (una carrera pelusa de una forma típica podría generar 1.000 de ellos) en busca de respuestas sospechosas.

Este es un enfoque intensivo en mano de obra "al descubierto". Pero cuando su empresa es propietaria de las aplicaciones reales, el enfoque bare-metal vale la pena, ya que puede usarlo para construir suites de prueba de regresión que se ejecutarán como un reloj en cada ciclo de desarrollo para cada aplicación. Esta es una victoria para un montón de razones:

  • Su pruebas de seguridad se llevará una cantidad predecible de tiempo y recursos por aplicación, lo que le permite presupuesto y triaje.

  • Su equipo obtendrá la máxima precisión y resultados completos, ya que sus pruebas se ajustarán a sus aplicaciones.

  • Va a costar menos que los escáneres comerciales y menos que los consultores.

Por supuesto, si sigue esta ruta, básicamente se convertirá en un asesor de seguridad para su empresa. No creo que eso sea malo; si no quieres esa experiencia, WebInspect o Fortify no te ayudarán de ninguna manera.

+4

Excelente respuesta. – xan

+0

Agradable y esto es lo que esperaba, Gracias –

1

He oído cosas buenas sobre SpiDynamics WebInspect por lo que las soluciones van pagados, así como Nikto (para una solución libre) y otras herramientas de código abierto. Nessus es una excelente herramienta para la infraestructura en caso de que necesite verificar esa capa también. Puede recoger un cd en vivo con varias herramientas llamado Nubuntu (Auditor, Helix o cualquier otra distribución de seguridad funciona también) y luego subir algunos tutoriales para la herramienta específica. Siempre, siempre asegúrese de escanear desde la red local. Usted corre el riesgo de que el centro de datos lo bloquee si escanea un recuadro de la WAN sin autorización. Aprendimos la lección de la manera difícil. ;)

0

http://www.nessus.org/nessus/ - Nessus ayudará a sugerir formas de mejorar sus servidores. Realmente no puede probar aplicaciones personalizadas, aunque creo que los complementos son relativamente fáciles de crear por su cuenta.

0

Eche un vistazo a Rational App Scan (solía llamarse Watchfire). No es gratis, pero tiene una interfaz de usuario agradable, es muy potente, genera informes (a medida y en contra de marcos de cumplimiento estándar como Basel2) y creo que puedes crear un script en tu compilación de CI.

4

Sé que ha preguntado específicamente sobre las herramientas de pentesting, pero como esas han sido ampliamente respondidas (usualmente uso una mezcla de AppScan y pentester entrenado), creo que es importante señalar que pentesting no es la única forma de "verificar las lagunas de seguridad", y con frecuencia es no el más efectivo.

Las herramientas de revisión del código fuente pueden proporcionarle una visibilidad mucho mejor de su código base, y encontrar muchos defectos que pentesting no ofrece.

Estos incluyen Fortify y OunceLabs (costosos y para muchos idiomas), VisualStudio.NET CodeAnalysis (para .NET y C++, gratis con VSTS, decente pero no excelente), LAPSE de OWASP para Java (gratis, decente, no excelente), CheckMarx (no es una herramienta barata, fanTASTic para .NET y Java, pero tiene una gran sobrecarga), y muchos más.

Un punto importante que debe tener en cuenta: (la mayoría de) las herramientas automáticas no encuentran todas las vulnerabilidades, ni siquiera cerca. Puede esperar que las herramientas automatizadas encuentren aproximadamente el 35-40% de los errores que encontraría un pentester profesional; lo mismo ocurre con la revisión de código fuente automática frente a manual.

Y por supuesto, un SDLC adecuado (Seguridad del Ciclo de Vida de Desarrollo), incluyendo el modelado de amenazas, revisión de diseño, etc, ayudará aún más ...

0

Para este tipo de prueba, realmente desea buscar algún tipo de probador de fuzz. SPIKE Proxy es uno de los dos probadores de fuzz para aplicaciones web. Es de código abierto y escrito en Python. Creo que hay un par de videos de BlackHat o DefCON sobre el uso de SPIKE en algún lado, pero tengo dificultades para localizarlos.

Hay un par de paquetes de software profesional de alta gama que harán las pruebas de la aplicación web y mucho más. Una de las herramientas más populares sería CoreImpact

Si planea realizar la Prueba de lápiz por su cuenta, le recomiendo que lea gran parte del OWASP Project's documentation. Específicamente, las guías de Verificación y Prueba/Desarrollo de Seguridad de Aplicación OWASP. La mentalidad que necesita para probar a fondo su aplicación es un poco diferente de su mentalidad de desarrollo normal (no es que DEBE ser diferente, pero generalmente lo es).

0

¿qué hay de rat proxy?

Una aplicación de herramienta semi-automatizada, en gran parte pasiva web auditoría de seguridad, optimizado para una detección sensible precisa y , y automático anotación, de los problemas potenciales y patrones de diseño relevantes para la seguridad basado en la observación de existente, tráfico iniciado por el usuario en entornos web complejos 2.0.

Detecta y prioriza las amplias clases de los problemas de seguridad, como entre sitios consideraciones modelo de confianza dinámicos, problemas de inclusión de guión, contenido problemas que sirven, insuficiente XSRF y defensas XSS, y mucho más

Ratproxy actualmente se cree que admite entornos Linux, FreeBSD, MacOS X y Windows (Cygwin).

0

sé que pidió específicamente sobre las herramientas de pentesting, pero ya que ellos han sido contestadas ampliamente (por lo general voy con una mezcla de AppScan y pentester entrenado), creo que es importante señalar que pentesting no es la única manera de para "verificar las lagunas de seguridad", y a menudo no es la más efectiva.

Las herramientas de revisión del código fuente pueden proporcionarle una visibilidad mucho mejor de su código base, y encontrar muchos defectos que pentesting no ofrece.

Estos incluyen Fortify y OunceLabs (costosos y para muchos idiomas), VisualStudio.NET CodeAnalysis (para .NET y C++, gratis con VSTS, decente pero no excelente), LAPSE de OWASP para Java (gratis, decente, no excelente), CheckMarx (no es una herramienta barata, fanTASTic para .NET y Java, pero tiene una gran sobrecarga), y muchos más.

Un punto importante que debe tener en cuenta: (la mayoría de) las herramientas automáticas no encuentran todas las vulnerabilidades, ni siquiera cerca. Puede esperar que las herramientas automatizadas encuentren aproximadamente el 35-40% de los errores que encontraría un pentester profesional; lo mismo ocurre con la revisión de código fuente automática frente a manual.

Y por supuesto, un SDLC adecuado (Seguridad del Ciclo de Vida de Desarrollo), incluyendo el modelado de amenazas, revisión de diseño, etc, ayudará aún más ...

1

Skipfish, w3af, Arachni, ratproxy, ZAP, Webscarab: todo gratis y muy buena IMO

Cuestiones relacionadas