This site is the archived OWASP Foundation Wiki and is no longer accepting Account Requests.
To view the new OWASP Foundation website, please visit https://owasp.org

Difference between revisions of "Cross-Site Request Forgery (CSRF)"

From OWASP
Jump to: navigation, search
(References)
Line 39: Line 39:
  
 
[http://www.darkreading.com/document.asp?doc_id=107651&WT.svl=news1_2 CSRF Vulnerability: A 'Sleeping Giant']
 
[http://www.darkreading.com/document.asp?doc_id=107651&WT.svl=news1_2 CSRF Vulnerability: A 'Sleeping Giant']
 +
 +
Martin Johns and Justus Winter wrote an interesting paper and presentation for the 4th OWASP AppSec Conference which described potential techniques that browsers could adopt to automatically provide CSRF protection [http://www.owasp.org/index.php/Image:OWASPAppSecEU2006_RequestRodeo.ppt RequestRodeo: Client Side Protection against Session Riding], ([http://www.owasp.org/index.php/Image:RequestRodeo-MartinJohns.pdf paper])
  
 
[[Category:Attack]]
 
[[Category:Attack]]

Revision as of 20:23, 28 October 2006

This is an Attack. To view all attacks, please see the Attack Category page.


Description

Cross-Site Request Forgery (CSRF) is an attack that tricks the victim into loading a page that contains a malicious request. It is malicious in the sense that it inherits the identity and privileges of the victim to perform an undesired function on the victim's behalf, like change the victim's e-mail address, home address, or password, or purchase something. CSRF attacks target functions that cause a state change on the server.

For most sites, such a request will normally automatically include any credentials associated with the site, such as the user's session cookie, basic auth credentials, IP address, Windows domain credentials, etc. Therefore, if the user has authenticated to the site, the site will have no way to distinguish this from a legitimate user request.

In this way, the attacker can make the victim perform actions that they didn't intend to, such as logout, purchase item, change account information, or any other function provided by the vulnerable website.

If it is possible to store the CSRF attack on the vulnerable site itself, the severity of the attack are increased. The likelihood is increased because the victim is more likely to view the page containing the attack than some random page on the Internet. The likelihood of a successful attack is also increased because the victim is sure to be authenticated to the site already.

Synonyms: CSRF attacks are also known by a number of other names, including XSRF, Session Riding, Cross-Site Reference Forgery, and Hostile Linking. Microsoft refers to this type of attack as a One-Click attack in their threat modeling process and many places in their online documentation.

Examples

The following example has an attack embedded in the img request below:

<img src="http://www.mybank.com/transferFunds.do?acctId=123456" />

When the victim's browser attempts to render this page, it will issue a request to www.mybank.com to the transferFunds.do page with the specified parameters. The browser will think the link is to get an image, even though it actually is a funds transfer function.

Related Threats

Related Attacks

XSS

Related Vulnerabilities

Related Countermeasures

  • TBD: Add a per-session nonce to URL and all forms
  • TBD: Add a per-request nonce to URL and all forms
  • TBD: Add a hash(session id, function name, server-side secret) to URL and all forms
  • TBD: .NET - add session identifier to ViewState with MAC

References

CSRF Vulnerability: A 'Sleeping Giant'

Martin Johns and Justus Winter wrote an interesting paper and presentation for the 4th OWASP AppSec Conference which described potential techniques that browsers could adopt to automatically provide CSRF protection RequestRodeo: Client Side Protection against Session Riding, (paper)