Cenzic 232 Patent
Paid Advertising
web application security lab

What is CSRF

For the last few days I’ve really been trying to figure out what CSRF (Cross site request forgeries) are. I know that might seem like a pedantic or academic question but it’s really not. Here’s what I’m really concerned with. Without being able to define it we can’t even start talking about how to defend it. Stopping all cross site calls would break the internet and unfortunately wouldn’t solve a lot of the CSRF attacks out there anyway (since many are really SAME site request forgeries).

Here’s what I’m getting at. What if I can force someone to log out. In of itself that isn’t really much of an “attack.” If anything from a security perspective that is helpful because it reduces the overall risks for other CSRF attacks to be successful. However used in some strange DoS attack against the user might prove to be bad. So it’s not the CSRF that’s bad, it’s the DoS that the CSRF helps to create.

Calling a remote function might not be bad (lots of image servers are actually remote databases with an image output). Most would think calling an HTML file in an IMG tag is bad. Well, except if that HTML page is a benign 404 error telling us that the image isn’t hosted there anymore.

There are even more gray areas, like changing someone’s billing information. That would seem to be highly unscrupulous and bad, but if the attacker can’t do anything with it, it really ends up being only a mild inconvenience to the owner of the account when the company in question calls and warns them that their billing information doesn’t match their credit card on file. So while that definitely is a CSRF it’s certainly not an attack of any note. So what is an attack of note? Clearly changing passwords, secret questions or emails qualify. But who’s to say if adding a note to an calendar function or changing someone’s sex from male to female in the database or changing their default time zone is bad or not?

I’ve heard lots of definitions and all of them are skirting around the one major issue, which is what exactly makes the attack “bad” or worth thinking about. XSS seems more clear cut because it’s “bad” if you can get someone else to visit it and if the website is popular, etc… There are a few shades of gray in there but far fewer than with CSRF. If we as a web application security lab can’t define it, how can anyone reasonably expect to stop it?

17 Responses to “What is CSRF”

  1. maluc Says:

    This really is similar to “What is XSS?”. Many would define it as ‘injecting valid html, javascript, or other scripting language commands into a webpage’ .. but thats not totally true either. in the case of: http://mywikisite.com?page=/algebra.html .. changing that page to: http://google.com would also be XSSing. Likewise, a webpage that you may be able to inject HTML into, but whitelists ONLY tags (with no attributes) .. that’s not really XSS.

    So i think the definition you are looking for is just:

    if (
    ( (’Making a server request something it didn’t intend to request’) || (’Making a user request something they didn’t intend to request’) ) && (’Giving a direct/indirect benefit to the attacker’)
    ) then it’s CSRF

    So yes, in your example .. messing up someones billing records may not be an attack of note, UNLESS it benefits the attacker. A great example to illustrate this is the Bank of America DoSing a while ago. When trying a customers password 3 times locked them out of their account. Just an inconvenience, unless the attacker was Chase Bank, trying to lure annoyed customers away from BoA and to open accounts with them. So that too would be CSRF as they are impersonating the customer and making the server do something it didn’t intend to do. RSnake described that idea here: http://ha.ckers.org/blog/20060901/brute-force-password-guessing/

    so yeah, i think the current definitions for both XSS and CSRF are fine.. just with the caveat that it must provide some direct/indirect benefit to the attackers.

  2. RSnake Says:

    That’s the critical point. An advantage to an attacker… that’s fine in principle but what does that mean? Here’s why I’m asking this. If I’m building a web application scanner how do I know if CSRF gives an attacker any value? I can detect that there’s no nonce on just about every function everywhere on the internet. That clearly doesn’t give the attacker and advantage in most cases. How do I programmatically isolate what is interesting and what is not? Advantage, while clear after the fact isn’t clear in a forward thinking web application security scan.

    And, no, I’m not writing a scanner.

  3. maluc Says:

    ah, i see your point.. and i have no idea how an A.I. could differentiate between the two.. aside from trying to with some advanced heuristics :/

    i’m not sure a computer scanner has any hope of doing so without most of them being false positives (theyre not really false though, since they do allow CSRF, but you get the idea). So i think human security analysts should still feel pretty safe with their job security..

    CSRF is just too intrinsic to the functioning of the internet ..

  4. RSnake Says:

    I wish I could disagree but I really think that’s the state of things. I can’t see how a scanner could have any hope in telling me anything that I couldn’t just as easily and more correctly diagnose myself. Bummer.

  5. maluc Says:

    Well i think it goes beyond the scope of scanners anyway. Just like how to prevent a user from accessing an area of the site (which is basic knowledge for a web developer) so should how to protect the forms/commands from being submitted/called remotely be basic knowledge. A scanner also can’t decide what should and shouldn’t be accessible only to logged in users. Developers are already catching on, by doing things like requiring the ‘Current Password’ be entered to change the password. I just don’t think many know whyy they do it.

    If you want to limit access to parts of the website, you do a IsLoggedIn() check.
    If you want to limit forms/commands to not be called remotely, you use a nonce.

    That needs to be a part of every developers basic truths.

  6. Sylvan von Stuppe Says:

    [XC]SRF is a threat. The vulnerabilities (there are multiple) that contribute to it are at least threefold:

    1) long session timeout:
    reducing the session timeout will only reduce the window when the attack would actually function. It’s hard to lure a user to “Log into your sla.ckers.org account, then come visit my site”. But it could still happen.
    2) allowing critical changes over GET:
    this begins to sound like what you’re driving at - define “critical”. But only allowing the stuff to go through POST actually reduces the possibility of [XC]SRF.
    3) lack of flow control:
    sites ought to have some other control to verify that the user is either aware of the change that’s going to take place, or that they’ve visited the change page prior to submitting the change page. The classic examples are things like - require your current password to enter a new one, or enter a CAPTCHA to perform some other critical operation, or to at least use a token in a hidden form that’s matched to the same value in the session

    For the sake of correcting developers, I’m really beginning to look at real vulnerabilities, not just the threats that exploit them.

  7. Brian Says:

    AFAICT, the idea that using post forms reduces the risk of CSRF is a myth. If the browser has javascript enabled, it is easy to submit a post form.

  8. RSnake Says:

    Reduces? Yes… Eliminates? No. The reason why it reduces it is because some websites allow things like remote images. That image can be 301′d back to the site in question causing the CSRF (GET only). So there in lies a reduction, but if there is an iframe, or if the user can get the person to click on a link that has a page with JavaScript on it that they control, then yes, the risk is still there. So reduces, yes, but definitely doesn’t eliminate.

  9. Brian Says:

    Ah, that makes sense. There’s more opportunity for hosting the CSRF attack if a GET request can exploit it. Thanks.

  10. Sylvan von Stuppe Says:

    Boy, I’m really sorry I made mention of that. For some odd reason, I thought that modern browsers wouldn’t allow javascript to submit forms such that the action was on a different host than the page was constructed from (without user interaction, anyhow). After testing it out, it turns out I was REAL wrong.

    So using GET reduces it to a degree - the attacker can’t just use an IMG tag to do it, but can use javascript to submit a form to the site.

  11. RSnake Says:

    No worries, Sylvan, I don’t blame you at all. It’s really not obvious what browsers allow under the hood until you start poking at it (and it’s rarely what you think is going to happen. The problem most web apps have regarding CSRF is that they intend to be POST only, but if you change the method to GET it still accepts the results.

    Restricting those forms to POST only (and erroring out or otherwise not allowing GET requests) does limit the vulnerability slightly (of course you can still force a JavaScript click so if they control the page or can get you to go to a page that they do control it’s meaningless).

    That’s where nonces come in, although XMLHTTPRequest can read things on the page, so you better hope you don’t have a XSS hole.

  12. Sylvan von Stuppe Says:

    But the XmlHttpRequest I know can’t (at least in modern browsers) go cross-domain. So it would require a script injection vulnerability somewhere on the recipient domain (the legitimate domain we want the victim to click to.) I assume that’s where you’re implying the XSS hole must be.

  13. RSnake Says:

    That’s right. Sorry, that did sound confusing. The cross domain stuff comes in when there is a form that accepts POST methods only. You can create a page that has a form that submits to the remote website via POST through a JavaScript click event. If it’s protected by a nonce that vulnerability goes away, but most websites aren’t protected by CSRF in this way.

  14. Maria Says:

    I have read this article and all the response, they are quit interesting and helped me to understand what exactly CSRF vulnerability is. I would like to know, how to carry out testing techniques in order to ensure that a web application is not vulnerable to CSRF vulnerabilities?

  15. RSnake Says:

    The simplest answer is try to construct a) an image tag or b) a piece of JavaScript that attempts to exploit the function at hand from a page that don’t normally have control over that function (off site is the best example, unless your site is prone to have XSS holes - as most are). The only trick there is that many sites allow you to change POST requests to GET requests and the site still happily allows it. If you want you can drop me an email offline and we can talk about it. It can get really complicated depending on the function and your site and it’s somewhat off topic to this discussion.

  16. Jeremiah Grossman Says:

    That’s right, every “important” feature of every website would need to be tested and/or protected. The word “important” being subjective. Is Google’s search “important” enough to be protected against CSRF? Not from Google standpoint, but certainly from a users perspective. That’s why I said in my earlier post that “CSRF may in fact represent an industry challenge far exceeding that of Cross-Site Scripting (XSS).”

    http://jeremiahgrossman.blogspot.com/2006/09/csrf-sleeping-giant.html

    Because basically we can’t find all the bulk of CSRF vulnerabilities quickly like we can with XSS. And furthermore I as a user would prefer not to depend on the security of some website to protect me. Fun times ahead when the two are combined.

  17. Suvra Chakraborty Says:

    Can u pls send me some useful notes and implementations on CSRF….

    I found it too interesting….Like some books and info….

    Regards
    Suvra