¿Para qué sirve realmente la protección CSRF?

He estado escuchando sobre CSRF hace mucho tiempo, y lo que más de las veces oigo es:¿Para qué sirve realmente la protección CSRF?

La protección contra los ataques CSRF es importante para que alguien no enviar su formulario automáticamente (usando un bot o algo así)

Bueno, eso no es 100% cierto, ¿verdad?

He estado haciendo web scraping durante aproximadamente 3 años, y es bastante sencillo realizar una solicitud, analizar el campo csrftokenmiddleware y POST junto con los otros campos.

Entonces, ¿para qué es realmente?

Fuente

2012-04-20 Oscar Mederos

@agf Acabo de leer esa pregunta, y no veo la duplicación ': (' –

Claro, estoy leyendo la respuesta ahora ...;) –

Usted describe una publicación "anónima". Se trata de proteger esa publicación de que ocurra con las credenciales de un usuario autenticado. – Cheekysoft

Sí, puede borrar el formulario y obtener el token de prevención de CSRF. Pero no puede enviar el formulario sin borrar el sitio, y no puede obtener una ficha de otra persona y luego enviar el formulario - está vinculado a una sesión. Eso es lo que evita la protección CSRF realmente, alguien engañando a un usuario para que envíe un formulario.

Una descripción más general de CSRFs, originalmente publicado en respuesta a Django's comments framework and CSRF:

Un CSRF es un ataque donde alguien sin permiso para acceder a un alguien trucos de recursos que tiene el permiso de que la visiten.

Por lo tanto, por ejemplo, la protección CSRF podría evitar que alguien engañe al usuario para que publique un comentario con un enlace de correo no deseado o de malware. Alternativamente, la solicitud que engañan al usuario para que la haga podría estar mal formada, hacer que se bloquee su servidor web o incluir código destinado a pasar por el proceso de validación y dañar su base de datos o poner en peligro su sitio de otras maneras.

De modo que sin la protección CSRF, alguien podría, en teoría, engañar a un usuario que haya iniciado sesión para que envíe un comentario que en realidad no escribió.

Con la protección CSRF, Django detectará que no se trata de datos reales enviados a través del formulario real en su sitio, y lo rechazará.

Fuente

2012-04-20 07:58:28 agf

Es una protección para un tipo diferente de escenario. A veces el atacante puede insertar javascript, ya sea iframes o img src-s en una página suya, en un lugar al que cualquier usuario conectado pueda acceder. Cuando el usuario accede a la página (digamos una página con comentarios, y un comentario solicita un enlace por parte de los atacantes), esa solicitud la realiza el navegador del usuario registrado, junto con sus cookies. CSRF básicamente protege este tipo de envíos desencadenados (envíos simples del lado del cliente). Por supuesto, cualquier atacante puede solicitar la página, analizarla para el token y crear la solicitud con el token, pero no puede hacerlo al lado de un usuario conectado.

Fuente

2012-04-20 08:00:30

Imagine una aplicación web de banca electrónica en banking.example.com con el siguiente formulario para enviar una transacción:

<form action="/transaction" method="post"> 
    <input type="text" name="beneficiary"/> 
    <input type="text" name="amount"/> 
    <input type="submit" value="Pay"/> 
</form>

Un atacante podría ahora crear un sitio web en hacker.net con lo siguiente:

<form action="https://banking.example.com/transaction" method="post" style="visibility:hidden"> 
    <input type="text" name="beneficiary" value="John Doe, Account No. 34-236326-1"/> 
    <input type="text" name="amount" value="1000000"/> 
    <input type="submit" value="Pay"/> 
</form> 
<script> 
    document.forms[0].submit(); 
</script>

El atacante engañaría a las víctimas para que visiten el hacker.net, lo que hará que los navegadores de las víctimas envíen una solicitud POST a la aplicación de banca electrónica, lo que implicará una gran transacción para el pirata informático. Esto funciona porque el navegador de la víctima envía felizmente la cookie de sesión junto con la solicitud POST falsificada a la aplicación de banca electrónica. Si el formulario hubiera estado protegido por un token CSRF, el atacante no podría haber causado que el navegador de la víctima enviara una solicitud POST válida y, por lo tanto, el ataque no sería posible.

Este tipo de ataque se denomina ataque de falsificación de solicitudes entre sitios (CSRF).

Incidentemente, los ataques de CSRF también son la razón por la cual las personas dan el consejo de nunca visitar otros sitios web mientras están conectados a una banca electrónica u otra aplicación web crítica.

Los tokens CSRF no protegen un formulario web que los usuarios normales autorizados envían automáticamente como ellos mismos. Para protegerse de eso, usaría un CAPTCHA.

Fuente

2012-04-20 11:15:17

¿Cómo crees que esto es diferente de validar el referente en el lado del servidor? Sin admitir cookies csrf pero haciendo solo esta validación, aún puedo identificar el ataque. – Ethan

Ok, descubrí por qué no se utiliza el referente. Está bloqueado en muchos casos, ya que se considera que contiene información confidencial a veces. Las empresas y sus representantes suelen hacer eso. Sin embargo, si se utiliza HTTPS, es más probable que no se bloquee. Y, también se menciona que el referente puede ser falso. – Ethan

Me encontré con esta pregunta nuevamente mientras le contaba a un amigo acerca de CORS. 'document.forms [0] .submit();' no funcionaría de todos modos debido a la política del mismo origen, ¿verdad? –

Usted no será capaz de

para hacer una solicitud, analizar el campo csrftokenmiddleware y que lo ponga junto con los otros campos.

porque JS en un dominio diferente no podrá recuperar y utilizar los datos de su dominio para generar solicitudes si su servidor está configurado properly.

Lee sobre CORS.

Fuente

2014-08-12 19:46:59 warmspringwinds

¿Para qué sirve realmente la protección CSRF?

Respuesta

Cuestiones relacionadas