security - incorrect - ¿Por qué el token CSRF debe estar en metaetiqueta y en cookie?
csrf token php (4)
¿Cuál es la necesidad de poner el nombre y el valor del token CSRF dentro de la etiqueta <head> usando <meta> como:
p.ej:
<meta content="authenticity_token" name="csrf-param" />
<meta content="4sWPhTlJAmt1IcyNq1FCyivsAVhHqjiDCKRXOgOQock=" name="csrf-token" />
He leído sobre el concepto para mantener el valor de CSRF en las cookies, pero no encuentro el motivo por el que debo guardarlo dentro de la etiqueta <head> .
Esto se debe a que no hay nada que impida que un sitio web ofensivo envíe datos a un sitio web legítimo, que podría incluir su ticket de autenticación y su token CSRF. Imagine este escenario ... tomado de ASP.NET
- Un usuario inicia sesión en www.siteA.com, utilizando la autenticación de formularios.
- El servidor autentica al usuario. La respuesta del servidor incluye una cookie de autenticación.
Sin cerrar la sesión, el usuario visita un sitio web malicioso. Este sitio malicioso contiene el siguiente formulario HTML:
<h1>You Are a Winner!</h1> <form action="http://siteA.com/api/account" method="post"> <input type="hidden" name="Transaction" value="withdraw" /> <input type="hidden" name="Amount" value="1000000" /> <input type="submit" value="Click Me"/> </form>
Tenga en cuenta que la acción de formulario se publica en el sitio vulnerable, no en el sitio malicioso. Esta es la parte de "Cross-site" de CSRF.
El usuario hace clic en el botón Enviar. El navegador incluye la cookie de autenticación con la solicitud. La solicitud se ejecuta en el servidor con el contexto de autenticación del usuario y puede hacer cualquier cosa que un usuario autenticado pueda hacer.
Básicamente, cuando siteA.com recibe el ataque CSRF, debe coincidir con el token CSRF en la cookie contra el de la metaetiqueta. Una solicitud legítima incluirá ambas, sin embargo, un ataque de falsificación solo incluirá el token CSRF especificado en la cookie.
La única opción que podría imaginar es hacer que los datos sean accesibles desde JavaScript. De causa en caso de que las cookies sean solo http.
Los tokens de CSRF normalmente van en forma de campos de formulario ocultos. Ponerlos en una metaetiqueta solo tiene sentido si está usando JavaScript. JavaScript podría leer los tokens de la metaetiqueta y publicarlos en una acción.
No querrá poner un token CSRF en una cookie porque la cookie se enviará para cada solicitud al sitio web específico desde el navegador web, independientemente de su origen. La única excepción serían las cookies seguras , que se supone que siguen la misma política de origen.
Para evitar CSRF , necesita un valor enviado con la solicitud que un sitio malicioso no puede enviar. Las cookies de autenticación no son adecuadas porque si un atacante puede hacer que el navegador envíe una solicitud al sitio de la víctima, las cookies se enviarán automáticamente.
Por ejemplo, al enviar un formulario a través de JavaScript contenido en www.evil.com para atacar la sesión del usuario en www.example.com :
<form method="post" action="https://www.example.com/executeAction">
<input type="hidden" name="action" value="deleteAllUsers">
</form>
<script>document.forms[0].submit()</script>
El almacenamiento de un token anti CRSF dentro de la página es la solución recomendada por OWASP para evitar que otro sitio web envíe el formulario, ya que el token aleatorio en la sesión del usuario no puede ser leído por www.evil.com debido a la misma política de origen que impide JavaScript en www.evil.com leyendo el contenido de la página de www.example.com .
Estos tokens se pueden almacenar en cualquier lugar dentro de la página. Lo más habitual es que esté dentro de los campos de formulario ocultos, pero también podrían almacenarse dentro de los atributos de datos HTML 5 . Parece que el uso de meta es simplemente otra forma en que puede almacenarse, donde el JavaScript puede incluirlo en cualquier forma que envíe la página.