In what case can CSRF-exempt be dangerous?

问题:

This question is more a re-insurance than one directly about how to code. As an autodidact i did not have a lot of possibilities to ask professionals such things, so i try here.

I have read the documents in the django-docs ( https://docs.djangoproject.com/en/1.3/ref/contrib/csrf/ ) and some info on that page: http://cwe.mitre.org/top25/#CWE-352

As far as i have understood, django delivers a token (some kind of pin-code) to a user. And to verify it really is him, he has to return it the next time he does a request. And some guys at Google found out that this is even possible with ajax-requests, which is why we have the new policy of protecting them too since 1.2.6. And CSRF is about someone giving me something (bad, dangerous code, corrupt files or something like that) pretending to be someone else.

So if i have some code like this:

@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))

that should be save, as i'm not giving access to the database or any part of my application before trying to convert the given value to an integer. And there is not too much damage if i do a wrong record of someone downloading a file (in this case it is almost none). Assuming i would write bills relying on this view, the CSRF-exempt would be vary bad idea (Is that right?).

I also do not understand why somebody can't steal the CSRF-token from a user and use it to still trick me (or the user). So i have some questions about this topic:

1) are my assumptions from above right?

2) can somebody tell me, what (and probably how) some not so nice guy could use the view above to do dirty tricks, and what would they be?

3) is a CSRF an example of a man-in-the-middle attack, is it just related to it, or is it something entirely different?

4) Any valuable links to do further reading on such dangers?

Maybe some of these questions sound no too well informed, but i'm trying to get over that. I would be very glad if someone could help me.

回答1:

CSRF attacks are about forcing a victims browser to send forged requests. A simple <img> or automatically submitted <form> suffice to do this for both GET and POST method. And as the requests are send by the browser, it sends any authentication credentials along and thus making the requests seem authentic and legitimate from the server’s point of view as they basically don’t differ from those initiated by the user’s actions.

And that’s exactly what the CSRF token is used for: establish a difference between requests that were initiated by the user and those that were forged by a third party site. For this purpose the CSRF token acts as a secret that is only known to the server and the user. The server puts the secret in the document in a response and expects it to be send back in the next request.

And as the secret is embedded in the response’s document that is assigned for this specific user, an attacker would need to eavesdrop that specific response or access the document in some other way. There certainly are attacks get the CSRF token (e. g. eavesdropping, MITM, XSS, etc.). But if you are protected against those attacks, an attacker won’t be able to forge an authentic request.

回答2:

CSRF attack

I trick you into viewing a webpage where I inserted some code (a request, typically through img or form) to another site (where you possibly have some rights).

Innocuous example

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

I cruelly changed the language of your session to french. Oh noes! You can safely remove csrf protection and save a db hit.

Dangerous examples

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

If you were logged in in yourbank.net (and it has no csrf or any other protection), your account should feel lighter by now. (I am 123.)

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

If you were logged in in yoursite.net as an admin, then we both are. (I am 123.)