Escáneres humanos contra vulnerabilidad [cerrado]

La mayoría de las fallas de control de acceso / autorización nunca se encontrarían con una herramienta (genérica), porque no comprende qué se supone que es accesible y qué no. (Habiendo dicho eso, los pentesters experimentados probablemente saben que muchas aplicaciones tampoco tienen esto documentado ...) Así que ese es un ejemplo de toda una clase de problemas.

Cualquier defecto lógico (por ejemplo, un usuario que puede crear otro usuario con más privilegios por diseño) tampoco sería detectado por una herramienta automatizada.

Cualquier cadena de vulnerabilidades no estaría correlacionada, como por ejemplo, cómo utilizar una fuga de información de bajo riesgo, junto con un DOM XSS de riesgo medio junto con otra vulnerabilidad de bajo riesgo para cambiar la contraseña de un usuario a cualquier cosa que el atacante quiera (esto es un ejemplo real que he visto).

Probar el DOM XSS con un escáner simple (normal) como la mayoría de esas herramientas comerciales es bastante difícil ya que no tienen un tiempo de ejecución de Javascript, por lo que se perderán la mayor parte.

También para las cosas que se pueden probar, una herramienta puede tener varios patrones para probar, pero probablemente se pierda casos más complejos. Por ejemplo, ¿qué sucede si una aplicación tiene un filtro de lista negra para XSS que bloquea explícitamente la alerta (1) y todos los vectores de ataque de la herramienta lo tienen como carga útil? Pasar por un filtro de lista negra es casi siempre posible, pero es muy difícil para una herramienta automatizada.

O considera DoS. ¿Cómo encontraría eso una herramienta automatizada?

Para un ejemplo final, ¿qué pasa con el desbordamiento de búfer en un archivo cargado y procesado? ¿Cómo podría la herramienta automatizada saber que ese es el caso y cómo crearía un exploit para ella?

Estos son solo algunos ejemplos, estoy seguro de que otros citarán mucho más.

En resumen,

• hay clases enteras de vulnerabilidades que no se pueden probar en el caso genérico

• incluso para las vulnerabilidades que se pueden probar automáticamente, es prácticamente imposible escribir pruebas exhaustivas (un conjunto de pruebas que encuentra todas instancias de la vulnerabilidad).

Por supuesto, con todo esto en mente, creo que no hay nada de malo en usar herramientas para hacer varias cosas más rápido. Sin embargo, cualquier resultado de una herramienta debe ser reproducido por el probador, y también debe ser consciente de las limitaciones de la herramienta para poder aumentar los resultados con más ataques creativos.

Solo quiero complementar la respuesta anterior, las vulnerabilidades como SQL Injection y XSS pueden detectarse mediante procesos sistemáticos (no siempre), una herramienta sería suficiente para este trabajo, pero como dijo @lengyelg, hay casos complejos que pueden no puede ser detectado por la facilidad de una herramienta, por ejemplo: una inyección de SQL ciego donde la inyección podría ocurrir después de order by o limit , la aplicación está detrás de un WAF y la respuesta de la aplicación es una estructura de datos JSON; este tipo de vulnerabilidad necesita tiempo para ser analizada. Si ejecuta una herramienta, es posible que no pueda detectar la vulnerabilidad, no quiero decir que las herramientas no pueden detectarlas, pero una herramienta necesita conocimiento para ser configurado correctamente La mejor manera de obtener este conocimiento es hacerlo usted mismo, conociendo la aplicación, una respuesta correcta, una respuesta incorrecta, un error de la aplicación, etc. cuando puede comprender muy bien el comportamiento de la aplicación y cada uno de sus componentes, puede crear un buen exploit y configurar una herramienta para hacer el trabajo más rápido y eficiente. Una herramienta nos ayuda a hacer nuestro trabajo, pero en mi opinión, nunca debería hacer nuestro trabajo completamente. Entonces creo que una herramienta necesita el conocimiento humano, un martillo necesita la fuerza correcta y la dirección correcta para hacer un buen trabajo.