Checklist Bug Bounty

Metodología de recopilación de información, enumeración, análisis y descubrimiento de vulnerabilidades en BBP, VDP o Pentesting Web. Basado en experiencia + metodología WSTG.

---

Importante:

Recordar que siempre antes de recopilar información, ejecutar comandos arrancar herramientas o analizar los flujos de un objetivo, es recomendable revisarlo manualmente como un usuario normal (sin mentalidad de hunting). Esto con el fin de conocer la funcionalidad principal del entorno web y comenzar a plantear posibles ideas desde antes de comenzar la auditoría. Por otra parte, considerar que este checklist no es infalible, ni tampoco un proceso paso a paso estrictamente invariable para un proceso de auditoría web, si no que es una recopilación de ciertos procedimientos mínimos que se deben tener en consideración al momento de abordar un tópico específico mientras se realiza la revisión de un sitio.

*: Ejecución también asociada a Pentesting Black Box

**: Ejecución también asociada a procesos de Hardening o Pentesting White Box

---

1. Information Gathering

• Censys [F]

• Chaos Project Discovery

• CRT [F]

• Virus Total [F/R]

• Security Trails [R]

• Builtwith

• CentralOps

• DNSlytics

• DNS dumpster

• Hacker Target Tools

• Shodan

• URL Scan

• Visual Ping (SANDBOX)

• View DNS

• Wayback Machine

• Web Check

1.2 Recon / OSINT

• Realizar Dorking

• Realizar OSINT

• Revisar plataformas (RRSS, foros, repos) por credenciales expuestas o información sensible

• Verificar contenido en pastebins y sitios similares

1.3 Fingerprinting a sitio web

• Identificar tipo y versión del servidor web

• Enumerar infraestructura del sitio con (port scanning con Nmap o Rustscan)

• Enumerar registros DNS

• Probar DNS Zone Transfer

• Enumerar subdominios

1.4 Metafiles y archivos sensibles

• Revisar robots.txt, sitemap.xml, humans.txt, security.txt

• Buscar archivos de configuración (.git, .svn, /.DS_Store)

• Buscar archivos de respaldo o versiones antiguas (.bak, .old, .tmp)

1.5 Mapeo de contenidos y rutas

• Identificar tecnologías y frameworks utilizados con httpx, Wappalyzer o WhatWeb

• Revisar cookies y headers HTTP para descubrir nombres de frameworks o versiones

• Realizar crawling y fuzzing web para descubrir estructura del sitio por URLs

1.6 Identificar inputs y roles del sitio

• Detectar parámetros, formularios y métodos HTTP soportados

• Verificar diferencias en el contenido según el User-Agent o headers

• Identificar posibles roles de usuarios y funcionalidades asociadas (admin, user, guest)

1.7 Information Disclosure y Data Leaks

• Analizar posibles Disclosure de versiones en cabeceras (Server, X-Powered-By)

• Revisar código fuente en busca de posibles Leaks con datos sensibles como claves, tokens o contraseñas

• Buscar archivos .git, .env, source maps, etc

• Para todos los puntos anteriores analizar posibles divulgaciones de información asociadas al dominio: credenciales, información sensible, versiones de software, tecnologías con CVEs o exploits públicos, etc

---

2. Configuration & Deployment Management Testing

2.1 Configuración del servidor

• Realizar detección de WAF

• Detectar IP original detrás del WAF

• Probar credenciales por defecto o dirigidas a tecnología en paneles de administración

• Verificar si el servidor está preparado para manejar ataques DoS (*)

2.2 Configuración de aplicación/plataforma

• Asegurar que solo estén activos los módulos y servicios necesarios (**)

• Revisar logs y posibles fugas de información sensible en registros (**)

• Verificar si se exponen capturas de error internas (stack traces) a usuarios sin autenticación mediante errores no controlados

• Analizar si hay datos de testing en entornos de producción y viceversa (*)

2.3 Enumerar interfaces de administración

• Intentar descubrir URLs de paneles admin, aplicaciones de terceros en el mismo servidor

• Revisar rutas /admin, /manager, /console, etc

• Verificar protección de acceso

2.4 HTTP Verb Tampering

• Verificar si métodos HTTP no convencionales están activos

• Probar XST (Cross-Site Tracing) si soporta TRACE para revelar headers confidenciales

• Probar HTTP Verb Tampering

2.5 Políticas de seguridad y encabezados

• Comprobar uso correcto de HSTS

• Asegurar no acceder vía HTTP si política requiere HTTPS

• Revisar Content Security Policy (CSP)

• Revisar X-Frame-Options, X-XSS-Protection, X-Content-Type-Options

• Probar vulnerabilidad Clickjacking

• Revisar si se implementa adecuadamente Path Confusion

• Revisar políticas de Adobe Flash crossdomain.xml y Silverlight clientaccesspolicy.xml

• Confirmar que no otorgan privilegios excesivos a dominios externos

2.6 Permisos de archivos y directorios

• Probar Directory Listing (tecnología Wordpress o servidores Apache/Nginx mal configurados)

• Revisar que ficheros con información sensible por tecnología tengan permisos restrictivos o no sean accesibles

2.7 Subdomain Takeover

• Probar Subdomain Takeover

2.8 Cloud Storage

• Revisar buckets de AWS S3, Google Cloud Storage o Azure Blob por accesos públicos o configuraciones inseguras

2.9 Web Cache Poisoning

• Probar técnicas de PS

• Analizar headers de cache

• Probar Web Cache Poisoning

• Probar Web Cache Deception (Probar técnicas de PS) si la aplicación sufre Cache deception u otros problemas que permitan devolver respuestas maliciosas a otros usuarios

2.10 CRLF

• Probar CRLF sobre todos los headers de la consulta

• Inyectar nuevos headers y anidar sentencias CRLF con inyección de nuevos headers extra

2.11 HTTP Host Header Injection

• Probar técnicas de PS

• Duplicar headerHost en una petición

• Verificar prioridad de headers Host duplicados

• Inyectar header host alternativo X-Injected-Header: Valor

• Probar caracteres Unicode/Punycode en el Host (xn--ejemplo-4za.com)

• Probar inyección de headers alternativos para bypass de Host original (X-Forwarded-Host, X-Forwarded-For, X-Forwarded-Server, X-Host, X-Server, Forwarded, X-Original-Host, Referer )

• Omitir header Host y usar solo usar headers alternativos

• Analizar si la app genera enlaces o cabeceras Location: basadas en el encabezado Host

• Inyectar URL original en línea principal y alterar header Host

• Inyectar URL original con path y query sobre el encabezado Host y referenciar path raíz en línea principal

• Validar si la aplicación mezcla contenido o funciones esperando un subdominio legítimo

• Enviar Host: dom.com:8443 (u otro puerto) para analizar redireccionamientos hacia servicio interno

• Revisar si se vulneran restricciones de firewall o se exponen paneles de control no públicos

2.12 HTTP Request Smuggling

• Probar técnicas de PS

• Probar insertar cabeceras extra con \r o sentencias CRLF

• Evaluar si proxies o WAFs se confunden y generan comportamientos inesperados

• Enviar te chunked + content-length conflictiva con sobreescritura de chunk extents (0\r\n donde no se espera)

• Probar ofuscación de mayúsculas/minúsculas en nombres de cabeceras

• Forzar Connection: keep-alive y luego inyectar datos adicionales en la misma conexión para manipular la siguiente petición

• Analizar si se puede causar Response Splitting para inyectar cabeceras en la respuesta del servidor

• Probar estructuras CL.TE, TE.TE, TE.CL, CL.0, etc

---

3. Authentication Testing

3.1 Credenciales y canales cifrados

• Comprobar si el login emite tráfico solo a través de HTTPS

• Revisar si contraseñas, tokens o keys se exponen por HTTP

3.2 Credenciales por defecto

• Probar logins típicos (admin:admin, root:root)

• Revisar documentación o nombres de la empresa como credenciales (filtraciones, OSINT)

• Revisar contraseñas por defecto en servicios WordPress, phpMyAdmin, etc

3.3 Mecanismo de lockout / fuerza bruta

• Verificar que la cuenta se bloquee tras varios intentos fallidos

• Analizar código HTTP 429 ante envío masivo de solicitudes por fuerza bruta

• Revisar si hay captcha y si se puede bypasear

• Analizar mecanismo de recuperación legítimo en caso de bloqueo

• Probar rate limiting al intentar numerosas autenticaciones

3.4 Bypass de autenticación

• Probar acceder a URLs internas sin pasar por login (Forceful Browsing) o sin cookies de sesión

• Probar vulnerabilidad Parameter Tampering

• Revisar si la aplicación permite session ID prediction

3.5 Política remember-me y almacenamiento de credenciales

• Verificar si las credenciales almacenadas en la cookie están cifradas o en texto plano

• Analizar si guarda la contraseña en localStorage o cookies sin cifrado

3.6 Debilidades caché del navegador

• Analizar si las páginas con datos sensibles tienen cabeceras de control de cache

• Revisar si post logout se puede ver información sensible retornando a URLs internas

3.7 Política de contraseñas

• Comprobar política de contraseñas (longitud, caracteres especiales)

• Verificar si el servidor impide usar contraseñas comunes o el mismo username como password

• Revisar si se permite reutilizar contraseñas antiguas

3.8 Preguntas de seguridad (Security Question)

• Revisar la complejidad de las preguntas

• Comprobar si pueden ser fácilmente adivinadas o rotas por fuerza bruta

3.9 Cambio / restablecimiento de contraseña

• Verificar que información se requiere para resetear la contraseña

• Comprobar si el token de reseteo expira apropiadamente y se invalida tras uso

• Verificar si se destruyen sesiones activas cuando se cambia la contraseña

• Revisar si pide la contraseña antigua antes de permitir un cambio de password

• Analizar si el reset password token tiene estructura predictiva o baja entropía

3.10 Pruebas de MFA/2FA/OPT

• Probar bypass de MFA manipulando parámetros, reusando tokens, etc

• Revisar si se invalida el código tras uso exitoso o tiempo límite

• Probar bypass de 2FA por respuestas manipuladas, tokens reusables, etc

• Probar rate limiting en ingreso del 2FA para evitar brute force

• Probar rate limiting en códigos de un solo uso (OTP) para evitar brute force

• En OTP temporales (TOTP), comprobar si la app acepta un desfase de tiempo

• Intentar “replay” de un código ya usado y ver si servidor lo rechaza o admite

• Revisar si la app envía el código 2FA por canales inseguros y si hay notificaciones al usuario sobre el evento de 2FA

3.11 Autocompletado en formularios/entradas de contraseñas

• Revisar si se utiliza autocomplete="off" en campos críticos

• Analizar que no quede la contraseña almacenada en navegador sin consentimiento

3.12 Probar notificaciones fuera de canal

• Comprobar si app envía correos/mensajes cuando se bloquea una cuenta o se cambia contraseña

• Verificar que esto no filtre información sensible y que sea realmente útil para el usuario

3.13 Probar historial de autenticación accesible por el usuario

• Revisar si el usuario puede ver un registro de inicios de sesión

• Verificar si ese registro expone IPs, fechas y si esto puede derivar en filtración de datos

---

4. Identity & Authorization Testing

4.1 Roles y gestión de usuarios

• Verificar que cada rol tenga permisos limitados a su ámbito

• Revisar funciones de admin accesibles por usuarios de rol bajo

• Confirmar que existan mecanismos para desactivar o eliminar usuarios antiguos (*, **)

• Analizar si un usuario puede eliminarse o eliminar la cuenta de otros sin ser admin

• Revisar recursos asociados a cuentas dadas de baja

• Comprobar que no se acepten cuentas duplicadas con el mismo email o ID

• Revisar si se rechazan direcciones de correo desechables

• Validar qué datos se solicitan y cómo se verifica la validez (captcha, email de confirmación, etc.)

• Revisar mensajes de error para detectar si se filtra la validez de un usuario (usuario válido + contraseña inválida, etc.)

• Confirmar si hay rate limiting en intentos de login

• Verificar que no se divulgue información sobre la existencia de cuentas

• Comprobar restricciones mínimas para usernames (longitud, caracteres prohibidos, etc.)

• Probar enumeración de usuarios

4.2 Bypass y escalada de privilegios

• Probar acceso directo a URLs internas sin pasar por la verificación de permisos

• Hacer “forceful browsing” para llegar a recursos teóricamente restringidos

• Revisar si la aplicación confía solo en un token o parámetro para conceder privilegios

• Probar escalada vertical mediante alteración de ID, UUID, u otros métodos de control implementados

• Probar escalada horizontal mediante alteración de ID, UUID, u otros métodos de control implementados

• Intentar modificar cookies o tokens que contengan información de rol, ID de usuario, etc

• Verificar si la aplicación no valida en servidor dichos valores y permite privilegios indebidos

• Probar wildcard permissions

4.3 IDOR

• Probar cambio de IDs o parámetros designados sobre un usuario

• Añadir parámetros extra con distintos métodos (GET, POST, JSON)

• Revisar si la validación de propiedad de un recurso no existe o es deficiente

• Verificar si hay versiones antiguas de la API donde los controles de acceso no estén implementado

• Analizar enumeración por consultas indirectas, ID estructurados, UUIDs, etc

4.4 HTTP Parameter Pollution

• Probar HTTP Parameter Pollution

• Enviar parámetros duplicados en la misma petición (param=1&param=2)

• Revisar como el servicio interpreta dichos valores

4.5 Directory Path Traversal & File Inclusion

• Probar Path Traversal

• Probar Local File Inclusion

• Probar Remote File Inclusion

4.6 OAuth Weaknesses

• Probar si un token OAuth antiguo sigue siendo aceptado

• Probar Open Redirect en flujo de OAuth

• Confirmar que la app compruebe el state para prevenir ataques de CSRF o confusión de sesión

---

5. Session Management Testing

5.1 Gestión de sesión

• Verificar si token de sesión se transmite por HTTPS

• Analizar estructuras de tokens, cookies, JWT, etc

5.2 Cookies attributes

• Revisar flags Secure, HttpOnly, SameSite (Lax o Strict) para cookies

• Analizar persistencia y caducidad de cookies

• Evitar almacenar datos sensibles en cookies sin cifrar

• Asignar valor NULL o sin lógica en la cookie de sesión

5.3 Session fixation

• Comprobar si se emite un nuevo token de sesión tras un proceso de autenticación

• Verificar si el servicio acepta una cookie manipulanda pre request de login

5.4 Exposición de variables de sesión

• Revisar si el ID de sesión aparece en la URL o en logs accesibles

• Revisar si el ID es predecible o está codificado en Base64 con info sensible

5.5 CSRF

• Probar técnicas de PS

• Comprobar si existen tokens CSRF únicos y vinculados a la sesión

• Quitar o modificar token y analizar comportamiento del servidor

• Revisar si el token se renueva en cada formulario o sesión

• Probar intercambiar tokens entre cuentas distintaswwwwwwwwwwwwwwwwwwwwwwwww

5.6 Logout functionality

• Analizar que la sesión se invalida tras logout

• Revisar si se puede acceder a recursos retrocediendo en el navegador post logout

5.7 Session timeout

• Revisar tiempo de inactividad tras el cual expira la sesión

• Comprobar si hay tiempo de vida máximo para la sesión

5.8 Session Puzzling

• Identificar variables internas del token de sesión y probar combinaciones que rompan la lógica

5.9 Session Hijacking

• Interceptar tokens en HTTP si no usan HTTPS

• Probar reutilizar cookies capturadas en otra sesión

• Revisar si HSTS previene ataques de secuestro por downgrade a HTTP

5.10 JWT Attack

• Probar técnicas de PS

• Revisar si se usan algoritmos inseguros

• Comprobar si se validan correctamente las firmas

• Verificar si la expiración está configurada y forzada

• Probar JWT KID Injection

---

6. Data validation testing (Injections)

6.1 XSS Reflected

• Probar técnicas de PS

• Probar caracteres peligrosos (<, >, &, ")

• Probar XSS Reflected en PDF export, input type text, autofill, tabnabbing, SVG injection, mutation en React, técnicas de PS, etc

• Inyectar payloads usando caracteres extraños o Unicode normalizado

• Enfocar posibles bypass de WAF por detección de caracteres simbólicos o estructuras de sentencias

• Usar “backticks” (`) o entidades HTML parciales (<, >, &) mezcladas

• Probar inyecciones en parámetros GET, POST o cabeceras Referer, User-Agent, X-Forwarded-For, etc

• Incluir vectores en atributos “onerror”, “onload”, “onfocus” o HTML5 (<svg onload=alert(1)>)

• Revisar si hay algún filtrado que bloquea <script>, pero no otras etiquetas (<iframe>, <marquee>, <style> con expression: en CSS para IE)

• Revisar si hay filtrado de ciertos payloads y buscar bypass (por ejemplo, new line \r\n)

• Probar payloads políglotas que funcionen en múltiples contextos (HTML, JSON, XML)

• Añadir saltos de línea (\r\n) o tabulaciones para romper reglas de WAF

• Combinar HTML entities, URL encode, Unicode, base64 en un solo payload

• Usar %uFFFF (UTF-16) en navegadores antiguos

6.2 XSS Stored

• Probar técnicas de PS

• Identificar campos que almacenen datos y se muestren luego (comentarios, foros, perfiles)

• Subir ficheros con nombres maliciosos (JS en el nombre de archivo)

• Probar inyección XSS mediante archivos SVG

• Intentar inyectar payloads persistentes en base de datos

• Revisar el efecto en diferentes navegadores / vistas

• Probar payloads políglotas

6.3 XSS DOM-Based

• Probar técnicas de PS

• Buscar “sources” y “sinks” menos habituales ( document.URL, document.baseURI, window.name, localStorage, sessionStorage)

• Revisar librerías JavaScript que hagan eval(), Function(), setTimeout("string", ...) con datos controlados

• Probar frameworks antiguos con sandbox bypass inyectando algo tipo {{constructor.constructor('alert(1)')()}}

• Insertar payload que sea válido en HTML/JS inline (polígloto) o mezclar con event handlers (<svg onload=...>)

6.4 SQL Injection

• Probar técnicas de PS

• Probar en formularios de login, barras de búsqueda, cookies, cabeceras u otras entradas

• Usar inyección ciega por Booleans, Time-based

• Probar tamper scripts, encodings, Union-based, Error-based

• Incluir funciones específicas de cada SGBD

• Revisar NoSQL, Mongo, CouchDB si aplica

• Realizar inyección de paylaods para evasión de WAF

6.5 LDAP Injection

• Emplear wildcards y filtros encadenados ( (uid=) o (|(uid=admin)(uid=)) ) para evadir validaciones

• Probar (cn=* concatenado para inyectar condiciones extra

• Intentar romper la lógica con & ( (&(objectClass=person)(|(uid=admin)(uid=*))))

• Revisar si es un LDAP de Active Directory para enumerar grupos o usuarios con parámetros especiales

6.6 XML Injection y XXE

• Probar técnicas de PS

• Validar si la app procesa XML

• Probar inyección XXE con DTD externo () para leer ficheros locales

• De existir XXE, intentar SSRF si se puede apuntar a http://localhost:<port>

• Realizar blind XXE con DNS exfil (SYSTEM "http://<collab-dns>?file=...") si el contenido no se devuelve directamente

• Probar ataques de DoS con entidades recursivas (“billion laughs”)

6.7 SSI Injection

• Probar técnicas de PS

• Combinar directivas o en entornos que soporten SSI

• Analizar si el server interpreta archivos .shtml, .stm, .shtm

• Analizar inyecciones

• Revisar si el path se puede manipular encadenar LFI o RFI

6.8 XPath / XQuery Injection

• Utilizar condiciones como username or '1'='1 o count(//user[username/text()='admin'])

• Extraer datos vía condicionales if(count(//user[pass='p'])=1) then ...

• Explorar si framework XML admite acceso a ficheros locales

6.9 IMAP/SMTP Injection

• Inyectar comandos IMAP o SMTP en formularios

• Insertar saltos de línea %0d%0a para añadir encabezados SMTP como To:, Bcc:, Data:

• Analizar si la app concatena subject o destinatario con input del usuario

• Revisar formularios de contacto donde se envía correo automáticamente para inyección de campos

6.10 Code Injection / Template Injection

• Probar técnicas de PS

• Probar inyección en motores de plantillas (Jinja2: {{7*7}} -> 49, Twig: {{_self}}, Velocity: $systemProperties.get("os.name"), Freemarker)

• Analizar si la app evalúa directamente cadenas recibidas

• Analizar vectores para RCE ({{().__class__.__mro__[1].__subclasses__()}} en Python)

• Revisar si la aplicación deja acceso a métodos internos del template para posible escalada

6.11 Command Injection

• Probar técnicas de PS

• Usar separadores de comandos (;, |, &&, ||) para ejecutar comandos en OS

• En entornos Unix combinar IFS (IFS=$'\x0a') para romper scripts y redirigir comandos

• Inyectar variables de entorno personalizadas (ENV_VAR=value) si la app concatena entradas en comando shell

• Explorar shell built-ins (source, exec) para persistencia de inyección

• Si existen input files, inyectar secuencias EOF en la terminal para sobrescribir secciones de script

6.12 Format String Injection

• Buscar usos de funciones de formateo (printf, sprintf) sin sanitizar entradas

• Inyectar múltiples sentencias %s%s%s%s para leer partes del stack en busca de direcciones o contraseñas en memoria

• Probar %999999 para provocar DoS si la función intenta formatear un buffer muy grande

• Buscar funciones fprintf(stderr, user_input) en código, donde no se use un literal de formato y se inyecte directamente la variable

• Revisar entornos en que la format string se combine con wide chars (%ls, %ws) para romper validaciones y lógicas

6.13 SSRF

• Probar técnicas de PS

• Probar parámetros que acepten URLs

• Realizar inyecciones de headers haciendo referencia a recursos internos o al localhost

• Realizar llamados por body de la petición a recursos internos o de confianza

• Intentar acceder a recursos internos (metadata de AWS, red interna)

• Emplear domain fronting usando un Host: distinto al SNI TLS, si la aplicación pasa la conexión a un proxy que confía en el SNI

• Añadir cabeceras custom en la URL (http://127.0.0.1:[e-mail]) para romper la lógica de parseo

• Probar protocolos menos típicos (dict://, tftp://, scp://) si la librería subyacente los soporta

• Con SSRF blind, intentar métodos PUT o DELETE en puertos internos como docker API, redis

6.14 Mass Assignment

• Enviar campos JSON adicionales no esperados para forzar cambios en atributos sensibles

• Analizar si app acepta objetos anidados (10+ niveles de JSON) que podrían forzar un stack overflow en el parser o asignar propiedades inesperadas dentro de la estructura

• Incluir propiedades definidas como only read” en el modelo, para ver si la app no las ignora (createdAt, isSystemUser)

• En frameworks como Ruby on Rails, probar parámetros signados vs strong parameters con arrays, hashes anidados

• Revisar si la aplicación expone endpoints de “bulk update” que apliquen cambios masivos sin verificación de permisos

6.15 Cross-Site WebSocket Hijacking

• Revisar si app valida origen y token en el handshake WebSocket

• Probar header Sec-WebSocket-Key para ver si la app hace validaciones; si no reutilizar el handshake

• Inyectar subprotocolos como Sec-WebSocket-Protocol: chat, super-protocol) para ver si la app reacciona de forma insegura

• Usar websockets binarios e introducir payloads que el parser no espere, provocando de-serialización si el backend está mal configurado

• Si hay reconexión automática, forzar DNS change (subdominio) para redirigir el WS a un servidor de control (collab)

6.16 Overflows

• Revisar si campos numéricos o de tamaño de payload excesivo pueden provocar comportamientos fuera de lo normal o la lógica

• Comprobar si hay librerías nativas propensas a estos ataques

• Incluir multi-part forms en que un campo declare un tamaño menor pero se envía un stream mayor (heap overflow)

• Usar formatos de imágenes con metadatos inusuales (EXIF con grandes valores) que disparen un buffer overflow por librerías

• Probar sobrepasos en cadenas de conversión numérica como atoi(), recibiendo valores mayores que INT_MAX

• Si la app maneja “chunked” data, enviar chunks corruptos que indiquen tamaños irreales

6.17 Comparar validación client-side vs server-side

• Confirmar que la validación en el front-end no sea la única defensa

• Asegurar que el servidor valida y sanitiza los inputs

• Editar manualmente un disabled o readonly <input> en la respuesta

• Quitar “step” o “min/max” en <input type="number"> para inyectar valores fuera de rango

• Interceptar respuesta del servidor y reinyectar parámetros con dropdown fijo

• Si hay wizard de varios pasos, saltarse un paso desde consola o reordenar secuencia de peticiones revisando si el servidor valida la secuencia original

---

7. Client-Side Testing

7.1 DOM-Based XSS

• Probar técnicas de PS

• Identificar sinks peligrosos en el sitio (document.write, innerHTML, eval, setTimeout("string", ...), Function()) y buscar valores que provengan de document.URL, window.name, localStorage, etc

• Probar payloads que no involucran la respuesta del servidor (XSS puramente en el front-end)

• Inyectar o sobrescribir variables globales que la app use en el DOM (por ejemplo, window.config), si no hay validación

• Revisar frameworks antiguos (AngularJS < 1.6, Knockout, Vue < 2) con funciones {{ ... }} que permitan inyección

• Intentar “payloads polígotos” que funcionen como HTML y como JavaScript simultáneamente

• Evaluar si existe Shadow DOM o Web Components que reinyecten contenido inseguros

7.2 JavaScript Execution / HTML Injection

• Revisar si se pueden inyectar scripts/HTML en la interfaz de usuario más allá de los formularios clásicos (por ejemplo, personalización de temas, perfil de usuario, mensajes de chat)

• Probar CSS Injection (usando <style>, @import, expression: en IE antiguos) o manipulación de estilos (forzar clickjacking, UI redressing)

• Chequear si la aplicación usa sanitizadores de HTML (DOMPurify, etc.) y buscar bypass en configuraciones mal definidas

• Explorar inyecciones en atributos de HTML5 (data-*), iconos en <link rel="icon" ...> o <base href> que puedan cambiar rutas internas

7.3 Open Redirect

• Probar técnicas de PS

• Buscar parámetros que controlen la URL de destino (?next= o ?redirect=) y verificar si hay validación de dominio

• Intentar redirigir a dominios externos maliciosos, incluyendo subdominios que parezcan confiables (http://app-evil.example.com)

• Probar encoding de la URL (%0d%0a, \x00) para inyectar cabeceras adicionales o romper la verificación del dominio

• Revisar si la app concatena sin sanitizar varios segmentos de ruta (por ejemplo, redirect=/admin + un segundo redirect que genera /admin/http://evil.com)

7.4 Cross Origin Resource Sharing (CORS)

• Probar técnicas de PS

• Revisar la cabecera Access-Control-Allow-Origin para ver si permite * o orígenes arbitrarios

• Comprobar si se permite Access-Control-Allow-Credentials: true junto con *, exponiendo datos sensibles al dominio que sea

• Intentar usar orígenes similares (https://sub.evil.com vs. https://victim.com) con homógrafos en caracteres Unicode (IDN) para bypass

• Probar cabeceras Origin: null (algunas apps aceptan orígenes nulos) o file:// en navegadores que permitan requests locales

7.5 WebSockets

• Probar técnicas de PS

• Comprobar si se validan orígenes y tokens al iniciar la conexión

• Probar “Cross-Site WebSocket Hijacking” enviando un Origin falso y viendo si el socket se establece, pudiendo leer datos

• Intentar manipulación del handshake enviando cabeceras poco comunes (Sec-WebSocket-Protocol) o fragmentadas

• Revisar si el servidor reusa cookies sin HttpOnly que puedan ser capturadas desde un script malicioso

7.6 Web Messaging

• Probar manipulación de mensajes postMessage, revisando si la app verifica el event.origin antes de procesar datos

• Enviar objetos complejos (JSON con anidaciones) para ver si hay inyección en la respuesta o si se guardan en localStorage sin sanitizar

• Verificar si la app hace un postMessage a * (cualquier origen) exponiendo datos internos

• Revisar si existen listeners de message que ejecuten funciones con eval o concatenación de strings sin validación

7.7 Service Workers / Offline App

• Revisar la política de caché e interceptación de requests (archivo service-worker.js) para ver si se cachean recursos críticos sin cifrar

• Verificar que no se almacenen datos sensibles (tokens, credenciales) en la cache del service worker.

• Probar manipular la ruta de registro del service worker (navigator.serviceWorker.register('/sw.js')) si la app no la fija correctamente, inyectando un SW malicioso

• Evaluar si se implementa https: para el service worker, pues SW en HTTP no está permitido pero si hay configuraciones “dev” que lo dejan en local host sin TLS

7.8 Browser Storage

• Revisar localStorage, sessionStorage, IndexedDB para datos sensibles sin cifrar o sin expiración (podrían mantenerse tras logout)

• Confirmar que al hacer logout se limpien datos locales (tokens, historial) o, al menos, se invaliden en el servidor

• Probar manipular sessionStorage en otra pestaña o dominio si la app no comprueba el origen

• Revisar si las claves en IndexedDB se usan para offline access y si exponen info confidencial (contraseñas, token JWT, etc.)

7.9 Reverse Tabnabbing

• Verificar si los enlaces con target="_blank" usan rel="noopener noreferrer" para evitar que la pestaña hija controle window.opener

• Intentar inyectar un enlace sin noopener y abrirlo para ver si la nueva pestaña puede redirigir la pestaña original (window.opener.location)

• Si la app genera links dinámicamente (por ejemplo, un blog con enlaces externos), comprobar si añade por defecto noopener o “safe” en HTML5

• Revisar si se pueden robar datos de la pestaña previa o suplantar la interfaz de la página original tras redirigir opener.location

---

8. Business Logic Testing

8.1 Validar datos de lógica de negocio

• Probar ingresar valores extremos (negativos, muy grandes) en campos como precio, cantidad o descuentos para forzar desbordamientos o desajustes de lógica

• Revisar manipulación de valores de impuestos, envíos gratis o recálculos de montos finales sin validación en el servidor

• Intentar romper validaciones condicionales (ej. un campo “descuento” que debería requerir un código especial) haciendo peticiones directas al endpoint

8.2 Falsificación de solicitudes

• Comprobar si la app permite omitir pasos obligatorios del flujo como saltar checkout y llegar directo a confirmación de compra

• Revisar posibilidad de repetición de acciones críticas (doble confirmación de pagos, uso del mismo cupón varias veces) para obtener beneficios indebidos

• Probar reenvíos (replays) de la misma petición con tokens antiguos o sin token, y ver si la app valida el estado

• Intentar enviar un token de sesión de un usuario distinto en un paso avanzado para ver si se mezclan los flujos (session puzzling)

8.3 Integridad de procesos

• Ver si es posible alterar datos a mitad de un flujo (cambiar precio en un carrito antes de pagar, modificar dirección de envío tras haber confirmado un paso)

• Alterar un campo de stock o inventario en plena transacción para ver si se finaliza con stock negativo

• Iniciar dos sesiones simultáneas y alternar pasos entre ambas para ver si la lógica del servidor se rompe

8.4 Límites de uso de funciones

• Probar repetidamente una misma acción (p. ej., canjear un cupón, puntos de fidelidad) para ver si se aplica varias veces en un mismo pedido

• Intentar sobrepasar un límite teórico (por ejemplo, añadir 999999 artículos al carrito) para detectar limitaciones de inventario o sumas excesivas

• Revisar si hay control de transacciones atómicas (un cupón que solo debería ser válido una vez por usuario)

8.5 Circunvención de workflows

• Intentar saltar pasos obligatorios (como verificación de correo, aceptación de términos) enviando directamente la petición al endpoint final

• Revisar si la app guarda un “estado del wizard” en la sesión o en campos ocultos y si se pueden modificar para avanzar sin cumplir las condiciones

• Falsificar la ruta del proceso (por ejemplo, enviar paso 3 antes de completar paso 2) y ver si el servidor lo acepta

8.6 Defensas contra uso indebido

• Revisar si hay validaciones server-side que impidan abusos (compra de productos a 0 €)

• Intentar peticiones muy rápidas o automatizadas (sin captcha ni limitación) para ver si se genera spam o se saturan inventarios

• Comprobar si la aplicación registra los eventos en logs y si existe algún mecanismo de detección de fraudes (varios pagos sospechosos, IPs repetidas, etc.)

8.7 File Upload (funcionalidad riesgosa)

• Probar técnicas de PS

• Verificar tipos de archivo permitidos (extensiones, MIME) y usar caracteres Unicode o secuencias RLO (Right-to-Left Override) para ocultar la extensión real (.php disfrazado de .jpg)

• Asegurar que el servidor no devuelva o ejecute archivos con extensiones sensibles (.php.old, .aspx.bak, etc.)

• Revisar si realmente se valida el contenido vs la extensión (subir un PNG con cabecera de un ZIP, etc.)

• Comprobar dónde se almacena el archivo subido y si el directorio es accesible públicamente

• Probar subir ficheros con payloads XSS, RCE, SSRF (p. ej. PDF o imágenes con metadatos maliciosos)

• Revisar límites de tamaño, frecuencia y número de archivos para evitar DoS por saturación de disco

• Subir nombres que contengan %00 para truncar la extensión en sistemas basados en C

8.8 Pago con tarjetas (Card Payment)

• Revisar vulnerabilidades comunes en entornos de pago (PCI-DSS compliance, cifrado en reposo de PAN y CVV)

• Probar contraseñas por defecto en terminales POS o software de pago

• Verificar si datos de tarjeta se guardan cifrados y se transmiten solo por HTTPS (nunca en texto plano)

• Probar inyecciones y fallos de configuración en el formulario de pago (incluso SSRF si se consultan APIs de tarjetas)

• Revisar almacenamiento criptográfico inseguro: logs, backups con PAN no enmascarado

• Forzar errores en pagos y reembolsos para ver si exponen datos internos o devuelven estados inconsistentes (saldo duplicado, reembolso doble)

• Intentar “card testing” (varios números y CVVs) sin que la app bloquee tras varios intentos

8.9 Denial of Service (DoS) (*, **)

• Probar si existen límites o throttling en peticiones para evitar saturar recursos (CPU, memoria, disco)

• Revisar mecanismos anti-automatización (CAPTCHA, rate limiting) para frenar bots masivos

• Intentar wildcards en queries (SQL wildcard DoS, .* en búsquedas de Regex) que consuman mucho CPU

• Mandar payloads enormes o chunked mal formados para saturar la app (Slowloris, R.U.D.Y)

• Forzar condiciones de carrera con múltiples hilos que ejecuten operaciones costosas simultáneamente

• Revisar si un usuario sin límite puede generar facturas, informes masivos o procesos batch largos

8.10 HTML5

• Explorar uso de APIs Web Storage (localStorage, sessionStorage) para ver si guardan tokens sensibles sin cifrar y sin expiración

• Revisar Service Workers y caché offline, asegurando que no se almacene contenido confidencial accesible sin autenticación

• Analizar si la app usa WebSockets o Web Messaging (postMessage) para lógica sensible sin verificar event.origin

• Comprobar políticas de CORS y CSP apropiadas para recursos en modo offline o con almacenamiento local.

• Usar la API de Drag & Drop o File API para inyectar datos en la app sin pasar por validaciones normale

---

9. Error Handling

9.1 Improper Error Handling

• Analizar posibles mensajes de error con información sensible (stack trace, rutas, consultas SQL, variables de entorno)

• Inducir errores con parámetros inesperados o tipos de archivo no permitidos para observar si el servidor responde con detalles internos

• Enviar datos en formatos incorrectos (XML en lugar de JSON, o viceversa)

• Revisar si el servidor devuelve un código de estado HTTP incoherente (200 con un mensaje de error o un 500 que muestre la ruta del archivo)

• Causar errores de encoding (UTF-8 vs. ASCII) por si la excepción expone codificación interna

• Revisar si hay endpoints dev o test que devuelvan “debug info” al recibir parámetros específicos (debug=true en la URL, cabeceras particulares, etc)

9.2 Stack Traces y debug

• Analizar si la app deja expuestos logs o traces por excepciones no controladas mostrando debug

• Provocar excepciones que involucren módulos ORM, almacenamiento en caché, external API calls

• Verificar mensajes de error que incluyan querys SQL, rutas del sistema de archivos, variables de entorno (ENV, PATH, SECRET_KEY)

• Si la aplicación envía correos de error a administradores comprobar si es posible inyectar payloads en el log/stack trace para un XSS o acceso no autorizado

• Forzar cargas excesivas de tráfico para ver si el servidor, ante saturación, arroja stack traces distintas o logs con más detalle (al no manejar adecuadamente la excepción)

---

10. Cryptography

10.1 Transport Layer Security

• Revisar versiones de SSL/TLS soportadas (evitar SSLv2, SSLv3, TLS 1.0) y confirmar si la app no permite fallback inseguro

• Probar ataques conocidos (POODLE, BEAST, CRIME, FREAK, LOGJAM, RC4 biases, etc.) usando herramientas especializadas (sslscan, testssl.sh)

• Revisar la robustez de los cifrados y la longitud de clave (>= 2048 bits); confirmar uso de Perfect Forward Secrecy (PFS) con suites ECDHE/DHE

• Verificar validez del certificado (no expirado, CN correcto, firma confiable); chequear Certificate Transparency si aplica

• Comprobar si hay HSTS preload (si la app lo declara y está en la lista de navegadores)

• Analizar si hay compresión activa (CRIME/BREACH) que permita filtraciones de datos

• Validar si se implementa OCSP Stapling o CRL para revocar certificados comprometidos

10.2 Cifrado débil / Algoritmos inseguros

• Verificar si se usan algoritmos inseguros (MD5, SHA1) en almacenamiento, firma o generación de tokens

• Comprobar uso de sal y “pepper” en hashes de contraseñas (evitar hashes planos o “salt” estático)

• Revisar la implementación de HMAC y si se separan bien las claves y datos (key primero, datos después)

• Confirmar si las funciones de hashing son adecuadas: preferir Argon2, bcrypt o scrypt frente a SHA256/SHA512 sin coste configurable

• Revisar si se aplican KDF (Key Derivation Functions) apropiadas para llaves maestras, tokens JWT o contraseñas de base de datos

• Chequear si hay uso de RC4 o cifrados obsoletos (DES, 3DES), sobre todo en VPNs o túneles SSL internos

10.3 Padding Oracle

• Probar vectores de padding oracle cuando se usen cifrados en modo CBC (AES-CBC, DES-CBC).

• Intentar manipular un bloque cifrado y observar si el servidor responde de forma distinta (mensaje de error vs. descifrado parcial)

• Usar herramientas o scripts (p. ej. PadBuster) para automatizar la exfiltración de texto plano si la app expone un canal

• Ver si los datos cifrados en cookies o tokens tienen padding que el servidor valide sin medidas (posibilidad de descifrar contenido sin la clave)

10.4 Información sensible en canales sin cifrar

• Revisar si se envía información crítica (tarjetas, credenciales) vía HTTP, correos en texto plano o protocolos inseguros (FTP, Telnet)

• Verificar si el proceso de “password reset” o “códigos de activación” se hace por correo sin cifrar

• Validar si se utiliza SMTP con TLS (STARTTLS) o si la app filtra contraseñas en logs en texto plano

• Revisar si el front-end hace peticiones a recursos estáticos (scripts, CSS) vía HTTP que puedan ser manipulados para injectar contenido malicioso

• Comprobar si la aplicación implementa HTTPS Strict-Transport-Security (HSTS) para evitar el downgrade a HTTP

---

11. Others Common Issues

11.1 No Rate Limiting

• Intentar múltiples solicitudes rápidas (fuerza bruta, enumeración masiva) usando distintas velocidades (ráfagas vs. flujo constante) para ver si hay detección

• Probar bypasses mediante cabeceras extra (X-Forwarded-For), cambio de IP, rotación de user-agent o proxies distribuidos

• Realizar ataques “low & slow” (pocos intentos pero constantes) para detectar si la app reacciona solo ante picos repentinos

• Probar si el sistema de limitación se basa en cookies (más fácil de saltar cambiando sesión) o en el “fingerprint” del dispositivo

• Revisar si existe un mecanismo de ban temporal o captcha tras X peticiones, y si este se puede omitir por fallos de implementación

11.2 EXIF Geodata

• Comprobar si en la subida de imágenes se mantienen metadatos EXIF (pueden filtrar geolocalización, fecha/hora, modelo de cámara)

• Verificar si se “limpian” esos metadatos al procesar la imagen (usando herramientas como exiftool para contrastar antes/después)

• Subir imágenes con datos EXIF inusuales (coordenadas falsas, comentarios ocultos) para ver si se muestran públicamente o se almacenan en la base de datos

• Probar imágenes que incluyan XMP data o IPTC metadata para ver si también se eliminan (algunas apps limpian EXIF pero olvidan otros contenedores)

• Revisar si se exponen los metadatos en vistas previas (thumbnails) o al procesar la imagen en otras secciones (por ejemplo, generar PDF con info)

11.3 Broken Link Hijack

• Buscar links rotos que se puedan “reclamar” (por ejemplo, dominio expirado, perfiles sociales) desde la web oficial

• Revisar documentaciones, manuales, footers o secciones de “contacto” con enlaces obsoletos a páginas de la empresa

• Intentar registrar un dominio caducado y comprobar si el tráfico o la reputación del mismo da acceso a usuarios o información residual

• Verificar si existen repos de GitHub, GitLab o bitbucket que ya no se usen y puedan ser “reclutados” para hosting malicioso con la marca de la empresa

• Probar si la app hace “redirect 301” o “link directo” a un sitio que ya no existe, generando la oportunidad de “hijack” para phishing

11.4 SPF / DKIM / DMARC

• Revisar configuración DNS para evitar spoofing de correo: verificar si el dominio tiene registros SPF (v=spf1 ...), DKIM (selector con clave pública) y una política DMARC (p=none, p=quarantine o p=reject)

• Comprobar si la política DMARC está relajada (por ejemplo, sp=none, adkim=s) que facilita suplantaciones parciales

• Enviar correos de prueba desde un servidor externo usando una dirección del dominio víctima y ver si llegan a destino (indicador de fallo en SPF/DMARC)

• Validar la alineación de cabeceras en DMARC (el From: coincida con el dominio al firmar DKIM y al estar en el registro SPF)

• Revisar subdominios que no tengan entradas DNS para SPF/DKIM, permitiendo spoofing parcial (por ejemplo, subdomain.domain.com no protegido)

---

12. API Testing

12.1 Autenticación y autorización

• Verificar si todos los endpoints requieren autenticación adecuadamente (incluidas rutas “opcionales” o endpoints de test)

• Testear mecanismos OAuth, JWT, API Keys, incluyendo escenarios de token “refresh” y expiraciones

• Probar fuerza bruta en API keys o tokens, usando diccionarios comunes (prefijos, sufijos) y exploits para tokens débiles

• Revisar control de acceso horizontal y vertical (IDOR en APIs), intentando modificar parámetros como userId o roles en payloads JSON

• Comprobar si existen endpoints que aceptan “guest” o “anonymous” con privilegios excesivos

• Revisar si la API implementa scope-based tokens en OAuth y si esos scopes se validan realmente en cada endpoint.

12.2 Gestión de sesión

• Verificar expiración correcta de tokens, intentando usarlos después de que supuestamente caduquen

• Probar reuse de tokens expirados o revocados, comprobando si el servidor mantiene una lista negra de tokens

• Revisar flags de seguridad en cookies (si usan cookies de sesión) como HttpOnly, Secure, SameSite

• Intentar “session fixation” inyectando un token en la URL o en la cabecera antes de autenticarse

• Confirmar si se emiten nuevos tokens tras operaciones sensibles (por ejemplo, cambio de contraseña)

12.3 Rate Limiting / Prevención de abusos

• Asegurarse de que haya límites de solicitudes por IP/usuario, explorando cabeceras como X-Forwarded-For para evadir IP-based blocking

• Probar enviar muchas peticiones simultáneas (ataques de fuerza bruta, enumeración) con distintas estrategias (ralentización, picos)

• Revisar si existe una “tarjeta de crédito” o “login” endpoint sin limitación, permitiendo card testing o fuerza bruta de credenciales

• Intentar cambiar valores de cabeceras (User-Agent, Accept) para detectar si se salta la limitación basada en firma de cliente

12.4 Validación de datos

• Replicar pruebas de inyección (SQLi, XSS, JSON tampering) en endpoints JSON/REST, intentando campos anidados o arrays (items[0].price)

• Revisar parámetros extra no esperados (Mass Assignment), añadiendo propiedades ocultas como role=admin

• Probar inyecciones en rutas “exóticas” de la API (ej. PUT /api/v1/users/12345?filter=...) donde el parser podría comportarse distinto

• Confirmar si se aplican validaciones de content-type (application/json, multipart/form-data) o si la API parsea todo sin restricciones

12.5 Manejo de errores / Information disclosure

• Comprobar si los mensajes de error exponen stack traces, rutas internas, nombres de tablas, variables de entorno

• Verificar códigos de estado correctos (401, 403, 404) y si la API regresa un 200 con un mensaje de error en JSON (podría engañar al cliente)

• Inducir errores lógicos (parámetros ausentes o con tipo incorrecto, etc.) para observar si se devuelven datos internos

• Probar “debug mode” o parámetros como ?debug=1 para ver si la API libera información adiciona

12.6 Transmisión segura

• Revisar uso de HTTPS para todas las operaciones sensibles, incluyendo endpoints de callback o webhooks que a veces quedan en HTTP

• Confirmar versiones seguras de TLS y que no se permita fallback a SSLv3/TLS1.0

• Probar si se implementa HSTS y si la cabecera Strict-Transport-Security incluye subdominios

• Revisar si se aceptan ciphers débiles (RC4, 3DES) o se usa un certificado autofirmado en producción.

12.7 Seguridad de endpoints

• Detectar endpoints obsoletos o de pruebas (por ejemplo, /api/v2-dev, /beta) que puedan exponer funciones no terminadas

• Comprobar si existen endpoints de administración ( /admin, /manage ) no protegidos o con credenciales por defecto

• Revisar si hay “overexposure” de datos en la respuesta, devolviendo campos internos ( contraseñas hashed, tokens ) al cliente

• Verificar políticas CORS en APIs: si Access-Control-Allow-Origin: * se combina con Access-Control-Allow-Credentials: true, exponiendo cookies a sitios maliciosos

• Explorar si la API soporta métodos HTTP no esperados (PUT, DELETE) en endpoints supuestamente de solo lectura

12.8 Business logic

• Probar bypass de reglas lógicas: por ejemplo, pagos a costo 0, modificar el subtotal en un JSON de carrito

• Envío repetido o manipulado de requests a endpoints críticos, intentando aplicar varias veces la misma acción (cupón, puntos de fidelidad)

• Revisar si la API maneja transacciones atómicas o si se pueden crear inconsistencias de inventario

• Alterar secuencias de pasos en flujos complejos (registro -> confirmación -> upgrade plan) para saltar validaciones

12.9 GraphQL (OWASP)

• Enumerar esquemas (introspection) usando queries a __schema, __type, para mapear todos los tipos y resolvers disponibles

• Probar inyecciones en consultas GraphQL, incluyendo string-based, numeric-based y alias injection en la sintaxis de GraphQL

• Revisar paginación y límites (prevención de DoS) si la API permite consultas con first: 999999 o anidamientos profundos ({ user { posts { comments { ... } } } })

• Examinar validaciones de fragments y directives, y si el servidor aplica restricciones de profundidad

• Intentar mutaciones maliciosas que no aparezcan en la doc (por ejemplo, usando introspección para descubrir mutations ocultas)

---