The Secure Web Series, Part 3: Protecting Against Cross-site Request Forgery (CSRF)

Screen Shot 2014-03-10 at 3.13.15 PM.png

 

Welcome to the third post in a series on how to avoid common web application vulnerabilities, called The Secure Web SeriesIn this series of posts we explore some of the most common vulnerabilities we see in our testing practice here at Fortify on Demand

The focus of the series is on vulnerabilities that aren’t easily identified via automation, as these are harder to find using readily available tools and many testing offerings tend to miss them during assessments. 
In each installment of the series we’ll cover the following areas:

  • The most common flaws we see in the real world for this particular component of web applications
  • How to avoid making each of those mistakes
  • A list of best practices for that component
 
What is CSRF?
 
For being as dangerous and as common as it is, Cross-site Scripting (CSRF) is remarkably misunderstood--even among security professionals. Many think it's a type of injection attack, and even more think it's a subclass of Cross-site Scripting (XSS). It's neither. Here's our preferred definition:
 
Cross-site Request Forgery
A vulnerabiility in a website that allows an attacker to trick a victim into performing malicious actions without their knowledge.
 
CSRF is an attack designed to accomplish one goal: Get a victim to perform an action that 1) is good for the attacker, and 2) can only be done by the victim.
 
That second part is important. 
 
Much of browser security revolves around a security model called the Same Origin Policy, which, among other things, restricts attackers from accessing a user's cookies. This is key because cookies often serve as proof of previous authenitcation, and in poorly coded applications that could mean that you can perform an action just by sending along that cookie.
 
And that's largely what CSRF is about. Attackers often can't steal your cookies, but what they CAN do is trick you (or your browser, actually) into making a request that is bad for you and good for the attacker. And because YOU are the one making the request (which you're proving by sending your cookie with the request), the action complies with the Same Origin Policy (SOP).
 
The key here is that browsers always send whatever cookies they have to the domains they are requesting. So if you're going to ads.somewebsite.com, you're sending along (with EVERY request) every single cookie you have for that domain. That's what makes this attack so powerful.
 
Here are some examples of attacker-forced actions:
 
  1. Making a bank transfer
  2. Creating a user on a system
  3. Promoting a regular user to an administrative user
  4. Deleting an account / logging out of a system

On many websites, these actions can be performed when just two criteria are present: 1) a request is made to the right page, and 2) you have a valid cookie for the site. This is the crux of CSRF.

 

Identifying CSRF In Your Applications

 

ScopeIcon.png

 

There are three qualifications you need to look for in potential CSRF vulnerabilities:

 

1. Change: You need to be able to change something using the HTTP request. There has to be a different state after the request completes than before, and if there isn't you don't have a CSRF vulnerability.

2. Sensitivity: The functionality that you're modifying needs to be sensitive. It needs to be something like a money transfer, or account privileges, or a salary adjustment, etc. It can't be something like changing your background color from black to baby blue.

3. Generic: The request has to be non-unique, meaning that if you give it to anyone and have them launch it (with your valid cookie) it will work. Anything that stops that effectively removes the CSRF issue.

 

When you think about looking for CSRF manually in your own applications, or (for security consultants) in the applications of your customers, I like to start with Sensitivity

 

Go through your application's functionality and code, and look for all sensitive actions that can be performed. Notice that this language encompasses two components of our criteria--change and sensitivity. Then, once you have those, check those functions for uniqueness.

 

Protecting Against Cross-site Request Forgery

 
Protecting against Cross-site Request Forgery is accomplished, unsuprisingly, by eliminating situations where the criteria of state-change, sensitivity, and non-uniqueness are present.
 
So if you can reduced your CSRF surface area first and foremost by having fewer pieces of functionality that modify sensitive things. But let us just assume that your site already does only what it's supposed to do in this regard, and thus we move to where the focus usually lies--uniqueness.
 
Making your requests unique is the primary defense against CSRF. What this means is that an attacker can no longer simply observe one legitimate transaction within your application and then put that request into an element that loads automatically on a website they control.
 
One way they do this is by taking a bank transfer request, for example, and putting it as the source in an image tag, like so:
 
Screen Shot 2014-03-13 at 9.05.23 AM.png
 
If the application accepts all such requests (with proper cookies, of course) as valid, then any victim who's logged into a given target website (site.com) here, can be on a malicious site (catpictures.com, or whatever the attacker has set up) and trigger this image.
 
Keep in mind: they didn't click anything. Their BROWSER went to load this image for them, from catpictures.com, and it fired off the transfer request. And because that cookie was still valid on site.com, the victim now has less money.
 
Suddenly cookie exipiration doesn't seem so trivial.
 
Anyway, this DOESN'T WORK if there is something about the transfer functionality above that requires uniqueness. In other words, any site that's defended against CSRF would discard such a rudimentary request (and should take additional actions as well, such as blacklisting, notification of the security team, etc.)
 
Here are some ways to add uniqueness:
 
1. Include a nonce (a number used once) in all actions that yield sensitive state changes.
2. Use a CAPTCHA to validate sensitive access or changes (Github uses this)
3. Require re-authentication for sensitive access or actions.
 
One popular variation on #1 involves setting a unique token value in both the user's cookie, and in a POST parameter. So when the user submits a request for a sensitive action, the server looks to ensure that the tokens 1) match, and 2) are valid.
 
Summary
 
There are enough approaches to CSRF defense to fill a small book on their own. The key points to remember are:
 
  1. How to identify CSRF (state change, sensitivity, non-uniqueness),
  2. How attackers weaponize it (by putting auto-loading functionality on malicous pages that your browser consumes)
  3. How to defend against it (by ensuring that your sensitive actions are triggered by unique requests that can only be made by legitimate clients)
There's far more that can be said about CSRF, but this will hopefully help with the basics. Also be sure to come back for the next installment where we'll cover Session Management Issues.
 
As always, feel free to reach out with any questions via Twitter (@danielmiessler) or via email (daniel.miessler@hp.com).
 
 
: :
 
Daniel Miessler is a Practice Principal with Fortify on Demand based out of San Francisco, California. His areas of expertise are web and mobile application security testing and building application security programs for the Global and Fortune 100. He can be reached at daniel.miessler@hp.com and on Twitter at @danielmiessler
 
 

Leave a Comment

We encourage you to share your comments on this post. Comments are moderated and will be reviewed
and posted as promptly as possible during regular business hours

To ensure your comment is published, be sure to follow the Community Guidelines.

Be sure to enter a unique name. You can't reuse a name that's already in use.
Be sure to enter a unique email address. You can't reuse an email address that's already in use.
Type the characters you see in the picture above.Type the words you hear.
Search
Showing results for 
Search instead for 
Do you mean 
About the Author
http://www.danielmiessler.com/about


Follow Us
The opinions expressed above are the personal opinions of the authors, not of HP. By using this site, you accept the Terms of Use and Rules of Participation