Entrando en tema
Este artículo sintetiza los conceptos clave presentados por Richard López, líder técnico de QA, durante la 9na edición de Testing en Chile, quien se ocupó de exponer sobre cómo los profesionales de aseguramiento de la calidad pueden detectar vulnerabilidades mediante pruebas automatizadas. La tesis central es que el equipo de QA puede actuar como un «primer filtro» en seguridad, aprovechando sus habilidades y herramientas existentes para identificar vulnerabilidades de alto nivel sin necesidad de ser especialistas en ciberseguridad o hackers. El enfoque principal se centra en la utilización de la herramienta de código abierto OWASP ZAP para realizar análisis de seguridad dinámico (DAST).
La estrategia propuesta consiste en integrar OWASP ZAP en los flujos de trabajo de automatización de pruebas ya existentes, como los que utilizan Selenium. Al configurar el navegador de prueba para que funcione a través del proxy de ZAP, los scripts de prueba funcional existentes pueden ser reutilizados para que ZAP capture y analice el tráfico de la aplicación. El proceso culmina con la ejecución de escaneos específicos (pasivos y activos) y la generación automática de reportes detallados. Este enfoque añade una capa de seguridad al ciclo de desarrollo con un esfuerzo relativamente bajo, fomentando una colaboración proactiva entre los equipos de QA y seguridad para mejorar la calidad y robustez del software.
1. El Rol del Profesional de QA en la Seguridad del Software
El rol del aseguramiento de la calidad (QA) trasciende la validación funcional y puede extenderse para ser un pilar fundamental en la estrategia de seguridad de una organización. El profesional de QA está en una posición ideal para ser el primer filtro humano en la detección de vulnerabilidades.
• Aplicación de la mentalidad de QA: La metodología de trabajo de un QA es directamente aplicable a las pruebas de seguridad. Una vulnerabilidad es, en esencia, otro tipo de defecto del software.
◦ Exploración de flujos: Se utiliza la misma habilidad para analizar flujos de usuario con una «lupa», buscando comportamientos inesperados o sospechosos.
◦ Reporte claro: La capacidad de crear reportes claros y concisos que inviten a la corrección es crucial. El QA puede documentar los pasos para reproducir una posible vulnerabilidad y el resultado obtenido, facilitando el trabajo del equipo de seguridad.
◦ Proceso análogo: El proceso de definir casos de prueba, ejecutar pasos, comparar resultados esperados con obtenidos y reportar desviaciones es el mismo que se utiliza para detectar defectos funcionales.
• Mitos y realidades sobre QA y Seguridad:
| Mito | Realidad |
| «La seguridad es trabajo de otro equipo.» | El QA es el primer filtro. Su función es detectar, priorizar y verificar vulnerabilidades como cualquier otro defecto del sistema. |
| «El QA debe ‘romper’ la aplicación para probar seguridad.» | El rol principal del QA es identificar y registrar la vulnerabilidad. La validación profunda y la explotación de dicha vulnerabilidad pueden ser delegadas al equipo de seguridad especializado. |
| «Si el escáner automatizado no lo marca, no lo reporto.» | Se deben reportar comportamientos sospechosos aunque no haya una alerta explícita de la herramienta. El equipo de seguridad evaluará la relevancia del hallazgo. |
2. Clasificación de Pruebas de Software
Para contextualizar las pruebas de vulnerabilidad, es fundamental entender su lugar dentro del espectro general de pruebas de software.
Pruebas Funcionales
Su propósito es verificar que las funcionalidades del software cumplen con los criterios de aceptación definidos.
• Pruebas Unitarias
• Pruebas de Integración
• Pruebas del Sistema
• Pruebas de Aceptación del Usuario (UAT)
• Pruebas de Regresión
• Pruebas de Humo (Smoke Testing)
Pruebas No Funcionales
Analizan el comportamiento y las características del sistema bajo ciertas condiciones, en lugar de funcionalidades específicas.
• Rendimiento: Pruebas de carga, estrés, y de pico.
• Seguridad: Pruebas de vulnerabilidad y de control de acceso. Este es el enfoque principal de la presentación.
• Usabilidad: Pruebas de accesibilidad y de experiencia de usuario (UX).
• Fiabilidad (Reliability): Pruebas de recuperación ante fallos y de disponibilidad.
Pruebas Estáticas vs. Dinámicas
• Pruebas Estáticas (SAST): Analizan el código fuente de la aplicación sin ejecutarlo. Herramientas como SonarQube escanean repositorios en busca de malas prácticas o vulnerabilidades a nivel de código.
• Pruebas Dinámicas (DAST): Analizan la aplicación mientras está en ejecución. Este enfoque permite identificar vulnerabilidades que solo se manifiestan en tiempo de ejecución. OWASP ZAP es una herramienta para DAST.
3. OWASP ZAP: Herramienta Clave para el Análisis Dinámico
OWASP ZAP (Zed Attack Proxy) es una herramienta de código abierto y una de las más populares en el ámbito de la seguridad para realizar pruebas dinámicas en aplicaciones web.
• Referencia a OWASP Top 10: ZAP basa sus análisis en las vulnerabilidades más comunes y críticas, como las documentadas en el OWASP Top 10. La lista de 2021, mencionada en la presentación, incluye:
◦ Pérdida del control de acceso
◦ Fallos criptográficos
◦ Inyección (Ej. SQL Injection)
◦ Diseño inseguro
◦ Configuración de seguridad incorrecta
◦ Componentes vulnerables y desactualizados
Tipos de Escaneo en ZAP
ZAP ofrece diferentes modos de escaneo, cada uno con un propósito y nivel de intrusión específico.
• Escaneo Pasivo:
◦ Función: Observa el tráfico HTTP/HTTPS entre el navegador y el servidor sin enviar peticiones maliciosas. No ataca la aplicación.
◦ Detección: Señala configuraciones básicas inseguras en cabeceras, cookies, etc., y ayuda a detectar información expuesta por error.
◦ Seguridad: Es completamente seguro y no invasivo. Puede ser utilizado en ambientes productivos sin riesgo. Se ejecuta automáticamente por defecto mientras se usa la herramienta.
• Escaneo Activo:
◦ Función: Es un escaneo agresivo que envía entradas de prueba y payloads maliciosos para comprobar si existen vulnerabilidades reales como Cross-Site Scripting (XSS) o SQL Injection.
◦ Detección: Colabora activamente en encontrar agujeros de seguridad al modificar datos y peticiones.
◦ Seguridad: Es intrusivo y jamás debe ejecutarse en un entorno de producción. Su uso debe limitarse a ambientes controlados (QA, desarrollo) y siempre con autorización previa.
• Spider:
◦ Función: Recorre todos los enlaces de una aplicación para descubrir páginas, recursos y formularios, construyendo un mapa del sitio automáticamente.
◦ Ideal para: Sitios web tradicionales o «clásicos».
• Ajax Spider:
◦ Función: Navega aplicaciones modernas basadas en JavaScript (React, Angular, Vue.js) para descubrir rutas y contenido dinámico que el Spider normal no puede ver.
◦ Consideraciones: Es más lento que el Spider tradicional y puede requerir configuración de inicio de sesión para acceder a áreas privadas.
Flujo de Trabajo Combinado y Eficiente
Para obtener resultados eficientes y completos, se recomienda la siguiente combinación de escaneos:
1. Mapeo del Sitio: Ejecutar primero el Spider o Ajax Spider (dependiendo de la tecnología de la aplicación) para que ZAP descubra todas las URLs y puntos de entrada del sistema.
2. Análisis Pasivo: Este escaneo se ejecuta de forma implícita y continua mientras se realiza el mapeo y la navegación.
3. Análisis Activo: Una vez que el sitio ha sido completamente mapeado, ejecutar el escaneo activo sobre las URLs descubiertas para una búsqueda profunda de vulnerabilidades.
4. Integración de ZAP con Pruebas Automatizadas (Selenium)
La verdadera potencia de este enfoque reside en la capacidad de integrar ZAP en un pipeline de automatización existente. Esto permite reutilizar las pruebas funcionales ya desarrolladas para realizar escaneos de seguridad de forma continua.
• Configuración Técnica:
1. Configuración del Proxy: El navegador utilizado por el framework de automatización (ej. ChromeDriver en Selenium) se configura para usar la dirección local y el puerto de OWASP ZAP como su proxy.
2. Uso de la API de ZAP: ZAP expone una API que permite controlarlo programáticamente. Desde el código de las pruebas, se puede iniciar, detener y gestionar los diferentes tipos de escaneo, así como generar reportes.
• Proceso Automatizado Típico:
1. Inicio: Al comenzar la suite de pruebas (usando un SuiteListener), el código se conecta a la API de ZAP, inicia una nueva sesión y limpia alertas previas.
2. Ejecución de Pruebas Funcionales: Los scripts de Selenium ejecutan los flujos de usuario normales (login, búsquedas, transacciones). Todo el tráfico generado pasa a través de ZAP, que realiza su escaneo pasivo automáticamente.
3. Finalización y Escaneos Adicionales: Al terminar las pruebas, el script invoca a la API de ZAP para:
▪ Ejecutar el Ajax Spider para asegurar un mapeo completo.
▪ Ejecutar el escaneo activo sobre todo el sitio mapeado.
4. Generación de Reportes: Una vez finalizado el escaneo activo, se utiliza la API para generar un reporte en formato HTML.
5. Notificación: El reporte puede ser enviado automáticamente por correo electrónico a los equipos correspondientes (QA, Seguridad) o se puede integrar con herramientas como Jira para crear issues de forma automática.
5. Reportes y Acciones Posteriores
Los reportes generados por ZAP son un entregable clave del proceso, ya que proporcionan información valiosa y accionable.
• Características de los Reportes:
◦ Visualmente Atractivos: Son claros y fáciles de interpretar.
◦ Detallados: Muestran todas las posibles vulnerabilidades encontradas, clasificadas por nivel de riesgo (Alto, Medio, Bajo, Informativo).
◦ Accionables: Para cada alerta, el reporte incluye una descripción del riesgo, las URLs afectadas y, en muchos casos, posibles soluciones o mitigaciones.
◦ Ejemplos de Hallazgos: Un reporte puede identificar una librería de JavaScript vulnerable por estar desactualizada o un posible punto de inyección SQL en un formulario.
• Gestión de Hallazgos:
◦ El equipo de QA reporta las «posibles vulnerabilidades», ya que las herramientas pueden generar falsos positivos.
◦ El equipo de seguridad, como especialista, recibe este reporte y se encarga de validar, explotar (si es necesario) y confirmar si el hallazgo representa un riesgo real.
6. Conclusiones y Recomendaciones Clave
• QA como primer filtro: El equipo de QA debe asumirse como el primer filtro humano en la detección de vulnerabilidades, utilizando su conocimiento del producto.
• Proactividad: Es fundamental ser proactivo y proponer la implementación de análisis básicos de vulnerabilidad, incluso si no es una práctica establecida en el equipo.
• Ir más allá de lo funcional: No basta con validar que una función cumple con los requisitos; hay que cuestionar los riesgos de seguridad asociados.
• Fomentar la colaboración: Promover sesiones conjuntas entre QA y Seguridad permite que ambos equipos aprendan de cada hallazgo, incluyendo los falsos positivos.
• Apalancar herramientas: Utilizar herramientas como OWASP ZAP permite agregar un valor significativo al proceso de calidad con un esfuerzo de integración manejable, reutilizando el trabajo de automatización ya realizado.
Acceso a la charla de Richard
Fuera de la charla de Richard, te comparto conceptos
Por fuera del contenido ofrecido por Richard, quiero agregar a este tema algunos conceptos que se encuentran en el programa de estudios del ISTQB CT-STE.
Concepto de “vulnerabilidad” según ISTQB-STE
Una vulnerabilidad es una debilidad en un sistema, proceso, diseño, implementación o configuración que puede ser explotada por una amenaza para comprometer la confidencialidad, integridad o disponibilidad de un activo. Esto incluye tanto aspectos técnicos (como código inseguro o mal configurado) como humanos y organizacionales (como prácticas operativas deficientes).
Referencia oficial:
- Capítulo 1.1 – Niveles de seguridad de activos
- Capítulo 8.2 – Identificación y análisis de vulnerabilidades
- Capítulo 8.3 – Cierre de vulnerabilidades
- Capítulo 5.3 – Escenarios de ataque comunes
Recomendación práctica
Si estás trabajando en un equipo de proyectos que no ha abordado explícitamente la gestión de vulnerabilidades, o sea security testing, te sugiero que pienses y evalúes con tu equipo los siguientes aspectos:
- Iniciar un inventario de activos críticos → (Capítulo 1.1)
- Clasificarlos por nivel de sensibilidad → (alta/media/baja)
- Planificar pruebas de seguridad en etapas del ciclo de vida → (Capítulo 6)
- Aplicar estándares y automatización para su detección continua.
