Las pruebas de seguridad han evolucionado de ser un nicho especializado a una competencia esencial para los ingenieros de QA. Con las brechas de datos costando a las empresas millones y dañando reputaciones irreparablemente, la responsabilidad de identificar vulnerabilidades de seguridad ahora se extiende más allá de los equipos de seguridad dedicados a todos los involucrados en el desarrollo de software. Esta guía completa equipa a los ingenieros de QA con conocimiento práctico de los fundamentos de pruebas de seguridad, vulnerabilidades comunes y las herramientas necesarias para descubrir y validar problemas de seguridad.
Entendiendo Security Testing en el Contexto QA
Security testing es la práctica de identificar vulnerabilidades, amenazas y riesgos en sistemas de software que podrían llevar a acceso no autorizado, brechas de datos, compromiso del sistema o denegación de servicio. A diferencia de las pruebas funcionales que validan que las características funcionan según lo previsto, las pruebas de seguridad examinan qué sucede cuando las características son abusadas, evadidas o explotadas.
La Mentalidad de Security Testing
Las pruebas de seguridad efectivas requieren un cambio de mentalidad del pensamiento de QA tradicional:
Mentalidad QA tradicional:
- “¿Esta característica funciona según lo documentado?”
- “¿Qué sucede cuando sigo el camino feliz?”
- “¿Pueden los usuarios legítimos lograr sus objetivos?”
Mentalidad de security (como se discute en Penetration Testing Basics for QA Testers) testing:
- “¿Cómo se puede abusar de esta característica?”
- “¿Qué sucede cuando deliberadamente proporciono entrada maliciosa?”
- “¿Puedo evadir la autenticación o autorización?”
- “¿Qué datos sensibles están expuestos?”
- “¿Qué sucede si manipulo llamadas API o solicitudes del navegador?”
Security (como se discute en OWASP ZAP Automation: Security Scanning in CI/CD) Testing vs. Penetration Testing
Security (como se discute en SQL Injection and XSS: Finding Vulnerabilities) testing es una categoría amplia que incluye:
- Análisis estático (revisión de código, herramientas SAST)
- Análisis dinámico (pruebas en tiempo de ejecución, herramientas DAST)
- Revisiones de configuración
- Modelado de amenazas
- Validación de cumplimiento
Penetration testing (o ethical hacking) es un tipo específico de pruebas de seguridad donde los testers intentan activamente explotar vulnerabilidades para demostrar escenarios de ataque del mundo real.
Como ingeniero de QA, te enfocarás principalmente en escaneo de seguridad automatizado, identificación básica de vulnerabilidades y pruebas de regresión de seguridad.
El OWASP Top 10: Tu Fundamento en Security Testing
El OWASP Top 10 es el documento de concientización definitivo para la seguridad de aplicaciones web. Publicado por el Open Web Application Security Project (OWASP), representa los riesgos de seguridad más críticos para aplicaciones web basándose en datos de cientos de organizaciones y miles de aplicaciones.
OWASP Top 10 (Edición 2021)
A01:2021 – Broken Access Control
Qué es: Broken Access Control ocurre cuando los usuarios pueden actuar fuera de sus permisos previstos—accediendo a datos de otros usuarios, modificando datos que no deberían, o realizando funciones administrativas sin autorización adecuada.
Manifestaciones comunes:
- Insecure Direct Object References (IDOR): URLs como
/api/users/12345
donde cambiar el ID expone datos de otros usuarios - Missing function-level access control: Paneles de administración accesibles para usuarios regulares
- Forced browsing: Acceso a páginas adivinando URLs (e.g.,
/admin
,/reports
) - Elevation of privilege: Usuarios regulares obteniendo derechos de administrador mediante manipulación de parámetros
Cómo probar:
- Probar control de acceso vertical: Inicia sesión como usuario de bajo privilegio e intenta acceder a funciones de administrador
- Probar control de acceso horizontal: Como Usuario A, intenta acceder a recursos del Usuario B manipulando IDs o tokens
- Probar forced browsing: Intenta acceder a URLs restringidas directamente sin autenticación
- Probar manipulación de parámetros: Modifica
role=user
arole=admin
en solicitudes
Ejemplo de caso de prueba:
# Solicitud normal como Usuario 12345
GET /api/users/12345/profile HTTP/1.1
Authorization: Bearer <user_12345_token>
# Ataque: Intentar acceder al perfil del Usuario 99999
GET /api/users/99999/profile HTTP/1.1
Authorization: Bearer <user_12345_token>
# Respuesta segura esperada: 403 Forbidden
# Respuesta vulnerable: 200 OK con datos del Usuario 99999
A02:2021 – Cryptographic Failures
Qué es: Fallos relacionados con criptografía (o falta de ella) que exponen datos sensibles. Esto incluye datos transmitidos sin cifrado, algoritmos de cifrado débiles, gestión inadecuada de claves y falta de cifrado en reposo.
Cómo probar:
- Verificar aplicación de HTTPS: Intenta acceder a la aplicación vía HTTP—debería redirigir a HTTPS
- Verificar validez del certificado: Usa herramientas de desarrollador del navegador o SSL Labs
- Inspeccionar datos almacenados: Verifica cookies, local storage, session storage para datos sensibles
- Revisar almacenamiento de contraseñas: Verifica que las contraseñas estén hasheadas con algoritmos fuertes (bcrypt, Argon2, PBKDF2)
A03:2021 – Injection
Qué es: Los defectos de inyección ocurren cuando datos no confiables se envían a un intérprete como parte de un comando o consulta.
SQL Injection profundo:
SQL Injection ocurre cuando la entrada del usuario se incorpora en consultas SQL sin sanitización o parametrización adecuada.
Código vulnerable (Python):
# VULNERABLE - ¡Nunca hagas esto!
username = request.form['username']
password = request.form['password']
query = f"SELECT * FROM users WHERE username='{username}' AND password='{password}'"
cursor.execute(query)
Payload de ataque:
Username: admin' --
Password: anything
# Consulta resultante:
SELECT * FROM users WHERE username='admin' -- ' AND password='anything'
# El -- comenta el resto de la consulta, evadiendo la verificación de contraseña
Cómo probar SQL Injection:
# Login bypass
' OR 1=1--
admin' --
' OR 'x'='x
# Union-based injection
' UNION SELECT NULL, NULL, NULL--
' UNION SELECT username, password, NULL FROM users--
# Blind SQL injection (time-based)
'; IF (1=1) WAITFOR DELAY '00:00:05'--
Código seguro (consulta parametrizada):
# SEGURO - Siempre usa consultas parametrizadas
username = request.form['username']
password = request.form['password']
query = "SELECT * FROM users WHERE username=? AND password=?"
cursor.execute(query, (username, password))
A04:2021 – Insecure Design
Qué es: Fallos de seguridad en el diseño y arquitectura de la aplicación, antes de que se escriba cualquier código.
Ejemplos:
- Sin rate limiting en restablecimiento de contraseña permitiendo fuerza bruta
- Preguntas de recuperación de credenciales que son fácilmente adivinables
- Fallos de lógica de negocio
A05:2021 – Security Misconfiguration
Qué es: Configuraciones predeterminadas inseguras, setups incompletos, almacenamiento en la nube abierto, headers HTTP mal configurados, mensajes de error verbosos revelando información sensible.
Cómo probar:
- Verificar credenciales predeterminadas: Prueba
admin/admin
,admin/password123
- Sondear paneles de administración expuestos:
/admin
,/administrator
,/phpmyadmin
- Desencadenar errores: Envía entrada malformada para revelar stack traces
- Verificar headers de seguridad HTTP: Usa SecurityHeaders.com
Headers de seguridad esenciales:
Content-Security-Policy: default-src 'self'
X-Frame-Options: DENY
Strict-Transport-Security: max-age=31536000
X-Content-Type-Options: nosniff
A06:2021 – Vulnerable and Outdated Components
Qué es: Usar bibliotecas, frameworks u otros componentes de software con vulnerabilidades conocidas.
Cómo probar:
# Verificar dependencias npm para vulnerabilidades
npm audit
# Verificar paquetes Python
pip-audit
A07:2021 – Identification and Authentication Failures
Qué es: Fallos en mecanismos de autenticación permitiendo a atacantes comprometer contraseñas, claves o tokens de sesión.
Cómo probar:
- Probar política de contraseñas: Intenta contraseñas débiles como
123456
,password
- Probar protección de fuerza bruta: Intenta múltiples inicios de sesión fallidos
- Gestión de sesión: Verifica que los tokens de sesión sean aleatorios, seguros y expiren
A08:2021 – Software and Data Integrity Failures
Qué es: Código e infraestructura que no protegen contra violaciones de integridad.
A09:2021 – Security Logging and Monitoring Failures
Qué es: Registro, detección, monitoreo y respuesta insuficientes a eventos de seguridad.
A10:2021 – Server-Side Request Forgery (SSRF)
Qué es: SSRF ocurre cuando una aplicación web obtiene un recurso remoto sin validar la URL proporcionada por el usuario.
Cross-Site Scripting (XSS): Tipos y Pruebas
Cross-Site Scripting (XSS) permite a los atacantes inyectar scripts maliciosos en páginas web vistas por otros usuarios.
Tipos de XSS
Reflected XSS
Script malicioso se refleja desde un servidor web, típicamente en resultados de búsqueda, mensajes de error.
Ejemplo:
GET /search?q=<script>alert('XSS')</script>
Stored XSS
Script malicioso se almacena permanentemente en el servidor objetivo.
DOM-Based XSS
La vulnerabilidad existe en código del lado del cliente en lugar del lado del servidor.
Probando XSS
Payloads básicos de XSS:
<script>alert('XSS')</script>
<img src=x onerror=alert('XSS')>
<svg/onload=alert('XSS')>
<iframe src="javascript:alert('XSS')">
Payloads avanzados de XSS:
# Variación de mayúsculas/minúsculas
<ScRiPt>alert('XSS')</sCrIpT>
# Codificación HTML
<img src=x onerror="alert('XSS')">
# Usando backticks
<img src=x onerror=`alert('XSS')`>
Cross-Site Request Forgery (CSRF)
CSRF engaña a usuarios autenticados para ejecutar acciones no deseadas en una aplicación web donde están actualmente autenticados.
Cómo funciona CSRF:
- Usuario inicia sesión en sitio legítimo (bank.com)
- Usuario visita sitio malicioso (attacker.com)
- Sitio malicioso desencadena una solicitud a bank.com
- Navegador incluye automáticamente cookies de autenticación
- Bank.com procesa la solicitud como si el usuario la iniciara
Probando CSRF
Verificar tokens CSRF:
<form action="/transfer" method="POST">
<input type="hidden" name="csrf_token" value="random_token">
<button type="submit">Transfer</button>
</form>
Probar protección CSRF:
- Enviar formularios sin token CSRF
- Usar token CSRF de una sesión diferente
- Usar tokens CSRF expirados
Herramientas de Security Testing
OWASP ZAP (Zed Attack Proxy)
OWASP ZAP es la herramienta gratuita de pruebas de seguridad más popular del mundo.
Características clave:
- Proxy de intercepción
- Escáner automatizado para vulnerabilidades comunes
- Escaneo activo y pasivo
- Spider/crawler para mapear estructura de aplicación
- Fuzzer para probar validación de entrada
Comenzando con ZAP:
# Instalación
brew install --cask owasp-zap # macOS
apt install zaproxy # Ubuntu/Debian
Flujo de trabajo básico:
1. Configurar navegador para usar ZAP como proxy (localhost:8080)
2. Navegar tu aplicación normalmente
3. Ejecutar escaneo automatizado
4. Revisar hallazgos en pestaña Alerts
5. Generar informe
Burp Suite
Burp Suite es el toolkit estándar de la industria para pruebas de seguridad de aplicaciones web.
Características clave:
- Proxy de intercepción potente
- Escáner (solo edición Professional)
- Repeater para manipular y reenviar solicitudes
- Intruder para ataques automatizados
- Decoder para codificación/decodificación de datos
Configuración de proxy de Burp:
1. Burp Suite → Proxy → Options → Interface: 127.0.0.1:8080
2. Navegador → Configuración de proxy → Manual: localhost:8080
3. Importar certificado CA de Burp al navegador
Otras Herramientas Útiles
Nikto - Escáner de servidor web
nikto -h https://example.com
SQLMap - Herramienta automatizada de SQL injection
sqlmap -u "https://example.com/page?id=1" --dbs
Nmap - Escáner de red
nmap -sV -sC example.com
Security Testing en Pipelines CI/CD
Integrar pruebas de seguridad en CI/CD asegura que las vulnerabilidades se detecten temprano.
# .github/workflows/security.yml
name: Security Scan
on: [push, pull_request]
jobs:
security:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v2
- name: Run Bandit
run: |
pip install bandit
bandit -r . -f json -o bandit-report.json
- name: ZAP Baseline Scan
uses: zaproxy/action-baseline@v0.6.1
with:
target: 'https://staging.example.com'
Mejores Prácticas
1. Adopta una mentalidad security-first
- Piensa como un atacante
- Cuestiona suposiciones sobre límites de confianza
2. Prueba temprano y frecuentemente
- Integra pruebas de seguridad en cada sprint
- Usa herramientas de pruebas de seguridad en CI/CD
3. Mantente actualizado sobre vulnerabilidades
- Sigue actualizaciones de OWASP Top 10
- Suscríbete a newsletters de seguridad
4. Colabora con equipos de seguridad
- Asiste a capacitaciones de seguridad
- Participa en programas de bug bounty
5. Documenta y rastrea hallazgos
- Usa calificaciones de severidad consistentes
- Proporciona pasos de reproducción claros
6. Prueba en entornos no productivos primero
- Nunca pruebes en producción sin autorización explícita
- Usa entornos dedicados de pruebas de seguridad
7. Entiende los límites legales y éticos
- Solo prueba sistemas que tienes autorización para probar
- Sigue prácticas de divulgación responsable
Conclusión
Las pruebas de seguridad ya no son opcionales—es una responsabilidad fundamental de la ingeniería de QA moderna. Desarrollar competencia en comprender el OWASP Top 10, probar vulnerabilidades comunes y usar herramientas como OWASP ZAP y Burp Suite mejorará significativamente tu valor como ingeniero de QA y mejorará la postura de seguridad de las aplicaciones que pruebas.
La seguridad es un viaje continuo, no un destino. Comienza pequeño, enfócate en las vulnerabilidades más críticas primero y construye progresivamente tu experiencia en pruebas de seguridad.