El XSS reflejado se produce cuando se incluyen scripts maliciosos en las URL y se reflejan inmediatamente a los usuarios sin un saneamiento adecuado. Estos ataques suelen requerir ingeniería social para convencer a los usuarios de que hagan clic en enlaces maliciosos. La prevención implica la validación de entradas, la codificación de salidas y la implementación de encabezados de Política de Seguridad de Contenidos.
El cross-site scripting reflejado ocurre cuando una aplicación web toma datos de entrada de una petición, normalmente un parámetro de consulta de la URL, un término de búsqueda o un campo de formulario, y los devuelve directamente en la respuesta HTML sin codificarlos. Si un atacante crea un enlace cuyo parámetro contiene un script, el servidor refleja ese script en la página y el navegador de la víctima lo ejecuta como si lo hubiera escrito el propio sitio. El payload no se almacena en ningún sitio; solo vive en esa única petición, así que cada ataque necesita un enlace malicioso nuevo. Un vector típico es una página de resultados de búsqueda que imprime tu consulta tal cual, o una página de error que repite un valor sin escapar tomado de la URL.
Como el script inyectado se ejecuta en el navegador de la víctima bajo el propio origen del sitio, hereda la confianza de ese origen. Puede leer cookies que no sean HttpOnly, tokens de sesión y el contenido de la página, enviar formularios o reescribir lo que ve el usuario, lo que permite el secuestro de sesión, el robo de credenciales y phishing que parece proceder del dominio real. El XSS reflejado suele depender de la ingeniería social: el atacante tiene que conseguir que la víctima haga clic en un enlace trampa desde el correo, el chat o un anuncio malicioso, así que a menudo apunta a usuarios autenticados de banca, webmail o paneles de administración. Un único parámetro vulnerable puede comprometer cualquier cuenta cuyo propietario abra el enlace.
Las defensas principales están del lado del desarrollador: valida la entrada y aplica una codificación de salida sensible al contexto para que los valores reflejados se rendericen como texto, nunca como marcado o script. Una Content Security Policy añade una segunda capa al restringir qué scripts pueden ejecutarse, y el autoescapado de los frameworks cierra la mayoría de los casos por defecto. cside no sustituye a la codificación de salida; su foco son los scripts de terceros que carga una página. Cuando un punto de apoyo de XSS o un script de un proveedor comprometido intenta cargar o exfiltrar datos a través del navegador, el método Script de cside inspecciona el payload real de JavaScript, puede bloquear ese comportamiento en tiempo real y conserva un registro forense, lo que además cumple con los requisitos de monitorización de scripts de PCI DSS 6.4.3 y 11.6.1.
Su radio de impacto suele ser menor, porque el payload no se guarda en el servidor, así que solo afecta a los usuarios que abren un enlace específico creado a medida en lugar de a todos los que ven una página. Pero las capacidades dentro del navegador son idénticas, y contra un objetivo autenticado de alto valor un solo clic puede bastar para secuestrar una cuenta.
No. El atributo HttpOnly solo oculta una cookie a JavaScript, así que limita el robo de tokens, pero un script reflejado todavía puede actuar dentro de la sesión, leer datos de la página, enviar peticiones y desfigurar la interfaz. HttpOnly es una mitigación útil, no una solución; sigues necesitando codificación de salida y una CSP sólida.
We answer client-side security questions every day. Bring yours.