Primero, una definición de Chrome :
Las cookies del mismo sitio (née "First-Party-Only" (née "First-Party")) permiten a los servidores mitigar el riesgo de CSRF y de ataques de fuga de información al afirmar que una cookie en particular solo debe enviarse con solicitudes iniciadas del mismo dominio registrable.
Entonces, ¿contra qué protege esto?
CSRF?
Las cookies del mismo sitio pueden prevenir eficazmente los ataques CSRF. ¿Por qué?
Si configura la cookie de sesión como el mismo sitio, solo se enviará si una solicitud emana de su sitio. Por lo tanto, un ataque CSRF estándar donde el atacante atrae a la víctima al sitio http://malicious.com que publica una solicitud a http://bank.com/transfer.php?amount=10000&receiver=evil_hacker no funcionará. Como malicious.com no es el mismo origen que bank.com , el navegador no enviará la cookie de sesión y transfer.php se ejecutará como si la víctima no hubiera iniciado sesión.
Esto es muy similar a cómo la configuración de un encabezado HTTP X-Csrf-Token lo protege de CSRF; nuevamente, hay algo que solo se envía si la solicitud proviene de su dominio. La propiedad del mismo sitio convierte su cookie de sesión en un token CSRF.
Entonces, ¿problema resuelto? Especie de. Hay algunas advertencias:
- Esto solo funcionará para los navegadores que implementan esta función. Hasta ahora, muy pocos lo hacen. A menos que desee lanzar a todos los que usan un navegador un poco más antiguo debajo del bus, todavía necesitará implementar un token CSRF antiguo.
- Si necesita un control más preciso, esto no será suficiente. Si ejecuta un sistema que muestra contenido de usuario no confiable, como un foro, no desea que las solicitudes que se originan en las publicaciones de los usuarios se consideren válidas. Si alguien publica un enlace a
http://myforum.com/?action=delete_everything , no desea que se elimine nada solo porque un usuario haga clic en él. Con un token CSRF tradicional, puede controlar exactamente cuándo se usa. Con una cookie del mismo sitio, no puedes.
- Se siguen aplicando las mismas advertencias anteriores para las antiguas protecciones CSRF. Si tiene una vulnerabilidad XSS, ninguna protección CSRF en este mundo lo protegerá.
Dicho esto, la cookie del mismo sitio sigue siendo una buena cosa que debe usarse junto con las defensas tradicionales como defensa en profundidad.
¿XSS y XSSI?
La cookie del mismo sitio no hace nada para protegerlo de ataques XSS comunes. Si un pirata informático logra engañar a su sitio para que se haga eco del script desde la URL de su sitio, se ejecutará como proveniente de su origen (después de todo, lo es) y, por lo tanto, las cookies de sesión se enviarán con todas las solicitudes del script inyectado. hace a tu dominio.
Si lees cuidadosamente la cita en tu publicación, verás que dice XSSI con una I al final, y no XSS. I significa inclusión, y XSSI está relacionado con, pero es diferente de, XSS. Aquí es una buena explicación de XSSI y cómo difiere de XSS:
XSSI es una forma de XSS que aprovecha el hecho de que los navegadores no impiden que las páginas web incluyan recursos como imágenes y scripts, que se alojan en otros dominios y servidores. [...] Por ejemplo, si el sitio de Bank ABC tiene un script que lee la información de la cuenta privada de un usuario, un pirata informático podría incluir ese script en su propio sitio malicioso (www.fraudulentbank.com) para obtener información de los servidores de Bank ABC cada vez que El cliente de Bank ABC visita el sitio del hacker.
Las cookies del mismo sitio lo protegen de XSSI, ya que una cookie de sesión no se enviaría con la solicitud del script y, por lo tanto, no devolvería ninguna información confidencial. Sin embargo, para XSS ordinario no hace ninguna diferencia.