In what case can CSRF-exempt be dangerous?

Question

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.

Cecrops

Answer 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.

Paragon

There is a dim light appearing at the end of the tunnel... So if i wanted to send evil things to a server, i first would have to send some data to some users browser. In this data i hide some automatically posting form that sends to the server to be attacked. I assume that the user is logged in to that server, because he has an account there. And if the server wouldn't check for some token, it would just have to believe that request was legitimate. At least i have an idea now how it works, and where to draw the line to MIM and XSS. Thanks for that. – Cecrops

@Cecrops CSRF is not about sending malicious data to the server. It’s primarily about impersonation as the attacking site can send legitimate and authentic requests in behalf of the victim. Eavesdropping, MITM, and XSS are only means to get grasp of a mitigating CSRF token (although since most authentication management schemes use cookies based sessions, you could just as well get the session ID instead). – Paragon

So CSRF is all and "only" about pretending to be someone you are not? Where only doesn't mean not important, but everything else is a different attack vector. – Cecrops

Gumbo, so is marue's code dangerous? We would like a clear answer, what do you mean "But if you are protected against those attacks, an attacker won’t be able to forge an authentic request." Thanks – Rosenberg

@LucasOu-Yang The protection against CSRF is requiring something that cannot be forged like a parameter that is not predictable (i.e., the CSRF token). Now if an attacker would be able to get this parameter by eavesdropping, MITM, or XSS, he would be able to forge authentic requests containing that unpredictable parameter. Now if you’re protected against those attacks, an attacker won’t be able to forge an authentic request as he won’t be able to predict the CSRF token. – Paragon

Answer 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.)

Celerity