Ranked at number eight on the 2013 OWASP Top Ten, Cross-Site Request Forgery (CSRF) remains a major concern. CSRF manipulates a web application vulnerability which allows an attacker to trick the end user into performing unwanted and possibly sensitive actions.
A CSRF attack can occur when an authenticated user moves to a malicious website while still logged into the target web application. Malicious HTTP requests can then be routed to the target site via the victim’s browser. The application will perform the task as requested because it stems from the browser of an authenticated user. Essentially, CSRF is an exploitation of the trust a browser has in an authenticated user. Such an attack is relatively easy to set up and, worryingly, can be difficult to detect. CSRF may be used to steal an authenticated user’s personal details or even perform financial transactions. The recent exposure of a speedily remedied CSRF vulnerability in Twitter was a timely reminder of the continued danger CSRF poses. Twitter joins a high profile list including Gmail, Facebook, Ebay, YouTube, and INGDirect who have all encountered CSRF vulnerabilities in their websites.
A potential CSRF manifestation
Instigated to exploit the domain cookie trust model, CSRF can manifest itself in a number of ways. In the attacker’s ideal situation, the target victim may perform monetary transactions online with a bank whose website is vulnerable to CSRF. The attacker, in targeting all customers of this particular bank, has set up a malicious website that, when navigated to by the still-logged-in victim, will transfer a sum of money to the attacker’s account. The malicious link may take the form of an image, banner ad, or even a site that replicates the bank’s own website. An attacker will typically embed HTML or JavaScript code into the link which will request a specific task – in this scenario, the task involves the transfer of funds to the attacker’s account. With the request originating from the browser of an authenticated user, the online bank processes the task as requested. The user, faced with an error screen, remains none-the-wiser. CSRF vulnerabilities lie at the heart of the HTTP protocol and have proved difficult to eradicate.
Preventing CSRF
There are a number of CSRF prevention techniques in popular usage. One of the most common methods is to implement CSRF tokens with the Synchronizer Token Pattern by appending unpredictable challenge tokens to each request to ensure the validity of the source. The server application must then verify that each sensitive HTTP request contains the correct token. With this defense enabled, a successful attack would require the malicious actor to guess the randomly generated token – a near impossible task. Another prevention method involves validating the HTTP Referrer header. In theory, CSRF attacks are prevented by accepting requests from trusted sources only. It goes without saying that this defense can fail if a site processes requests that do not contain a referer header. Also, CSRF attacks that originate from an HTTPS domain will omit the referrer. Developers should treat HTTPS requests that attempt a state change as an attack. When implemented correctly, the HTTP referrer defense can effectively guard against CSRF attacks. One final caveat to note is that a referrer check can be bypassed with cross-site scripting.
Persistent CSRF risk
CSRF remains a dangerous and widespread vulnerability. With increased awareness of CSRF, many websites have successfully implemented defense mechanisms, but Twitter’s recent exposure to a subtle CSRF flaw offers a timely reminder of the persistent threat.
