• 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!

View
 

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.

 

Example

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>
</form>

 

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

 

chris%40example.tld

 

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" />
<script>document.csrf.submit();</script>
 

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,

http://4diggers.blogspot.com/

 

Google Mail Exploit, 01 Jan 2007, Alex Bailey,

http://cyber-knowledge.net/blog/2007/01/01/gmail-vulnerable-to-contact-list-hijacking/

 

Amazon Exploit, 15 Mar 2007, Chris Shiflett,

http://shiflett.org/blog/2007/mar/my-amazon-anniversary

 

 

References

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

[1]http://www.isecpartners.com/documents/XSRF_Paper.pdf

 

"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.