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í.¿En qué caso puede ser exento de CSRF ser peligroso?
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.
Aparece una luz tenue al final del túnel ... Así que si quisiera enviar cosas malvadas a un servidor, primero tendría que enviar algunos datos al navegador de algunos usuarios. En estos datos, oculto algunos formularios que se envían automáticamente al servidor para ser atacados. Supongo que el usuario ha iniciado sesión en ese servidor, porque tiene una cuenta allí. Y si el servidor no verificara algún token, simplemente tendría que creer que la solicitud era legítima. Al menos ahora tengo una idea de cómo funciona, y dónde dibujar la línea a MIM y XSS. Gracias por eso. – marue
@marue CSRF no se trata de enviar datos maliciosos al servidor. Se trata principalmente de la suplantación, ya que el sitio de ataque puede enviar solicitudes legítimas y auténticas en nombre de la víctima. Eavesdropping, MITM y XSS son solo medios para comprender un token CSRF mitigante (aunque dado que la mayoría de los esquemas de administración de autenticación utilizan sesiones basadas en cookies, también podrías obtener el ID de sesión). – Gumbo
Entonces CSRF es todo y "solo" para pretender ser alguien que no eres? Donde solo no significa que no es importante, pero todo lo demás es un vector de ataque diferente. – marue