¿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 a ese dominio) desde una página generada desde otro dominio?

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

Hasta donde yo sé, este tipo de verificación de seguridad no se implementa en los navegadores web, pero no entiendo por qué. ¿Me equivoqué?

Acerca de CSRF:

• En wikipedia
• Sobre la codificación del horror

Editar: creo que las cookies no deberían enviarse en http POST en el caso anterior. Ese es el comportamiento del navegador que me sorprende.

Answer 1

¿Por qué el navegador no enviaría 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 & Quot; aquí & Quot ;.

Por lo que el navegador puede decir, el usuario está tomando una decisión consciente de hacer una solicitud al sitio A, por lo que lo maneja de la misma manera que manejaría cualquier solicitud al sitio A, y eso incluye enviar cookies del sitio A en la solicitud al sitio A.

---

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

¿O estás diciendo que si buscas en Yahoo " gmail " ;, y luego haces clic en el enlace que te lleva a http://mail.google.com , no debe iniciar sesión, incluso si le dijo a gmail que lo mantenga conectado , porque hizo clic en el enlace de otro sitio?

Answer 2

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

En cuanto a si un navegador debe rechazar eso ... ¿qué pasa con las muchas situaciones en las 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 el navegador puede hacer mucho en esa situación, ya que el objetivo de un ataque XSRF es dirigir el navegador a otro punto de la aplicación que realice algo malo. Desafortunadamente, el navegador no tiene idea de si la solicitud que se 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á sucediendo. 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 Vulnerabilidades de DNS . Al igual que básicamente cualquier seguridad de red, es responsabilidad de los puntos finales; Sí, apesta que tengamos que arreglar esto nosotros mismos, pero es mucho más difícil arreglarlo a nivel del navegador. Hay algunos obvios (& Lt; img src = & Quot; logoff.php & Quot; & Gt; se ve muy sospechoso, ¿verdad?), Pero siempre habrá casos extremos. (Tal vez es un script 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 haga algo en el sitio de destino con las credenciales de ese usuario.

Es decir, el usuario está realizando 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 el navegador pueda hacer mucho.

Ver esto:

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

Es una descripción general de una propuesta para un nuevo encabezado HTTP para ayudar a mitigar los ataques CSRF.

El nombre del encabezado propuesto es " Origin " y es básicamente el " Referer " encabezado menos la ruta, etc.