Cross-Site Request Forgery – A Significant Threat to Web Applications

Monday, June 08, 2009

Original Source:

Hi, this is Shaomin Wang. I am a security analyst in Oracle’s Security Alerts Group. My primary responsibility is to evaluate the security vulnerabilities reported externally by security researchers on Oracle Fusion Middleware and to ensure timely resolution through the Critical Patch Update. Today, I am going to talk about a serious type of attack: Cross-Site Request Forgery.

Cross-Site Request Forgery (CSRF), also known as Cross-Site Reference Forgery (XSRF), Session Riding and Confused Deputy Attack, is a type of malicious exploit where unauthorized requests are transmitted from a user to a trusted website (the target). CSRF exploits the trust that the targeted site has in a user’s browser and generally works by embedding a link or script in a malicious page (previously compromised by the attacker or belonging to a site specifically built for the purpose of carrying the attack) to access a site to which the user has already been authenticated. Ultimately, the trusted site is the target of the attacks, but the user is both the victim and an unknowing accomplice of the attack.

Here is how CSRF works. Let’s look a simple example where the server authentication is based solely on session cookies.

a) User Alice logs into her bank’s site by providing her username and password. The banking site identifies her and creates a unique session identifier (sid). The sid is saved in Alice’s cookie and passed from Alice’s browser to the banking site for each subsequent request. Each time, the banking site identifies Alice by matching the cookie value sid passed in the request header to the server stored session value. Once identified, Alice is allowed to perform authorized actions.
b) Without logging out her banking site, Alice visits a malicious site “”. “” contains a hidden form/JavaScript code or an image tag that causes Alice’s browser to send a malicious request to her banking site. On this request, Alice’s browser “happily” attaches the cookie containing the session id to “”.
c) Once accepting the malicious request, Alice’s banking site identifies the request as coming from Alice. The malicious request operation is then performed on behalf of Alice, and Voila!!!

CSRFs are not a new class of attack. They can be both simple and devastating. With a little social engineering, the attacker can trick the user into authenticating onto the targeted site, thus ensuring that the CSRF attack will be successful. And because the user’s browser sends the request to the targeted site, CSRF attacks are typically executed with the same level of privileges as the user, meaning any action the user can perform on the targeted site can also be performed by the attacker through the CSRF attack. Consequently, the more privileges a site grants its user, the more impact CSRF attacks can have (thus making financial sites a prime target for malicious perpetrators). If the end user has administrative privileges on the targeted system, a CSRF attack can lead to compromising the entire web application on the targeted system.

Vulnerability to CSRF is extremely widespread. CSRF attacks often exploit the authentication mechanism of targeted sites. In general, whenever authentication happens implicitly, there is a danger of CSRF attacks. Unfortunately, today, most web applications rely solely on automatically submitted credentials such as session cookies, basic authentication credentials, source IP addresses, or SSL certificates.

The concept of CSRF was first introduced in a research paper titled “The confused Deputy: (or why capabilities might have been invented)” by Norman Hardy in 1988. In Feb 2000, CERT published an advisory titled “Malicious HTML Tags Embedded in Client Web Request.” The advisory stated that “At the heart of this vulnerability is the violation of trust that results from the “injected” script or HTML running within the security context established.” In May 2000, Jim Fulton wrote an article, “Client Side Trojan”, on touching upon the same topic, where he stated that “potentially any Web-accessible system is vulnerable to this type of attack.”

CSRF got its current name in 2001 after Peter Watkins posted a note to bugtraq, where he wrote: “The problem is what I call CSRF (Cross-Site Request Forgeries, pronounced ‘sea surf’). Any time you can get a user to open an HTML document, you can use things like IMG tags to forge requests, with that user's credentials, to any Web site you want -- the one the HTML document is on, or any other”.

However, until very recently, CSRF were rarely discussed in the security community. For example, MITRE Vulnerabilities Trends 2007 stated that the first CSRF was reported to CVE in 2002. Until 2006, CSRFs were rarely reported to CVE. However, there have been some high profile CSRF attacks in the last two years:

In 2008, a CSRF vulnerability was found in New York Times’ website. Attackers could take advantage of’s “Email This” feature to obtain user’s email addresses.

The same year, a vulnerability in ING’s website ( was detected. It allowed an attacker to create an additional account on behalf of an arbitrary user. As a result, it was possible for the attacker to move funds out of a customer’s account. This was the first reported time that a CSRF allowed the transfer of funds from a financial institution.

Up to 2008, YouTube was vulnerable to CSRF attacks. Malicious attackers were able to add videos to a user’s “Favorites” list, add themselves as friends to a user, and even send messages on behalf of a user.

Several CSRF server side countermeasures are available, e.g. checking the HTTP referrer header to see if the request is coming from an authorized domain; The more reliable way of counter CSRF attacks is to require a secret, user-specific token in all form submissions.

CSRF vulnerabilities are not as well known and understood by web programmers as Cross Site Scripting Vulnerabilities (XSS). It is my experience that too many web developers are under the wrong impression that XSS fixes can also prevent CSRF attacks. Furthermore, while CSRF attacks do not require exploiting XSS, any application with XSS flaws is susceptible to CSRF. CSRF attacks can exploit the XSS flaw to steal any automatically submitted credential. It is critical that web developers provide defenses against both classes of attacks. I believe that the lack of awareness around CSRF greatly contributes to the prevalence of the attacks.

For more information:

o For an excellent article explaining limitations and prevention measures of CSRF, see:
o A testing guide for CSRF from OWASP:
o Confused deputy problem from Wikipedia:
o Peter Watkins’ note to bugtraq:
Possibly Related Articles:
General Webappsec->General Vulnerabilities
Post Rating I Like this!
avelin injector