Protect Your Assets
Showing results for 
Search instead for 
Do you mean 

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

danielmiessler ‎03-13-2014 09:27 AM - edited ‎07-07-2015 12:37 PM


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, 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



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:

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 ( here, can be on a malicious site (, 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, and it fired off the transfer request. And because that cookie was still valid on, 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.
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 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 and on Twitter at @danielmiessler

0 Kudos
About the Author


27 Feb - 2 March 2017
Barcelona | Fira Gran Via
Mobile World Congress 2017
Hewlett Packard Enterprise at Mobile World Congress 2017, Barcelona | Fira Gran Via Location: Hall 3, Booth 3E11
Read more
Each Month in 2017
Software Expert Days - 2017
Join us online to talk directly with our Software experts during online Expert Days. Find information here about past, current, and upcoming Expert Da...
Read more
View all