sql - test - representa un objetivo de las pruebas de vulnerabilidad

Herramientas de prueba de penetración (13)

¿Qué hay de nikto ?

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

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

¿Qué pasa con el proxy de rata ?

Una herramienta de auditoría de seguridad de aplicaciones web semi-automatizada, principalmente pasiva, optimizada para una detección precisa y sensible, y anotación automática, de problemas potenciales y patrones de diseño relevantes para la seguridad basados en la observación del tráfico existente iniciado por el usuario en entornos web 2.0 complejos .
Detecta y prioriza amplias clases de problemas de seguridad, como consideraciones dinámicas del modelo de confianza entre sitios, problemas de inclusión de scripts, problemas de servicio de contenido, defensas XSRF y XSS insuficientes, y mucho más
Actualmente, se cree que Ratproxy admite entornos Linux, FreeBSD, MacOS X y Windows (Cygwin).

Eche un vistazo a Rational App Scan (antes se llamaba 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.

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.

Finalmente, 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 se 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 . Este es el 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).
Estás pagando por cosas que no necesitas (como bases de datos de CGI maliciosos conocidos de los años 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 código fuente para operar.
Para ser eficaz, 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 un anaquel. 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.

Las herramientas de prueba de penetración también tienen inconvenientes:

Son mucho más difíciles de usar que los escáneres comerciales con fuego y olvido.
Suponen cierta experiencia en vulnerabilidades de aplicaciones web: debe saber lo que está buscando.
Producen poco o ningún informe formal.

Por otra parte:

Son mucho, mucho más baratos: lo mejor del lote, Burp Suite, cuesta solo 99EU, y tiene una versión gratuita.
Son fáciles de personalizar y agregar 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 prueba de pluma para una aplicación web básica:

Inicie sesión en la aplicación a través del proxy
Cree una "lista de resultados" de las principales áreas funcionales de la aplicación y haga ejercicio una vez.
Use la herramienta "araña" en su aplicación de prueba de pluma para encontrar todas las páginas y acciones y manejadores en la aplicación.
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 los fuzzers vienen con cadenas de prueba básicas que incluyen:
- Metacaracteres SQL
- Escapes de HTML / Javascript y metacaracteres
- Variantes internacionalizadas de estos para evadir los filtros de entrada
- Nombres y valores de campo de formulario predeterminados bien conocidos
- Nombres de directorios, nombres de archivos y verbos de manejador bien conocidos
Dedique varias horas a filtrar los errores resultantes (una ejecución de fuzz típica para un formulario puede generar 1000 de ellos) en busca de respuestas sospechosas.

Este es un enfoque intensivo en mano de obra, "metal desnudo". 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 por varias razones:

Sus pruebas de seguridad tomarán una cantidad predecible de tiempo y recursos por aplicación, lo que le permite presupuestar y clasificar.
Su equipo obtendrá resultados máximos precisos y exhaustivos, 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.

He oído cosas buenas sobre SpiDynamics WebInspect en lo que respecta a soluciones pagas, así como a Nikto (para una solución gratuita) 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. ;)

McAfee Secure no es una solución. El servicio que brindan es una broma.

Vea abajo:

http://blogs.zdnet.com/security/?p=1092&tag=rbxccnbzd1
http://blogs.zdnet.com/security/?p=1068&tag=rbxccnbzd1
http://blogs.zdnet.com/security/?p=1114&tag=rbxccnbzd1

Para este tipo de prueba, realmente quieres mirar 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 profesionales 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 pluma por cuenta propia, le recomiendo que lea gran parte de la documentación del Proyecto OWASP . 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).

Podrías considerar chorizo

Sé que preguntaste 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 a menudo no es el más efectivo .

Las herramientas de revisión del código fuente pueden proporcionarle una visibilidad mucho mejor de su base de código, 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 ++, gratuito con VSTS, decente pero no excelente), LAPSE de OWASP para Java (gratis, decente no excelente), CheckMarx (no es barato , herramienta fanTASTic para .NET y Java, pero alta sobrecarga), y muchos más.

Un punto importante que debe tener en cuenta: (la mayoría de) las herramientas automatizadas no encuentran todas las vulnerabilidades, ni siquiera están 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 (ciclo de vida de desarrollo de seguridad), que incluye el modelado de amenazas, revisión de diseño, etc., ayudará aún más ...

Sé que preguntaste 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 a menudo no es el más efectivo.

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

Y, por supuesto, un SDLC adecuado (ciclo de vida de desarrollo de seguridad), que incluye el modelado de amenazas, revisión de diseño, etc., ayudará aún más ...

Skipfish, w3af, arachni, ratproxy, ZAP, WebScarab: todo gratis y muy bueno IMO

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.

anteriormente hackersafe McAfee Secure.