Antes de comenzar las pruebas de seguridad, es fundamental entender la estructura de la aplicación. Sin una comprensión profunda sobre el diseño de la disposición de la aplicación, es improbable se puedan realizar pruebas profundas.

Objetivos de la Prueba

Mapear la aplicación web y entender los flujos de trabajo principales.

Como Evaluar

En las pruebas de caja negra es extremadamente difícil evaluar el código base completo. No solo porque el profesional no tiene una visión de las rutas de código a través de la aplicación, sino incluso si lo tuviera, probar todas las rutas de código consumiría bastante tiempo. Una manera de reconciliar esto es documentar las rutas de código descubiertas y evaluadas.

Existen muchas maneras de abordar la prueba y medir la cobertura del código:

• Ruta: Probar cada una de las rutas a través de la aplicación, lo cual incluya pruebas de análisis con valores combinatorios y limites para cada ruta de decisión. Mientras esta perspectiva ofrece minuciosidad, el número de rutas factibles de ser probadas crece exponencialmente con cada rama de decisión.
• Flujo de Datos (Análisis de Corrupción): Prueba la asignación de variables mediante una interacción externa (normalmente usuarios). Se enfoca en mapear el flujo, transformación y utilización de datos a través de la aplicación.
• Carrera: Evalúa múltiples instancias concurrentes de la aplicación manipulando los mismos datos.

El intercambio en cuanto a cual método utilizar y cual grado de cada método se utiliza, debe ser negociado con el propietario de la aplicación. También se podrían adoptar perspectivas simples, incluyendo consultar al propietario de la aplicación cuales funciones o secciones de código son particularmente preocupantes, y como estos segmentos de código pueden ser alcanzados.

Prueba de Caja Negra

Para demostrar la cobertura del código hacia el propietario de la aplicación, el profesional puede iniciar con una hoja de cálculo, y documentar todos los enlaces descubiertos mediante un proceso de “spidering” a la aplicación (ya sea hecha de manera manual o automática). Luego el profesional analizará de manera más cercana los puntos de decisión en la aplicación, para luego investigar cuantas rutas de código significativas son descubiertas. Estos luego son documentados en la una hoja de cálculo con URLs, prosa, y descripciones con capturas de pantalla de las rutas descubiertas.

Prueba de Caja Gris

Asegurar la cobertura de código suficiente para el propietario de la aplicación, es de lejos lo más fácil con la perspectiva de caja gris y caja blanca. La información solicitada y proporcionada al profesional, asegura los requerimientos mínimos para cumplir con la cobertura de código.

Ejemplo

Spidering automático

El spider automático es una herramienta utilizada para automáticamente descubrir nuevos recursos (URLs) en un sitio web particular. Inicia con una lista de URLs a visitar, llamadas las semillas, lo cual depende de como el Spider ha iniciado. Aunque existen muchas herramientas para “Spidering”, a continuación se utiliza Zed Attack Proxy (ZAP).

ZAP ofrece las siguientes características automáticas, los cuales pueden ser seleccionadas en base a requerimientos del profesional.

• Spider al Sitio: La lista semilla contiene todas las URIs existentes ya encontradas para el sitio seleccionado
• Spider a la Rama: La lista semilla contiene todas las URIs existentes ya encontradas y presentes en la rama de cada nodo seleccionado
• Spider a la URL: La lista semilla contiene únicamente la URI correspondiente hacia el nodo seleccionado (en el árbol del sitio)
• Spider a Todo el Alcance: La lista semilla contiene todas las URIs seleccionadas por el usuario “En Alcance”

Fuentes:

https://www.owasp.org/index.php/Map_execution_paths_through_application_(OTG-INFO-007)
https://github.com/zaproxy/zaproxy