XSS Reflejado.

El XSS reflejado (no persistente o Tipo 1) ocurre cuando una aplicación toma datos de una petición HTTP, normalmente un parámetro de URL o campo de formulario, y los reenvía en la respuesta sin codificación de salida apropiada. El ataque requiere que la víctima haga clic en un enlace manipulado, por lo que suele distribuirse mediante phishing, malvertising o mensajería. Una explotación exitosa permite robar cookies de sesión, ejecutar acciones en nombre del usuario o encadenar una toma total de cuenta. Las defensas incluyen codificación HTML sensible al contexto, una Política de Seguridad de Contenidos estricta y frameworks que escapan automáticamente la salida.

Anatomía de un ataque XSS reflejado

flowchart LR
  A[El atacante crea un enlace con script en un parametro] --> B[Distribuye via phishing / anuncio / chat]
  B --> C[La victima hace clic en el enlace]
  C --> D[La app refleja la entrada sin codificar]
  D --> E[El navegador ejecuta el script en la sesion]
  E --> F[Robo de cookie / acciones como el usuario / toma de cuenta]

Por qué el payload debe codificarse según su contexto

La sutileza que define al XSS es que la «codificación» depende del contexto: el mismo valor es seguro en un lugar y peligroso en otro. Un dato colocado dentro de texto HTML necesita codificación de entidades HTML; dentro de un atributo, codificación de atributo y comillas; dentro de un bloque <script> o un manejador de eventos, codificación de cadena JavaScript; y dentro de una URL, codificación de URL. Un único paso de codificación aplicado a ciegas pasará por alto los casos en que el mismo parámetro se refleja en varios contextos. Los motores de plantillas que escapan por defecto (JSX de React, Angular o el templating de servidor con escape contextual) eliminan la mayoría del XSS reflejado, siempre que se eviten atajos como dangerouslySetInnerHTML o innerHTML.

Los filtros del navegador ya no son una defensa. Google eliminó el XSS Auditor de Chrome en Chrome 78 (octubre de 2019) porque era fácil de eludir, causaba falsos positivos y podía ser abusado para desactivar selectivamente scripts legítimos; la cabecera X-XSS-Protection que respetaba está hoy prácticamente obsoleta. Los controles duraderos son la codificación de salida sensible al contexto, una Content Security Policy estricta (idealmente basada en nonce o hash), cookies HttpOnly para que un script robado no pueda leer la sesión, y la validación de entrada como defensa en profundidad en lugar de barrera principal.