• If you are citizen of an European Union member nation, you may not use this service unless you are at least 16 years old.

  • You already know Dokkio is an AI-powered assistant to organize & manage your digital files & messages. Very soon, Dokkio will support Outlook as well as One Drive. Check it out today!


Cross Site Request Forgery

Page history last edited by Robert Auger 14 years, 6 months ago

Project: WASC Threat Classification

Threat Type: Attack

Reference ID: WASC-9


Cross-Site Request Forgery

A cross-site request forgery is an attack that involves forcing a victim to send an HTTP request to a target destination without their knowledge or intent in order to perform an action as the victim. The underlying cause is application functionality using predictable URL/form actions in a repeatable way. The nature of the attack is that CSRF exploits the trust that a web site has for a user. By contrast, cross-site scripting (XSS) [9] exploits the trust that a user has for a web site. Like XSS, CSRF attacks are not necessarily cross-site, but they can be. Cross-site request forgery is also known as CSRF, XSRF, one-click attack, session riding, confused deputy, and sea surf.


CSRF attacks are effective in a number of situations, including:

  • The victim has an active session on the target site.
  • The victim is authenticated via HTTP auth on the target site.
  • The victim is on the same local network as the target site.


CSRF has primarily been used to perform an action against a target site using the victim's privileges, but recent techniques have been discovered [5] to disclose information by gaining access to the response. The risk of information disclosure is dramatically increased when the target site is vulnerable to XSS, because XSS can be used as a platform for CSRF, allowing the attack to operate within the bounds of the same-origin policy.



In order to forge a HTTP request, an attacker typically profiles the target site first, either by reviewing the HTML source or by inspecting the HTTP traffic. This helps the attacker determine the format of a legitimate request; the forged request is meant to mimic a legitimate request as closely as possible.

Consider a web site that allows users to configure their web-based email account to forward all incoming email to an alternative address:

<form action="/account/edit" method="post">
<p>Email: <input type="text" name="email" /></p>
<p><input type="submit" /></p>


An attacker can deduce from viewing this HTML source or by using this form that a legitimate request will have a format similar to the following:

POST /account/edit HTTP/1.1
Host: example.org
Content-Type: application/x-www-form-urlencoded
Content-Length: 19
Cookie: PHPSESSID=1234




If an attacker could forge such a request from another user, it's possible that the attacker could begin receiving all of the victim's email. A popular technique is to use JavaScript to submit a form that consists of hidden fields. If the target of the form is a hidden IFrame, the response is hidden from view. The following example demonstrates this:


<iframe style="width: 0px; height: 0px; visibility: hidden" name="hidden"></iframe>
<form name="csrf" action="http://example.org/account/edit" method="post" target="hidden">
<input type="hidden" name="email" value="attacker@email.tld" />

This malicious payload can be hosted on another web site the victim visits, or on the same site. Popular approaches for deploying malicious payloads include via banner ads, via cross-site scripting flaws, or via other means.

If the intent is to forge a GET request, a popular technique is to use an embedded resource such as an image as the malicious payload:

<img height="0" width="0" src="http://example.org/account/edit?email=attacker@email.tld" />

The key to understanding CSRF is to realize that only the request matters, and there are a variety of techniques that can be used to forge requests.


Public Incidents

Digg Exploit, 06 Jun 2006, Anonymous,



Google Mail Exploit, 01 Jan 2007, Alex Bailey,



Amazon Exploit, 15 Mar 2007, Chris Shiflett,





"Cross Site Reference Forgery: An introduction to a common web application weakness"



"Cross-Site Request Forgeries", Peter Watkins

[2] http://tux.org/~peterw/csrf.txt


"Security Corner: Cross-Site Request Forgeries", Chris Shiflett

[3] http://shiflett.org/articles/cross-site-request-forgeries


"The Cross-Site Request Forgery FAQ", Robert Auger

[4] http://www.cgisecurity.com/articles/csrf-faq.shtml


"JavaScript Hijacking", Brian Chess, et al.

[5] http://fortifysoftware.com/servlet/downloads/public/JavaScript_Hijacking.pdf


"Cross-Site Request Forgery: Looking at Devices", Daniel Weber

[6] http://labs.calyptix.com/csrf-tracking.php


"Cross-Site Request Forgery (CSRF)", Web Hacking Incidents Database

[7] http://webappsec.org/projects/whid/byclass_class_attack_method_value_cross_site_request_forgery_(csrf).shtml


"Cross-Site Request Forgeries: Exploitation and Prevention", William Zeller and Edward Felten

[8] http://freedom-to-tinker.com/sites/default/files/csrf.pdf


Cross-Site Scripting Section

[9] http://projects.webappsec.org/Cross-Site-Scripting


"Cross-Site Request Forgery", Wikipedia

[10] http://en.wikipedia.org/wiki/Cross-site_request_forgery


Cross-Site Request Forgery (CSRF)

[11] http://cwe.mitre.org/data/definitions/352.html

Comments (0)

You don't have permission to comment on this page.