¿No es CSRF un problema de seguridad del navegador?

Question

Con respecto a los ataques de falsificación de solicitudes entre sitios (CSRF), si las cookies son el método de autenticación más utilizado, ¿por qué los navegadores web permiten enviar cookies de algún dominio (y ese dominio) desde una página generada desde otro dominio?

¿No se puede prevenir CSRF fácilmente en el navegador al no permitir este tipo de comportamiento?

Hasta donde yo sé, este tipo de control de seguridad no se implementa en los navegadores web, pero no entiendo por qué. ¿Obtuve algo mal?

Sobre CSRF:

• On wikipedia
• On coding horror

Editar: Creo que las cookies no deben ser enviados en http POST en el caso anterior. Ese es el comportamiento del navegador que me sorprende.

Answer 1

¿Por qué el navegador no va a enviar cookies?

El sitio A (http://www.sitea.com) establece una cookie para el usuario.

El usuario navega al sitio B (http://www.siteb.com). El sitio B presenta integración con el sitio A: haga clic aquí para hacer algo en el sitio A! Los usuarios hacen clic en "aquí".

Por lo que el navegador puede decir, el usuario toma una decisión consciente de realizar una solicitud al sitio A, por lo que lo maneja de la misma manera que cualquier solicitud al sitio A, y eso incluye el envío de cookies del sitio A en la solicitud al sitio A.

---

Editar: Creo que el problema principal aquí es que le parece que es una distinción entre las cookies de autenticación y otras cookies. Las cookies se pueden utilizar para almacenar cualquier cosa: preferencias del usuario, su último puntaje alto o un token de sesión. El navegador no tiene idea para qué se utiliza cada cookie. I quiero que mis cookies estén siempre disponibles para el sitio que las configuró, y quiero que el sitio se asegure de que toma las precauciones necesarias.

O estás diciendo que si se busca yahoo para "Gmail" y haga clic en el enlace que te lleva a http://mail.google.com, no debe estar conectado, incluso si dicho Gmail para mantenerlo conectado en , porque hiciste clic en el enlace de otro sitio?

Answer 2

No es que un navegador esté enviando la cookie desde o hacia un dominio externo, es el hecho de que está autenticado y el sitio no valida la fuente de la solicitud, por lo que lo trata como si la solicitud vino del sitio.

En cuanto a si un navegador no debería permitir eso ... ¿qué pasa con las muchas situaciones en que son deseables las solicitudes entre sitios?

Editar: para que quede claro, su cookie no se envía a través de dominios.

Answer 3

No sé si hay mucho que el navegador puede hacer en esa situación, ya que el objetivo de un ataque XSRF es dirigir el navegador a otro punto de la aplicación que podría funcionar mal. Lamentablemente, el navegador no tiene idea de si la solicitud a la que se le está enviando es maliciosa o no. Por ejemplo, dado el ejemplo clásico de XSRF:

<img src="http://domain.com/do_something_bad" /> 

no es evidente para el navegador que algo malo está pasando. Después de todo, ¿cómo es saber la diferencia entre eso y esto ?:

<img src="http://domain.com/show_picture_if_authenticated" /> 

Answer 4

Muchos de los protocolos antiguos tienen grandes agujeros de seguridad: piense en el recientemente descubierto DNS vulnerabilities. Como básicamente cualquier seguridad de red, es la responsabilidad de los puntos finales; Sí, apesta que tengamos que arreglar esto nosotros mismos, pero es mucho más difícil de solucionar a nivel del navegador. Hay algunos más obvios (< img src = "logoff.php" > se ve muy sospechoso, ¿verdad?), Pero siempre habrá casos extremos. (Tal vez es una secuencia de comandos GD en un archivo PHP, después de todo.) ¿Qué pasa con las consultas AJAX? Y así sucesivamente ...

Answer 5

Las cookies de un sitio nunca se envían a otro sitio. De hecho, para implementar un ataque CSRF exitoso, el atacante no necesita tener acceso a estas cookies.

Básicamente, un atacante engaña al usuario, que ya ha iniciado sesión en el sitio web de destino, para que haga clic en un enlace o cargue una imagen que hará algo en el sitio de destino con las credenciales de ese usuario.

Es decir, el usuario realiza la acción y el atacante ha engañado al usuario para que lo haga.

Answer 6

Algunas personas han dicho que no creen que haya mucho que el navegador pueda hacer.

ver esto:

http://people.mozilla.org/~bsterne/content-security-policy/origin-header-proposal.html

Es una visión general de una propuesta de una nueva cabecera HTTP para ayudar a mitigar los ataques CSRF.

El nombre de encabezado propuesto es "Origen" y es básicamente la cabecera "Referer" menos la ruta, etc.