Por Qué las Pruebas de Seguridad Importan para QA
Las brechas de seguridad cuestan a las empresas un promedio de $4.45 millones por incidente. Más allá del impacto financiero, destruyen la confianza del cliente, generan sanciones regulatorias y pueden terminar carreras.
Como ingeniero QA, las pruebas de seguridad son tu responsabilidad. No necesitas ser un hacker ético certificado, pero debes entender los principios de seguridad lo suficiente para detectar vulnerabilidades comunes antes de que lleguen a producción.
La Tríada CIA
La tríada CIA es la base de la seguridad de la información. Cada requisito de seguridad se mapea a una de estas tres propiedades.
Confidencialidad
Los datos solo deben ser accesibles para usuarios autorizados.
Qué probar: ¿Pueden los usuarios acceder a datos de otros usuarios (IDOR)? ¿Los datos sensibles están cifrados? ¿Las API filtran datos innecesarios? ¿Los mensajes de error exponen información sensible?
Integridad
Los datos no deben ser alterados — accidental o maliciosamente.
Qué probar: ¿Pueden los usuarios modificar datos sin permiso? ¿La validación se hace del lado del servidor? ¿Están protegidas las consultas contra SQL injection?
Disponibilidad
Los sistemas deben estar accesibles cuando los usuarios los necesitan.
Qué probar: ¿Se puede crashear el sistema con una solicitud malformada? ¿Hay límites de tasa? ¿El sistema maneja el agotamiento de recursos correctamente?
Tipos de Pruebas de Seguridad
| Tipo | Qué Hace | Quién | Cuándo |
|---|---|---|---|
| Escaneo de Vulnerabilidades | Escaneo automatizado de vulnerabilidades conocidas | Equipo QA/DevOps | Cada sprint |
| Pruebas de Penetración | Intento manual de explotar vulnerabilidades | Especialistas | Trimestral |
| Auditoría de Seguridad | Revisión de controles y políticas | Auditores | Anual |
| Revisión de Código | Inspección del código fuente | Desarrolladores + seguridad | Durante desarrollo |
| SAST | Análisis estático del código | Pipeline CI/CD | Cada commit |
| DAST | Testing dinámico en runtime | CI/CD o QA | Cada deployment |
| Modelado de Amenazas | Identificación sistemática de amenazas | Arquitectura + seguridad | Fase de diseño |
Mentalidad de Pruebas de Seguridad
| Mentalidad Funcional | Mentalidad de Seguridad |
|---|---|
| “¿Funciona el login?” | “¿Puedo eludir el login?” |
| “¿Se puede enviar el formulario?” | “¿Puedo enviar datos maliciosos?” |
| “¿La API retorna datos correctos?” | “¿Puedo acceder a datos de otros usuarios?” |
| “¿Funciona la carga de archivos?” | “¿Puedo subir un archivo malicioso?” |
| “¿La búsqueda retorna resultados?” | “¿Puedo inyectar SQL en la búsqueda?” |
Categorías Comunes de Vulnerabilidades
Fallos de autenticación: Credenciales por defecto, sin bloqueo de cuenta, contraseñas débiles, sin MFA.
Fallos de autorización: Escalamiento horizontal de privilegios (acceder a datos de otro usuario), escalamiento vertical (acceder a funciones admin como usuario regular), IDOR.
Fallos de validación de entrada: SQL injection, XSS, command injection, path traversal, XXE.
Exposición de datos: Datos sensibles en URLs, respuestas API con campos innecesarios, mensajes de error revelando internos, falta de cifrado.
Pruebas de Seguridad como Ingeniero QA
No necesitas ser pentester para agregar valor. Verificaciones que todo QA debe hacer:
- Probar autorización: Acceder a recursos sin autenticación. Cambiar IDs en URLs.
- Probar validación de entrada: Caracteres especiales (
' " < > ; --), strings muy largos, tipos inesperados. - Verificar mensajes de error: No deben revelar stack traces, nombres de BD, rutas.
- Verificar HTTPS: Todas las páginas y API deben usar HTTPS.
- Probar gestión de sesiones: Sesiones expiran, tokens no son predecibles, logout invalida la sesión.
- Revisar headers: Headers de seguridad (CSP, X-Frame-Options, HSTS).
Ejercicio: Evaluación de Riesgos de Seguridad
Dado el diseño de una aplicación web, identifica riesgos de seguridad potenciales en las tres dimensiones de la tríada CIA.
Aplicación: Portal de Banca en Línea
Funcionalidades: Login con email/contraseña, vista de saldo, transferencias entre cuentas, historial de transacciones, descarga de estados de cuenta PDF, configuración de perfil con información personal.
Tarea
Para cada funcionalidad, identifica: un riesgo de confidencialidad, uno de integridad, uno de disponibilidad, la severidad y una mitigación recomendada.
Pista: Piensa Como un Atacante
Para cada funcionalidad, pregunta: “¿Qué pasa si alguien intenta…” — acceder sin permiso, modificar datos, enviar datos maliciosos, sobrecargar el sistema, interceptar comunicaciones.
Solución: Evaluación de Riesgos
| Funcionalidad | CIA | Riesgo | Severidad | Mitigación |
|---|---|---|---|---|
| Login | C | Fuerza bruta para adivinar contraseñas | Crítico | Bloqueo después de 5 intentos + CAPTCHA |
| Login | I | Credential stuffing con contraseñas filtradas | Crítico | MFA, verificación de contraseñas filtradas |
| Login | A | Ataque DoS al endpoint de login | Alto | Rate limiting (10 req/min por IP) |
| Vista de saldo | C | IDOR — cambiar ID de cuenta para ver otras | Crítico | Verificación de propiedad del lado del servidor |
| Transferencias | I | Condición de carrera permitiendo transferencias dobles | Crítico | Bloqueo a nivel de BD, claves de idempotencia |
| Historial | C | SQL injection en filtro de fecha | Crítico | Consultas parametrizadas, validación de entrada |
| C | Path traversal en parámetro de nombre de archivo | Alto | Whitelist de nombres permitidos | |
| Perfil | I | XSS via campo de nombre | Alto | Codificación de salida, header CSP |
Top 3 prioridades: (1) IDOR en vista de saldo, (2) Condición de carrera en transferencias, (3) SQL injection en historial.
Tips Profesionales
- Shift Left en Seguridad: Integra pruebas de seguridad en cada sprint, no solo antes de releases.
- Aprende Burp Suite: Incluso habilidades básicas (interceptar solicitudes, modificar parámetros) mejoran dramáticamente tu capacidad de testing de seguridad.
- Monitorea Bases de CVE: Suscríbete a alertas CVE para tu stack tecnológico.
- Programa de Security Champions: Promueve un champion de seguridad en cada equipo.
- Nunca pruebes seguridad en producción: Las pruebas de seguridad pueden causar daño. Usa siempre un entorno dedicado.