Jason Taylor on Security Testing

Posted June 17, 2008 by Kevin Poniatowskia

Tester Question: What is a cross-site request forgery attack? How do I test our website to see if it is vulnerable to this attack?

Cross-Site Request Forgery Attack explained: Cross-Site Request Forgery (CSRF or XSRF) is an attack that tricks the victim's browser into performing an undesired action on the victim's behalf. For example, this attack could result in a transfer of funds, changing a password, or purchasing an item. For most websites browsers will automatically include any credentials associated with the site when they perform these types of actions. If the victim is currently authenticated to use a website, there is no way for the browser to distinguish between a valid action chosen by the user or a malicious action initiated by an attacker due to the exploitation of a CSRF vulnerability.

For example, imagine an online banking site that performs a transfer of funds action by calling a URL such as:

http://bigsafebank.com/transfer.do?acct=ATTACKER&amount=1000

This URL will transfer $1000 from a victim’s account into the attacker’s account if the victim is logged into their account within the BigSafeBank website. The attacker knows that there isn’t much chance of getting a user to click on that link due to its suspicious looking nature, so the attacker must fool the victim into clicking the link and executing the malicious action.

The attacker can create an HTML email with a tag such as:

When a victim views this HTML email, they will see an error indicating that the image could not be loaded within the browser, but the browser would still submit the transfer request to bigsafebank.com without requiring any further interaction from the user. Even though the image was rendered unsuccessfully, using the <img> tag, an automatic http request was made that contained the victim's credentials, allowing the server to perform the malicious action.

While using the <img> tag is a common way to create the CSRF attack, it is by no means the only HTML tag that can be used to perform this attack. Among the other HTML tags that can be used to create a CSRF attack are the <script> and <iframe> tags. These tags could also have URLs embedded within them that create the automatic http request partnered with a malicious action. The attacker could also create a CSRF attack using Javascript. For example, an attacker could create an Image object that preloads an image, in this case, the image would be a URL containing a malicious action like in the code below:

A web application's vulnerability to CSRF is due to the following conditions:

The use of certain HTML tags will result in automatic HTTP Request execution.
Our browsers have no way of telling if a resource referenced by an <img> tag is a legitimate image.
The loading of an image will happen regardless of where that image is located.
Code within the web application performs security sensitive operations in response to requests without validation of the user.

GET requests are especially vulnerable to this type of attack, but POST requests are not immune. An attacker could write their own website and use JavaScript to auto submit their form to a target location on a victim's website. While using a POST request to perform this attack makes it much more difficult to implement than performing a GET request, the attack is still possible.

There are a couple of mitigations that developers can make within their code that will reduce the likelihood of a successful CSRF attack. The most common defense is to append challenge tokens to each request. These challenge tokens must be associated with the user's session. This will prevent an attacker from providing a valid token of their own to utilize within the attack. By including a challenge token with each request, the developer can ensure that the request is valid and not coming from another source other than the user. Another mitigation that will reduce the chances of a CSRF attack is to rely on the HTTP Referrer header. While this field can be spoofed, they can provide the user protection if the CSRF attack is coming from a link that was clicked within an email.

Testing for Cross-Site Request Forgery vulnerabilities:
Now that you've seen how damaging a CSRF attack can be, let's look at how you would test for this type of vulnerability in your application.

Look for areas in your application that will perform an action on the user's behalf, using their security context, in response to an HTTP GET request.
Create a URL address for the malicious action to be performed. For example: http://malicious.com/[action]
Create an email that contains HTML that references that URL address. For example, the img tag could be used: <img src="http://malicious.com/[action]" width="1" height="1" border="0">
Log into a valid testing account as the "victim".
After successfully authentication has occurred, click on the malicious testing link in the email that was previously created.
Observe the results. If the web server executed the request contained within the malicious email, a CSRF vulnerability was found!

This test makes use of the fact that the resources were available via the HTTP GET request. POST requests can also be vulnerable to CSRF, but these requests must be done using a scripting language that will auto-submit a form that includes the malicious tags.

One of the common mistakes that users make is that the CSRF attack will take advantage of the fact that many users forget to logout of web applications when they are finished using them. Doing this doesn't give the web applications a chance to clear their session IDs or other types of session information from the cookie, allowing the CSRF attack to be successful even when the user is not actively browsing vulnerable websites.

Additional Resources:

For more about CSRF, check out the Cross Site Request Forgery FAQ at: http://www.cgisecurity.com/articles/csrf-faq.shtml

Another great site for information about CSRF is: http://www.owasp.org/index.php/CSRF