Metodología de Pentesting Web con OWASP Top 10: Guía Práctica 2026

Introducción al Pentesting Web

Las aplicaciones web son el vector de ataque más común en incidentes de ciberseguridad. Según los informes anuales de Verizon DBIR, más del 40% de las brechas de datos involucran aplicaciones web como punto de entrada inicial. Un pentest web es una evaluación de seguridad controlada que simula ataques reales para identificar vulnerabilidades antes de que lo hagan los atacantes.

¿Por qué es esencial dominar el OWASP Top 10? Porque define el vocabulario común que usan pentesters, desarrolladores y equipos de seguridad en todo el mundo. Cuando identificas una vulnerabilidad como "A03:2021 — Injection", el equipo de desarrollo sabe inmediatamente a qué se refiere, qué estándares aplicar y cómo priorizar la remediación. Sin esta clasificación, los informes se vuelven ambiguos y las vulnerabilidades críticas pueden pasar desapercibidas entre hallazgos menores.

Además, el OWASP Top 10 no es solo una lista de referencia: es un marco de trabajo que estructura todo el proceso de pentesting web. Cada categoría incluye descripciones, escenarios de ataque, vectores de explotación y recomendaciones de prevención. Dominar este framework te permite diseñar planes de prueba sistemáticos en lugar de probar cosas al azar y esperar encontrar algo.

Referencia estándar: El OWASP Top 10 es la lista de las vulnerabilidades web más críticas, actualizada en 2021. Es el punto de partida para cualquier pentest web. Complementalo con el OWASP Web Security Testing Guide (WSTG) para metodologías de testing detalladas por categoría.

Setup del Entorno de Pentesting

Herramientas esenciales

# Kali Linux incluye todo preinstalado, pero también:

# Burp Suite Community (gratuito)
# https://portswigger.net/burp/releases

# OWASP ZAP (alternativa open source)
sudo apt install zaproxy

# Nikto — escáner de vulnerabilidades web
sudo apt install nikto

# SQLMap — automatización de SQL injection
sudo apt install sqlmap

# FFUF — fuzzing web (directory discovery, parameter fuzzing)
ffuf -u https://target.com/FUZZ -w /usr/share/wordlists/dirb/common.txt -ac

Laboratorio de práctica legal

NUNCA practiques en sitios reales sin autorización. Usa:

# DVWA (Damn Vulnerable Web Application)
docker run --rm -it -p 80:80 vulnerables/web-dvwa

# Juice Shop (OWASP)
docker run --rm -p 3000:3000 bkimminich/juice-shop

# WebGoat
docker run -p 8080:8080 -p 9090:9090 webgoat/goat-and-wolf

OWASP Top 10 2021 — Análisis y Testing

A01: Broken Access Control

Descripción: El control de acceso falla, permitiendo a usuarios acceder a datos o funciones no autorizadas. Esta categoría subió del puesto #5 en 2017 al #1 en 2021, convirtiéndose en la vulnerabilidad más prevalente encontrada en aplicaciones web reales. En el mundo real, esto se traduce en que cualquier usuario puede acceder al panel de administración, modificar datos de otros usuarios o ejecutar funciones privilegiadas sin autenticación.

Ejemplos reales: En 2019, Facebook tuvo un bug bounty donde un investigador descubrió que podía modificar parámetros en la API Graph para acceder a datos de millones de usuarios sin autenticación. Este tipo de IDOR masivo es exactamente lo que busca esta categoría. Otro caso famoso fue el breach de Capital One en 2019, donde un atacante explotó un misconfiguration en AWS WAF para evadir controles de acceso y acceder a datos de 100 millones de clientes.

Testing:

# Probar acceso a rutas admin sin autenticación
curl -i https://target.com/admin/dashboard
curl -i https://target.com/api/users/1234  # ¿Puedo ver datos de otro usuario?

# IDOR (Insecure Direct Object Reference)
# Cambiar ID en URL: /profile?id=100 → /profile?id=101
# ¿Ves datos de otro usuario? Es una vulnerabilidad IDOR

# Probar manipulación de JWT tokens
# Cambiar el campo "role" de "user" a "admin" en el payload
# Cambiar el "sub" (subject) para impersonar a otro usuario

# Forzar navegación de directorios
curl -i https://target.com/admin/../config/database.yml
curl -i "https://target.com/api/v1/users/../../admin/settings"

Remediación: Implementar controles de acceso en el servidor, no solo en el cliente. Usar principios de menor privilegio y validar permisos en cada endpoint.

A02: Cryptographic Failures

Descripción: Datos sensibles transmitidos o almacenados sin cifrado adecuado. Antes se llamaba "Sensitive Data Exposure" y fue renombrado para enfatizar la causa raíz: fallos en el diseño criptográfico, no solo en la exposición. Esto incluye contraseñas almacenadas en texto plano, conexiones HTTP sin TLS, algoritmos deprecados como MD5 o SHA1 para hashing de contraseñas, y claves API expuestas en código fuente o repositorios públicos de GitHub.

Ejemplos reales: LinkedIn en 2012 almacenaba contraseñas con SHA1 sin salt, lo que permitió a atacantes crackear millones de credenciales. Equifax en 2017 expuso datos sensibles porque su infraestructura no usaba TLS en varias partes internas. Estos casos muestran que los fallos criptográficos no son teóricos: tienen consecuencias masivas.

Testing:

# Verificar SSL/TLS con sslyze
sslyze --regular target.com

# Testssl.sh — análisis profundo de configuración TLS
bash testssl.sh target.com

# Buscar datos sensibles en respuestas HTTP
# Buscar: contraseñas, PAN, datos médicos, claves API en respuestas

# Verificar si hay cookies sin flag Secure o HttpOnly
# En Burp Suite: Proxy → HTTP History → revisar Set-Cookie headers

# Testear si se aceptan versiones obsoletas de TLS
nmap --script ssl-enum-ciphers -p 443 target.com

Remediación: Usar TLS 1.2+ en todas las conexiones, aplicar HSTS, cifrar datos en reposo con AES-256, y nunca almacenar contraseñas en texto plano — usar bcrypt, scrypt o Argon2.

A03: Injection (SQLi, XSS, Command Injection, LDAP Injection, etc.)

Descripción: Datos no confiables enviados a un intérprete como parte de un comando o consulta. Injection ha sido una de las categorías más peligrosas durante más de una década. Incluye SQL injection, XSS, command injection, LDAP injection, ORM injection y NoSQL injection. Cada tipo tiene su propio conjunto de técnicas, pero el principio es el mismo: el atacante inyecta código malicioso que el servidor interpreta como instrucciones legítimas.

Ejemplos reales: La vulnerabilidad SQLi en el site de la UEFA en 2020 permitió extraer datos de más de 50 millones de usuarios. Heartbleed (CVE-2014-0160) no es injection per se, pero el concepto de inyectar datos malformados en un servicio para extraer información confidencial es análogo. En 2021, la vulnerabilidad Log4Shell (CVE-2021-44228) demostró que el injection de JNDI podía comprometer millones de servidores Java en todo el mundo en cuestión de horas.

Testing manual básico:

# Inputs de prueba para detectar SQLi
' OR '1'='1
' OR '1'='1' --
' UNION SELECT NULL --
1; DROP TABLE users --

# Si el comportamiento de la aplicación cambia = posible SQLi

# Command injection payloads
; ls
| cat /etc/passwd
`whoami`
$(id)

# LDAP injection
*)(objectClass=*)
admin)(&)

Testing automatizado con SQLMap:

# SOLO en sistemas autorizados
sqlmap -u "https://target.com/product?id=1" --dbs
sqlmap -u "https://target.com/product?id=1" -D database_name --tables
sqlmap -u "https://target.com/product?id=1" --forms --batch --level=3
sqlmap -r request.txt --level=5 --risk=3 --dbs  # desde archivo de Burp

Remediación: Usar consultas parametrizadas / prepared statements en todos los casos. Nunca concatener input del usuario directamente en queries. Para XSS, sanitizar output y usar Content Security Policy (CSP).

A07: Identification and Authentication Failures

Descripción: La autenticación y gestión de sesiones son débiles, permitiendo a atacantes comprometer credenciales de usuarios o impersonar identidades. Esto incluye enumeración de usuarios mediante mensajes de error diferenciados, ausencia de mecanismos contra fuerza bruta, contraseñas por defecto, y tokens de sesión predecibles o que no se invalidan correctamente tras logout.

Testing:

# Enumeración de usuarios
# Si "usuario no existe" vs "contraseña incorrecta" → enumeración posible
# Automatizar con:
ffuf -u https://target.com/login -X POST -d "username=FUZZ&password=anything" \
  -w /usr/share/wordlists/seclists/Usernames/top-usernames-shortlist.txt \
  -H "Content-Type: application/x-www-form-urlencoded" -fc 401

# Fuerza bruta con Hydra (solo en sistemas autorizados)
hydra -l admin -P /usr/share/wordlists/rockyou.txt target.com http-post-form \
  "/login:username=^USER^&password=^PASS^:Invalid credentials"

# Verificar si el token de sesión cambia tras el login
# Verificar expiración de sesión
# Verificar logout completo (invalidación en servidor)

# Probar autenticación con JWT débil
# Algunos servidores aceptan JWT con "alg": "none" → bypass de verificación

Remediación: Implementar rate limiting, bloqueo tras intentos fallidos, MFA, y asegurar que los mensajes de error no revelen si el usuario existe.

XSS — Cross-Site Scripting (incluido en A03: Injection)

Descripción: XSS permite inyectar scripts en páginas que otros usuarios visualizan. Hay tres tipos principales: Stored XSS (el payload se almacena en la base de datos), Reflected XSS (el payload viene en la URL o parámetro y se refleja en la respuesta), y DOM-based XSS (la manipulación ocurre completamente del lado del cliente). El Stored XSS es el más peligroso porque afecta a todos los usuarios que visitan la página comprometida.

Testing básico:

// Payloads de prueba para XSS
<script>alert('XSS')</script>
<img src=x onerror=alert('XSS')>
"><script>alert(document.cookie)</script>
javascript:alert('XSS')

// Payloads más avanzados para evadir filtros
<svg onload=alert('XSS')>
<body onload=alert('XSS')>
<input onfocus=alert('XSS') autofocus>
<details open ontoggle=alert('XSS')>

// En Burp Suite: usar Repeater para probar cada input
// Buscar en: parámetros GET/POST, cabeceras HTTP, campos de formulario
// Probar también en campos que se renderizan en respuestas de error

Remediación: Sanitizar todo input del usuario, usar encoding al renderizar output, y desplegar Content Security Policy (CSP) como capa de defensa adicional.

Uso de Burp Suite para Pentesting Web

Burp Suite es el estándar de la industria para pentesting web:

Flujo básico de trabajo:
1. Configurar proxy (127.0.0.1:8080) en el navegador
2. Activar "Intercept" en Burp Proxy
3. Navegar por la aplicación para mapear todos los endpoints
4. Usar "Target > Site Map" para ver la estructura
5. Enviar requests a "Repeater" para modificar manualmente
6. Usar "Intruder" para fuzzing automatizado
7. Revisar "Scanner" (Pro) para vulnerabilidades automáticas

Generación del Informe de Pentesting

Un informe profesional incluye:

# Informe de Pentest — [Nombre Aplicación]
Fecha: XX/XX/XXXX | Clasificación: CONFIDENCIAL

## Resumen Ejecutivo
- Scope evaluado
- Hallazgos críticos (número por severidad)
- Recomendación general

## Hallazgos

### CRÍTICO: SQL Injection en /api/search
- **CVSS Score**: 9.8 (Critical)
- **Descripción**: El parámetro `q` no está sanitizado...
- **Evidencia**: [Captura de pantalla / Request-Response]
- **Impacto**: Extracción completa de base de datos
- **Remediación**: Usar prepared statements / parameterized queries
- **Referencia**: CWE-89, OWASP A03:2021

## Plan de Remediación Priorizado
| Prioridad | Vulnerabilidad | Esfuerzo | Plazo |
|-----------|---------------|----------|-------|
| 1 | SQL Injection | Medio | 1 semana |

Herramientas para Cada Categoría OWASP

No todas las herramientas sirven para todo. Mapear correctamente las herramientas a cada categoría OWASP te ahorrará tiempo y mejorará la cobertura de tu pentest.

# Instalación rápida de las más usadas
sudo apt install burpsuite zaproxy nikto sqlmap nuclei
pip install sslyze
go install github.com/ffuf/ffuf/v2@latest

Flujo de Trabajo de un Pentest Web

Un pentest web profesional no consiste en lanzar herramientas al azar. Sigue un flujo estructurado que garantiza cobertura completa y resultados reproducibles.

Fase 1: Recopilación de Información (Recon)

El 70% del tiempo de un pentester senior se dedica a entender el objetivo antes de tocar una sola herramienta de ataque. Esta fase determina la calidad de todo el resto del engagement.

# Reconocimiento passive (sin tocar el objetivo)
whois target.com
dig target.com ANY
theHarvester -d target.com -b google,linkedin,crtsh

# Reconocimiento active (con autorización)
nmap -sC -sV -oA target_enum target.com
ffuf -u https://target.com/FUZZ -w /usr/share/wordlists/dirb/common.txt -ac

# Descubrimiento de subdominios
subfinder -d target.com -o subdomains.txt
httpx -l subdomains.txt -o live_subdomains.txt

Fase 2: Enumeración y Mapeo

Una vez tienes los endpoints visibles, necesitas entender la lógica de la aplicación: qué hace cada endpoint, qué parámetros acepta, cómo maneja las sesiones y qué tecnologías usa por debajo.

# Configurar Burp Suite como proxy y navegar toda la aplicación
# Revisar Target > Site Map para entender la estructura
# Identificar tecnologías: Wappalyzer o builtwith
# Identificar frameworks, CMS, servidores, lenguajes de programación

Fase 3: Análisis de Vulnerabilidades

Con la aplicación mapeada, se ejecutan tests específicos para cada categoría OWASP. No se prueban todos los vectores en todos los endpoints — se priorizan los que tienen mayor impacto potencial según la fase de recon.

Fase 4: Explotación Controlada

Una vez identificada una vulnerabilidad, se valida con explotación mínima necesaria para demostrar impacto. No se extraen datos reales de producción a menos que sea estrictamente necesario y esté dentro del alcance acordado.

Fase 5: Documentación y Reporte

Cada hallazgo se documenta con evidencia reproducible: requests, responses, capturas de pantalla y pasos detallados. Un hallazgo sin evidencia reproductible no es un hallazgo válido.

Errores Comunes en Pentesting Web

Incluso pentesters experimentados cometen errores que reducen la efectividad del engagement o generan resultados incompletos. Estos son los más frecuentes:

1. No entender la lógica de negocio antes de atacar. Una aplicación de banca online tiene flujos muy diferentes a un e-commerce. Si no entiendes cómo se supone que funciona la aplicación, no podrás identificar cuándo algo está roto. Dedica tiempo a usar la aplicación como usuario normal antes de开始 testing.

2. Depender demasiado de herramientas automatizadas. SQLMap y Nuclei son excelentes, pero solo encuentran lo que están programados para buscar. La mayoría de las vulnerabilidades de lógica de negocio (roken access control, insecure design) requieren análisis manual y creatividad. Las herramientas automatizadas cubren quizás el 30% de un pentest completo.

3. Ignorar los headers HTTP. Muchos pentesters se enfocan solo en parámetros de formulario y olvidan revisar cabeceras como Authorization, Cookie, X-Forwarded-For, y Cache-Control. Burp Suite te muestra todas las cabeceras — úsalas.

4. No probar la aplicación móvil asociada. Si la aplicación web tiene una API y una versión móvil, la API es frecuentemente menos protegida que la interfaz web. Siempre prueba la API directamente con herramientas como Postman o Burp Suite.

5. Olvidar el alcance. Un error que puede terminar en problemas legales. Siempre revisa el scope del engagement antes de cada test. Si el alcance dice "app.example.com", no testees "api.example.com" sin confirmar.

Cómo Reportar Hallazgos

Un informe de pentesting es el producto final que justifica todo el trabajo. Si el informe es malo, el pentest fue inútil. Aquí tienes la estructura estándar y los errores más comunes al reportar.

Estructura del Informe

# Informe de Pentest — [Nombre Aplicación]
Fecha: XX/XX/XXXX | Clasificación: CONFIDENCIAL
## Resumen Ejecutivo
- Scope evaluado
- Hallazgos críticos (número por severidad)
- Recomendación general
## Metodología
- Framework utilizado (OWASP WSTG, PTES, etc.)
- Herramientas empleadas
- Periodo de testing
## Hallazgos

### CRÍTICO: SQL Injection en /api/search
- **CVSS Score**: 9.8 (Critical)
- **CWE**: CWE-89
- **OWASP Category**: A03:2021 — Injection
- **Descripción técnica**: El parámetro `q` no está sanitizado...
- **Evidencia**: [Request/Response de Burp Suite]
- **Impacto**: Extracción completa de base de datos
- **Remediación**: Usar prepared statements / parameterized queries
- **Referencia**: CWE-89, OWASP A03:2021

### ALTO: Broken Access Control en /api/users/{id}
- **CVSS Score**: 8.1 (High)
- **CWE**: CWE-639
- **OWASP Category**: A01:2021 — Broken Access Control
- **Descripción**: ...
- **Evidencia**: ...
- **Impacto**: ...
- **Remediación**: ...

## Plan de Remediación Priorizado
| Prioridad | Vulnerabilidad | CVSS | Esfuerzo | Plazo |
|-----------|---------------|------|----------|-------|
| 1 | SQL Injection | 9.8 | Medio | 1 semana |
| 2 | Broken Access Control | 8.1 | Bajo | 3 días |

## Apéndice
- Listado completo de endpoints evaluados
- Resultados de escaneo automatizado
- Tokens y credenciales usados (si aplica)

Errores comunes al reportar

• No incluir evidencia reproducible. Si el lector no puede repetir el hallazgo siguiendo tus pasos, el hallazgo no es válido.
• Usar lenguaje ambiguo. Evita frases como "podría ser vulnerable a". Sé preciso: "el parámetro X permite inyección SQL because...".
• Omitir la remediación. Un informe sin recomendaciones accionables es una lista de problemas sin solución. Incluye código corregido cuando sea posible.
• No priorizar. Un informe con 50 hallazgos sin clasificación de severidad overwhelming. Usa CVSS para priorizar y agrupa hallazgos similares.
• Olvidar el resumen ejecutivo. Los directores de seguridad no leen 50 páginas técnicas. El resumen ejecutivo debe caber en una página y comunicar el riesgo de negocio.

Recursos para Practicar

• PortSwigger Web Security Academy — gratuito, excelente
• HackTheBox — laboratorios de pentesting
• TryHackMe — rutas de aprendizaje guiado
• PentesterLab — ejercicios de código vulnerable

Recuerda: El pentesting sin autorización es un delito. Todas las técnicas aquí descritas deben aplicarse únicamente en entornos de prueba o con permiso escrito del propietario del sistema.

Artículos Relacionados

• SQL Injection: Guía Completa para Explotar y Prevenir — Profundiza en la vulnerabilidad más peligrosa de la OWASP Top 10 con técnicas de explotación y remediación.
• API Security y OWASP Top 10 para APIs — Extiende tu conocimiento OWASP al testing de seguridad en APIs REST y GraphQL modernas.
• Kali Linux: Las 20 Herramientas Esenciales para Pentesting — Domina las herramientas de Kali que necesitas para ejecutar un pentest web completo.
• Hacking Ético: Salario, Certificaciones y Cómo Empezar — Salarios, certificaciones CEH/OSCP/PNPT y hoja de ruta

🔧 Herramienta relacionada: Aprende a usar [Burp Suite] paso a paso en nuestra guía completa de herramientas.