¿En qué caso puede ser exento de CSRF ser peligroso?

Question

Esta pregunta es más un reaseguro que uno directamente sobre cómo codificar. Como autodidacta, no tenía muchas posibilidades de preguntarle a profesionales tales cosas, así que lo intento aquí.

He leído los documentos en los django-docs (https://docs.djangoproject.com/en/1.3/ref/contrib/csrf/) y algo de información en esa página: http://cwe.mitre.org/top25/#CWE-352

Por lo que yo he entendido, Django entrega una ficha (una especie de código pin) a una usuario. Y para verificar que realmente es él, debe devolverlo la próxima vez que haga una solicitud. Y algunos muchachos de Google descubrieron que esto es posible incluso con solicitudes jajax, por lo que también tenemos la nueva política de protegerlos desde 1.2.6. Y CSRF se trata de alguien que me da algo (código malo, peligroso, archivos corruptos o algo así) pretendiendo ser otra persona.

Así que si tengo un poco de código como este:

@csrf_exempt  
def grab(request): 
    """ 
    view to download an item 
    POST because it stores that a user has downloaded this item 
    """ 
    item_id = request.POST.get('item', None) 
    if not loop: return HttpResponseBadRequest('no item id provided') 
    item = Item.objects.get(pk=int(item_id)) 

que debe ser ahorrar, ya que no estoy dando acceso a la base de datos o cualquier parte de mi solicitud antes de intentar convertir el valor dado a una entero. Y no hay demasiado daño si hago un registro incorrecto de alguien que descarga un archivo (en este caso es casi nulo). Asumiendo que escribiría facturas confiando en esta vista, el exento de CSRF sería una mala idea (¿es eso correcto?).

Tampoco entiendo por qué alguien no puede robar el CSRF-token de un usuario y usarlo para engañarme a mí (o al usuario). Entonces tengo algunas preguntas sobre este tema:

1) son mis suposiciones de arriba a la derecha?

2) ¿alguien puede decirme, qué (y probablemente cómo) algún tipo no tan agradable podría usar la vista de arriba para hacer trucos sucios, y cuáles serían?

3) es un CSRF un ejemplo de un ataque de hombre en el medio, ¿está relacionado con él o es algo completamente diferente?

4) ¿Algún enlace valioso para seguir leyendo sobre tales peligros?

Tal vez algunas de estas preguntas no parezcan demasiado bien informadas, pero estoy tratando de superar eso. Estaría muy contento si alguien pudiera ayudarme.

Answer 1

CSRF attacks se trata de forzar a un navegador de víctimas para que envíe solicitudes falsificadas. Un simple <img> o automáticamente enviado <form> es suficiente para hacer esto tanto para el método GET como POST. Y a medida que el navegador envía las solicitudes, envía las credenciales de autenticación y hace que las solicitudes parezcan auténticas y legítimas desde el punto de vista del servidor, ya que básicamente no difieren de las iniciadas por las acciones del usuario.

Y eso es exactamente para lo que se usa el token CSRF: establezca una diferencia entre las solicitudes iniciadas por el usuario y aquellas que fueron falsificadas por un sitio de terceros. Para este propósito, el token CSRF actúa como un secreto que solo conocen el servidor y el usuario. El servidor pone el secreto en el documento en una respuesta y espera que se envíe de vuelta en la próxima solicitud.

Y como el secreto está incrustado en el documento de respuesta asignado a este usuario específico, un atacante tendría que espiar esa respuesta específica o acceder al documento de alguna otra manera. Ciertamente, los ataques obtienen el token CSRF (por ejemplo, eavesdropping, MITM, XSS, etc.). Pero si está protegido contra esos ataques, un atacante no podrá falsificar una solicitud auténtica.

Answer 2

CSRF ataque

que engañarle para que visualiza una página Web, donde me inserta un código (una solicitud, normalmente a través de img o form) a otro sitio (en la que, posiblemente, tiene algunos derechos).

ejemplo inocuo

<img src="http://www.yoursite.net/changelanguage?lang=fr"> 

que cruelmente ha cambiado el idioma de su sesión al francés. Oh no! Puede eliminar de forma segura la protección csrf y guardar un hit de db.

ejemplos peligrosas

<img src="http://www.yourbank.net/sendmoney?amt=9999&account=123> 

Si estaba conectado en yourbank.net (y no tiene csrf o cualquier otro tipo de protección), su cuenta debe sentirse más ligero por ahora. (Tengo 123.)

<img src="http://www.yoursite.net/admin/users/123/edit?admin=1"> 

Si usted inició sesión en yoursite.net como administrador, entonces ambos lo somos. (Tengo 123.)