Security Csrf Introduction


// Security - Cross-Site Request Forgery (CSRF):

CSRF is a common web application vulnerability that has been around for years.  
Because it is so prevalent in web applications, it has been listed as one of the 
top web vulnerability since 2007.

CSRF is a vulnerability where a malicious application cause a user's client to 
perform action on a trusted site without the user's knowledge if the user is 
already authenticated.

Consider that you are already authenticated on a trusted site, but you decide to 
visit another site (trusted but hacked).  The hacked site can have JavaScript 
code that create hidden iframe that go to the trusted site, and perform actions 
without your knowledge.

In order to carry out a CSRF attack, the attacker must somehow lure the 
potential victims to the hacked site (while these potential victims is already 
authenticated on the trusted site).  Both of these criteria are trivial, because 
nowadays we typically do not sign out of web application, so that we do not have 
to login again with username and password the next time we need to access the 
web application again.  And it is also fairly trivial to trick potential victims 
to visit hacked / malicious site by using domain names that look similar to the 
trusted site.

If that attack is successful, the impact can be severe, ranging from creating 
or modifying users to deleting data and even account compromise.

For CSRF attacks to succeed, the attacker had to know the exact name of the 
parameter, and also supply the associated values.  To prvent CSRF attacks, we 
typically append an extra parameter (a token) that is random (unique value) that 
is changed on every request.  This would make it next to impossible for the 
attacker to guess the value, and thus prevent the attack.  For this technique to 
be useful, four things must happen:

1. All sensitive state changing requests must include the token

2. The token must be unique to the request or user's session.

3. The token must be difficult to predict (long and random)

4. The token must be validated by the server to ensure that the request is
   originated by the intended user, and is not forged.

When a Web application formulates a request (by generating a link or form that 
causes a request when submitted or clicked by the user), the application should 
include a hidden input parameter with a common name such as "CSRFToken". The 
value of this token must be randomly generated such that it cannot be guessed 
by an attacker. Consider leveraging the class for 
Java applications to generate a sufficiently long random token. Alternative 
generation algorithms include the use of 256-bit BASE64 encoded hashes. 
Developers that choose this generation algorithm must make sure that there is 
randomness and uniqueness utilized in the data that is hashed to generate the 
random token.

Consider anyone who can load content into your users’ browsers, and thus force 
them to submit a request to your website. Any website or other HTML feed that 
your users access could do this.  Consider a web site that the user visit often 
but it is recently hacked, and the attacker modified this web site, or post a 
Cross Site Scripting attack onto a page that the user visit often.  This script 
can be malicious in such a way that it cause the browser to submit or send 
requests to your server.  If the user is already authenticated on your web site, 
your server may think that the request is initiated by the user, but it is not.

Attacker creates forged HTTP requests and tricks a victim into submitting them 
via image tags, XSS, or numerous other techniques. If the user is authenticated, 
the attack succeeds.

The script can do any state changing operation that the victim is authorized to 
perform, e.g., updating account details, making purchases, change password, 
logout and even login.

Consider another example.  You are already authenticated on your favorite web 
site.  Your favorite web site has a link that perform state changing operation.  For
example, it contains a link or a button to delete a particular row from the database.
An attacker can use his own account to determine the URL, but swap out the ID
of the database record.  The attacker can email you this link, or somehow trick 
you to use it.  If you use this link, you do state changing operation without even
knowing it.

To check whether an application is vulnerable, see if any links and forms lack 
an unpredictable CSRF token. Without such a token, attackers can forge malicious 
requests. An alternate defense is to require the user to prove they intended to 
submit the request, either through reauthentication, or some other proof they 
are a real user (e.g., a CAPTCHA).

Focus on the links and forms that invoke state-changing functions, since those 
are the most important CSRF targets.

You should check multistep transactions, as they are not inherently immune. 
Attackers can easily forge a series of requests by using multiple tags or 
possibly JavaScript.

Note that session cookies, source IP addresses, and other information 
automatically sent by the browser don’t provide any defense against CSRF since 
this information is also included in forged requests.

OWASP’s CSRF Tester tool ( can help 
generate test cases to demonstrate the dangers of CSRF flaws.
Unless otherwise stated, the content of this page is licensed under Creative Commons Attribution-ShareAlike 3.0 License