ABSTRACT

HTTP requests must contain a user-specific secret in order to prevent an attacker from making unauthorized requests.

EXPLANATION


A cross-site request forgery (CSRF) vulnerability occurs when:
1. A web application uses session cookies.

2. The application acts on an HTTP request without verifying that the request was made with the user's consent.



If the request does not contain a nonce that proves its provenance, the code that handles the request is vulnerable to a CSRF attack (unless it does not change the state of the application.) This means a web application that uses session cookies has to take special precautions in order to ensure that an attacker can't trick users into submitting bogus requests. Imagine a web application that allows administrators to create new accounts as follows:


var req = new XMLHttpRequest();
req.open("POST", "/new_user", true);
body = addToPost(body, new_username);
body = addToPost(body, new_passwd);
req.send(body);


An attacker might set up a malicious web site that contains the following code.


var req = new XMLHttpRequest();
req.open("POST", "http://www.example.com/new_user", true);
body = addToPost(body, "attacker");
body = addToPost(body, "haha");
req.send(body);


If an administrator for the vulnerable site visits a page containing this code while she has an active session, she will unwittingly create an account for the attacker. This is a CSRF attack. It is possible because the application does not have a way to determine the provenance of the request. Any request could be a legitimate action chosen by the user or a faked action set up by an attacker. The attacker does not get to see the web page that the bogus request generates, so the attack technique is only useful for requests that alter the state of the application.

Most web browsers send an HTTP header named referer along with each request. The referer header is supposed to contain the URL of the referring page, but attackers can forge it, so the referer header is not useful for determining the provenance of a request.

Applications that pass the session identifier on the URL rather than as a cookie do not have CSRF problems because there is no way for the attacker to access the session identifier and include it as part of the bogus request.

CSRF is entry number five on the 2007 OWASP Top 10 list.

REFERENCES

[1] OWASP 2007 OWASP Top 10

[2] Standards Mapping - OWASP Top 10 2007 - (OWASP 2007) A5 Cross Site Request Forgery (CSRF)

[3] Standards Mapping - OWASP Top 10 2010 - (OWASP 2010) A5 Cross-Site Request Forgery (CSRF)

[4] Standards Mapping - Security Technical Implementation Guide Version 3 - (STIG 3) APP3585 CAT II

[5] Standards Mapping - Web Application Security Consortium 24 + 2 - (WASC 24 + 2) Cross-Site Request Forgery

[6] Standards Mapping - Common Weakness Enumeration - (CWE) CWE ID 352

[7] A. Klein Divide and Conquer: HTTP Response Splitting, Web Cache Poisoning Attacks, and Related Topics

[8] Standards Mapping - SANS Top 25 2009 - (SANS 2009) Insecure Interaction - CWE ID 352

[9] Standards Mapping - SANS Top 25 2010 - (SANS 2010) Insecure Interaction - CWE ID 352

[10] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 - (PCI 1.2) Requirement 6.5.5

[11] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 - (PCI 2.0) Requirement 6.5.9