Las pruebas de penetración informaron vulnerabilidades CERO. ¿Significa esto que mi aplicación web es segura?

Las pruebas automatizadas son un buen paso, pero no sustituyen a un hacker ético humano experto para encontrar vulnerabilidades. Esto puede ser a través de pruebas de caja blanca y negra, revisión de código y herramientas especializadas como metasploit y código escrito a medida. Sin embargo, las personas con las habilidades y la experiencia son mucho más profundas y obtienen muchos más resultados que las herramientas automatizadas, sin importar cuán buenas sean.

Es imposible dar una idea de lo seguro que está, si todo lo que ha hecho es utilizar herramientas automatizadas, entonces se ha protegido de una buena cantidad de herramientas de explotación automatizadas, pero una persona capacitada probablemente tendrá mucho mejor oportunidad de encontrar cualquier cosa.

Si bien tiene un par de respuestas que indican que, de hecho, no puede estar seguro de que su aplicación sea segura en función de la salida de las pruebas automatizadas, podría ser útil ilustrar algunos problemas que una herramienta automatizada probablemente no detectaría. eso todavía puede ser bastante serio.

• Los defectos de autorización suelen ser el ejemplo canónico de cosas que son difíciles de encontrar con un escáner recto. Por ejemplo, suponiendo que tiene múltiples niveles de privilegios de usuario, una situación en la que un tipo de usuario no debería poder acceder a una pieza específica de funcionalidad que resulta estar disponible podría ser un problema de seguridad bastante serio pero un escáner directo no necesariamente reconocer a qué debería o no debería poder acceder

• Fallos en la lógica de negocios. Un ejemplo clásico es la capacidad en una tienda de comercio electrónico para comprar algo por -0.99 unidades de su moneda local. He visto este en pruebas en vivo, pero nuevamente el escáner carece de contexto para poder decir que eso es un problema.

• Algo tan básico como un directorio oculto puede engañar a los escáneres de caja negra. Los buscarán, pero, por ejemplo, si tiene un directorio oculto con una interfaz de administración no protegida en / my_totally_secret_dir_honest_guv / un escáner probablemente no lo localice.

• Problemas con la inyección de segundo orden. Por ejemplo, su aplicación de front-end toma la entrada de un usuario, pero nunca la representa para el usuario. En su lugar, se presenta en una aplicación diferente (por ejemplo, aplicaciones de asistencia técnica donde el ticket se envía a un administrador para trabajar). Si la primera aplicación no se hace eco del contenido, los escáneres no pueden encontrar cosas como XSS que aún pueden estar presentes (aunque, por supuesto, podría argumentarse que es el problema de otras aplicaciones aquí)

Eso son algunos ejemplos, hay más. Lo que sugeriría es que la revisión del código es válida para encontrar algo de esto y también la revisión manual es muy útil. Un buen recurso para obtener una idea más clara de las posibilidades es

No estoy seguro de que el 99% sea seguro, todo lo que puedo decir es que no es 100% seguro. Cualquier herramienta o comprobador de lápiz solo puede probar vulnerabilidades y vulnerabilidades conocidas actualmente. Los problemas de seguridad pueden salir a la luz en las próximas semanas / meses / años que resulten en el compromiso de su aplicación. Por lo que sabe, puede haber atacantes ahora que conocen un exploit que no está cubierto en sus pruebas.

Todo lo que puede decir es que ha tomado todas las medidas razonables para garantizar la seguridad de su aplicación.

No, no puede decir que su aplicación es 99% segura, 100% o 25% segura. Solo puede confirmar que su aplicación haya superado una prueba de penetración y la prueba de penetración informó 0 no conformidades. Eso suena bien, pero no se puede inflar un porcentaje de seguridad desde aquí con esta información.

La tecnología para certificar que un fragmento de código no tiene ninguna vulnerabilidad de seguridad no se ha desarrollado completamente. Las investigaciones solo se han realizado para certificar que no existe algún tipo de vulnerabilidad en el código con algunas Características como el código C que no asigna memoria dinámicamente, pero en general, es muy difícil certificar que un fragmento de código no tiene ninguna vulnerabilidad de seguridad.

Si necesita dicho porcentaje, puede realizar una prueba de penetración compatible con OSSTMM en la que se calcula la superficie de ataque y luego los RAV . Esa es una forma de calcular algo similar al porcentaje que mencionas y seguir una metodología repetible.

Para dar un valor adecuado a esta prueba de penetración en particular, es importante saber qué se ha probado exactamente (el alcance) y cómo (metodología, herramientas, etc.). Si su proveedor le ha entregado la lista de herramientas y productos, esa información puede ser analizada por otro experto en caso de que necesite repetibilidad (interesante para cualquier auditoría).

Si la prueba de penetración se basa en herramientas automáticas, como comentaron otros expertos, mi opinión es que puede estar seguro de que puede confiar en esta prueba de penetración. Las herramientas automáticas tienen limitaciones importantes y, cuando no detectan ninguna vulnerabilidad, es necesario conocer el análisis posterior para estar seguros de por qué.

Si tiene la documentación adecuada de lo que se probó y los resultados, si en el futuro tiene un incidente de seguridad, puede revisar la documentación para descubrir por qué no se detectó la vulnerabilidad y mejorar su metodología de prueba.

Lo que hiciste fue una prueba de vulnerabilidad en el mejor de los casos. Las herramientas de prueba automatizadas, como las que usted describe, simplemente prueban las vulnerabilidades conocidas. Una prueba de penetración tiene el componente humano, donde el atacante no solo localizaría las vulnerabilidades conocidas, sino que descubriría nuevas potenciales y luego las explotaría.

Aunque tomó un gran primer paso, debe tener en cuenta la inversión que ha hecho para desarrollar su aplicación y luego determinar si una prueba de penetración real es algo que vale la pena explorar desde un punto de vista de riesgo.