5

What is CSRF?

I need a basic definition that is not just lifted from Wikipedia.

I understand SQL injection, XSS, cookie poisoning, but I just cannot wrap my mind around this.

I am using a framework, CakePHP, that has a component that automatically prevent this CSRF. However, whenever I do something to the form like using jQuery to alter the values of the field. Or when I include some Ajax that works with Flash plugins like Uploadify, I need to disable CSRF.

SO how do I, in principle get to prevent CSRF when such elements are involved in the form?

Anders
  • 64,406
  • 24
  • 178
  • 215
Kim Stacks
  • 905
  • 9
  • 21

1 Answers1

7

CSRF or Cross-Site Request Forgery is basically a bad person tricking a good person's browser into performing functions on your website on the bad persons behalf.

Here is an example:

  1. Good user logs into your website and obtains a valid session
  2. Bad user tricks good user into following a link to a malicious site
  3. Malicious site contains a form with falsified data which posts to your website (however since it's sent from client side, your site thinks it originated from the good user)
  4. Your site then see's the good user submitted a form and processes the action.

Let's put it into context:

  1. Good user is an administrator on your website.
  2. From the admin panel, good user can add a user by filling out a form that looks like this:

    <form action="/new_user.php" name="myform" method="POST">
        <input type="text" name="new_username">
        <input type="password" name="new_password">
        <input type="Submit">
    </form>
    
  3. Good user follows a link to a malicious site, which contains the following javascript:

    <form action="http://www.yoursite.com/new_user.php" name="myform" method="POST">
        <input type="hidden" name="new_username" value="MaliciousHax0r">
        <input type="hidden" name="new_password" value="MaliciousPass">
    </form>
    <script type="text/javascript">
        document.myform.submit();
    </script>
    
  4. Your application now receives the request which was submitted by Good user, on Bad user's behalf. Since it originated from Good user, who happens to be logged into your website, all is well and your website processes the request.

Now keep in mind this is a simple example, and the Good user would see the submit happen which SHOULD raise a red flag, however using slightly more complex methods, such as XMLHttpRequest() in javascript would be silent/unknown to the Good user.

Bad user has now obtained an account on your system.

How to eliminate CSRF:

  1. The trick is to add a token to each form that has a random value which is generated for each request.
  2. When the form is submitted, your application checks to make sure the token is passed, and matches the random one which was generated when the form was loaded.

The malicious site wouldn't have access to this token, therefore it wouldn't be able to provide that required peice, and a form submission would not be processed.

How to make other tools work without disabling CSRF protection in CakePHP:

I don't know. Check documentation for the CSRF protection, for CakePHP, and for the other addons.

Question whether or not using those addons is worth the loss in CSRF protection, and consider alternate solutions.

CSRF Resource:

https://www.fortify.com/vulncat/en/vulncat/javascript/csrf.html

Purge
  • 1,996
  • 2
  • 14
  • 26
  • 2
    Correction to the first paragraph: CSRF is not about tricking a good user into following a link; it's about tricking the browser into following a link. It's not about social engineering or fooling unwary users; there's nothing users can do about. The detailed attack description is correct, but I suggest correcting the overview at the beginning of your answer. – D.W. Jan 19 '11 at 07:19
  • My first paragraph doesn't say that a good user followed a link. My example says that. However I see how you could misconstrue what my first paragraph said to mean something different, so I will reword it. – Purge Jan 19 '11 at 14:07
  • 1
    While your countermeasure is technically correct, it is missing some detail - and its good that it is. Since doing this right is complicated, and prone to subtle mistakes, you're much better off NOT doing this - instead, use either standard mechanisms built into your framework, or standard ready-made libraries (e.g. OWASP has a decent CSRFGuard). Alternatively, re-authentication can more be appropriate in certain scenarios... Final answer? Don't disable existing CSRF protection (as you hinted at...) Figure out how to do AJAX securely. – AviD Jan 20 '11 at 01:42
  • You make a good point. I would definitely use CSRF protection built into your framework, or a well adopted, well tested library before "rolling my own." I do not think that the countermeasure in my example is any less correct/feasible, or less secure (when implemented correctly), but I don't discount that using a ready-made feature, or library is an easier solution. – Purge Jan 20 '11 at 16:59
  • @Alex, sorry was away for so long. I like how you gave SIMPLE code examples in step 2 and step 3.Can you give similarly SIMPLE code examples in your step 1 and 2 for eliminating CSRF? Thank you – Kim Stacks Feb 10 '11 at 18:59
  • @Avid, hi there, can you give me examples to how to do Ajax securely? I think this veers a bit off from the original question so i have created [another question](http://security.stackexchange.com/questions/2099/how-to-do-ajax-securely) for this. Thank you. – Kim Stacks Feb 10 '11 at 19:07
  • Well, step 1 doesn't really have any code associated with it, it's just a preexisting condition. The user is an administrator. Step 2 and Step 3 have code associated with it, and step 4 explains what happens if the listed code is used in such a manner. – Purge Feb 11 '11 at 20:22
  • 2
    @Alex, thanks, your edit is an improvement. However, your example is still misleading. In step 2, you talk about tricking the good user into following a bad link. CSRF does not require the attacker to trick the user into clicking on or following any links. CSRF does not require any user interaction. CSRF involves causing the *browser* to follow a link, not tricking the user into following a link. – D.W. Feb 12 '11 at 03:09
  • @D.W. At some point, the user must go to the malicious site, how else would they end up at the malicious site? The browser doesn't get tricked into following a link, the user gets tricked into going to a malicious page where the browser is then tricked into submitting a form on the user's behalf. I think we are getting into the weeds and being nitpicky, but for the sake of clarity, correct me if I'm wrong. – Purge Feb 14 '11 at 15:56