Hasta donde sé, las pruebas de penetración se pueden dividir en pruebas de caja negra, caja gris y caja blanca. Pero entonces, ¿qué pasa con la revisión de código seguro? ¿Es parte de las pruebas de caja blanca o está separado?
La revisión del código de seguridad es el proceso de auditar el código fuente para que una aplicación verifique que los controles de seguridad correctos estén presentes, que funcionen según lo previsto y que Se han invocado en todos los lugares correctos. OWASP
Teniendo esto en cuenta, considera la prueba de caja gris:
Un probador de caja negra desconoce la estructura interna de la aplicación que se va a probar, mientras que un probador de caja blanca tiene acceso a la estructura interna de la aplicación. Un probador de caja gris conoce parcialmente la estructura interna, que incluye el acceso a la documentación de las estructuras de datos internas, así como los algoritmos utilizados. Wikipedia
Los pentesters identificarán las vulnerabilidades mediante el software de ingeniería inversa en el código de ensamblaje y trabajarán desde allí para identificar los vectores de ataque, como un desbordamiento de búfer. Pero, según la definición anterior, la revisión de código seguro debe ser una prueba de caja blanca.
Para responder a su pregunta, la revisión segura del código se realiza mediante pruebas de caja blanca, exclusivamente. Puede haber algunos casos en los que las personas puedan modificar esta definición para ajustarse al ejemplo anterior, pero como el código de ensamblaje de ingeniería inversa no es un código fuente, no lo reconoceré.
La diferencia entre las pruebas de caja blanca y la revisión del código fuente es que no canaliza el conocimiento de la disponibilidad de una vulnerabilidad después de revisar el código en la revisión del código fuente, pero en una prueba de caja blanca utiliza este conocimiento para crear un POC que funcione ( Prueba de concepto). En la revisión del código fuente, solo señala el fragmento de código afectado por la vulnerabilidad, en las pruebas de caja blanca recorremos todo el flujo de ejecución de extremo a extremo para determinar la vulnerabilidad y crear un POC.
La principal diferencia está en la acción real realizada. Las pruebas de caja blanca y la revisión segura de códigos comparten objetivos similares.
La prueba de caja blanca implica tocar el producto. En cualquier nivel de prueba, se hace algo con el producto que se está probando: se llama a una función y se valida su respuesta, por ejemplo, o alguien que pretende ser un usuario pasa por un flujo central. En cualquier caso, el software está físicamente probado; debe existir de alguna manera, y debe ser utilizable de alguna manera. Y luego debe ser utilizado.
En la revisión de código seguro, el producto no se toca. Puede tocarse como una actividad complementaria, quizás, pero la función principal es más bien la lectura. Lee el código fuente, lo analiza a medida que avanza y, en última instancia, intenta identificar y sintetizar los problemas para corregirlo. La revisión segura del código es un subconjunto de la revisión normal del código, que puede incluir el análisis del diseño, la implementación, el rendimiento, la estética, etc.
Una forma de verlo es como sigue:
Editar: lo anterior se refiere solo al cuadro blanco (para responder al alcance particular de la pregunta de OP), pero los mismos principios se aplican en las pruebas de cuadro gris y negro. En cualquier metodología de prueba, debe utilizar el producto como un subproducto inherente de la naturaleza de la tarea de la prueba. Esto (como se explicó anteriormente) no es lo mismo que con la revisión de código.
Lea otras preguntas en las etiquetas terminology