CSRF and XSS – Brothers in Arms

What is CSRF (XSRF)?

Cross-Site Request Forgery is a type of web attack which exploits the trust of a website in the user’s browser. In essence, the attacker manipulates the victim’s browser to send requests in the user’s name to websites that have been visited or are currently open, without the victim knowing what is happening in the background.

For example, if the victim is an accountant for a small business, making online payments to suppliers and contractors on a daily basis, it is highly likely that the victim’s browser has authentication cookies available for the online payment website or web application (https://www.mybank.com). Assuming that the attackers know the online payment web application, they can craft legitimate money transfer requests (https://www.mybank.com/accounts/transfer.asp?sum=100&target=D09832123) and then trick the victims into visiting malicious web pages that will manipulate their browser into sending these requests to the online payment system. The end result may be the online payment system transferring funds to the target account.

Anatomy of a CSRF attack

1. Attacker prepares a malicious web page that can cause victims’ browsers to send valid payment transfer requests.

• Example: The attacker creates maliciouspage.html and embeds the following iframe code <iframe src=https://www.mybank.com/accounts/transfer.asp?sum=100&target=D093487324></iframe>.
• Prerequisites: The attacker studies the way the mybank online payment system works, using a legitimate account and tools to sniff the HTTP requests being sent by the browser as part of legitimate transactions.
• Variations: The forged request can be embedded straight in an email message, case in which there is no need for the web page. However by using a malicious web page, the attacker can get insight into how the attack is progressing by analyzing the web server logs.

2. The attacker sends out SPAM (via email, social networks, etc.) containing a (hidden) link to maliciouspage.html hoping that SPAM will reach users of mybank who frequently use the online payment system.

3. When the SPAM reaches such a victim, assuming they click through it and reach maliciouspage.html, their browser will send a request to https://www.mybank.com for transferring 100 USD into account D093487324.

Immediate consequences of CSRF:

• Damage to the victim’s account
• The attack is untraceable in the bank’s web server logs – the malicious request is sent in the victim’s name, just as any other legitimate request for money transfer issued by the victim.
• The attack is undetected by the victim, if sufficiently small amounts of money are transferred, such attacks may remain unnoticed for long periods of time.

Example of a CSRF attack (click to enlarge)

Similarly, victims may perform unwanted actions on other websites like CRM/ERP systems, blogs, forums and social websites. CSRF can also be used to perform unwanted changes to router, firewall or Internet gateway configurations opening backdoors for further, better targeted attacks.

XSS gives a helping hand

As opposed to CSRF, XSS exploits the trust of the victim’s browser in a web server. While CSRF does not require the presence of a vulnerability per se, XSS needs a vulnerability in order to take place.

The two attacks are different and are rivals when it comes to damage, popularity and ease of enacting, but they can also work together and when that happens, the consequences are far more devastating. In order to see how XSS can aid CSRF, we need to have a look at common CSRF counter measures.

The simplicity of a CSRF attack, as well as the implications of the attack being successful, make it a serious security concern when it comes to developing web applications. Hence, countermeasures are taken to prevent CSRF from happening: token-based counter measures, referer or origin verifications and user unfriendly methods such as CAPTCHA codes, re-authentication, etc.

However if there is an XSS vulnerability, then malicious XSS payloads may enable attackers to execute code in the user context and render CSRF protection measures useless.

Reading tokens via XSS

If the tokens are stored in cookies, XSS attacks can be used to read the cookies and obtain the tokens which need to be embedded in the malicious requests in order for them to be successful. If the tokens are generated by the server, then XSS can be used to read (GET) a page on the server (XMLHttpRequest), record the valid token and embed it in the malicious requests, making CSRF possible.

Let’s assume that https://www.mybank.com/transfer protects all the POST requests with a token. If there is an XSS vulnerability on the same domain (let’s say https://www.mybank.com/accounts) then an XSS attack can be used to read the tokens used by https://www.mybank.com/transfer:

//get token by opening a page where POST is protected by the token

varpage = new XMLHttpRequest();
page.open("GET", "https://www.mybank.com/accounts/home", false); "//open any page protecting POST with token
page.withCredentials=true;
var ID = page.responseText;
var i = ID.indexOf("tokenidentifier");
ID = ID.substring(i,ID.length).substr(x,y);

//embed token into CSRF request
page.open("POST", "https://www.mybank.com/accounts/transfer.asp", false);
page.withCredentials=true;
var params = "sum=100&target=D093487324&tokenidentifier="+ID;
page.setRequestHeader("Content-length", params.length);
page.send(params);

An attack pattern such as the one below was used by the Sammy Worm (an XSS-based worm) in 2005 to propagate across MySpace. Similarly, same origin or referer verifications can be bypassed by manipulating victim’s browser and faking HTTP headers.

XSS helps CSRF bypass POST protection token

Cross-site scripting vulnerabilities pose security concerns beyond CSRF because they allow attackers to remotely control a victim’s browser with full privileges, making CSRF unnecessary.

In conclusion, as long as a vulnerability exists anywhere in the domain, the entire domain is compromised and valid protective measures against CSRF can be rendered useless.

THE AUTHOR

Acunetix

Acunetix developers and tech agents regularly contribute to the blog. All the Acunetix developers come with years of experience in the web security sphere.