Cross-Site Request Forgery (XSRF)

Cross-Site Request Forgery (XSRF)
Vulnerabilities, Attacks, and Mitigations

Prof. David Bernstein
James Madison University

Computer Science Department

bernstdh@jmu.edu

Motivation

The Nature of the Vulnerability:
- Situations in which a server can't determine if a request was initiated by the user
The Nature of the Attack:
- The attacker creates a document that makes a request that appears to be initiated by the user
- The user loads the document
The Trust Issue:
- The server has inappropriate trust in the client

The Simplest Instance

The Vulnerability:
- The service provider responds to GET requests with commands and parameters in the query string (e.g., www.cs.jmu.edu/process.php?command=drop&parameter=CS531)
The Attack:
- The attacker tricks the user or user-agent into making such a GET request
Tricking the User/User-Agent:
- Encourage the user to load a document that contains a malicious link and click on that link
- Encourage the user to load a document that contains an element that results in a GET request (e.g., an IMG element that contains the malicious URL in the src attribute)

Another Instance

The Vulnerability:
- The service provider responds to POST requests containing commands and parameters in the FORM data
The Attack:
- The attacker tricks the user or user-agent into making such a POST request
Tricking the User/User-Agent:
- Encourage the user to load a document that contains a malicious FORM and click on the SUBMIT button
- Encourage the user to load a document that contains a malicious FORM and a client-side script that performs the submission

A Common Misconception and Clarification

The Misconception:
- XSRF vulnerabilities are not present in session-oriented systems
The Clarification:
- Whether session information is on the client (e.g., in cookies) or the server, the user might visit a malicious page in between logging-in and logging-out
- Attacks of this kind are sometimes called session riding

An Important Issue

A Natural Question to Ask:
- Why doesn't this vulnerability arise in other command-oriented protocols (e.g., FTP)?
The Answer:
- FTP uses a single (actually two) TCP connection. This makes it much more difficult for an attacker to insert a command in between the user logging-in and logging-out

Mitigation During Design

Include Session Timeouts:
- This at least reduces the window of vulnerability
Use a Landing Page:
- If possible, have all requests originate from a landing page and then check the HTTP referer header before processing a request (Note: referer is the official spelling, not referrer)

Mitigation During Construction

Use a Number-Used-Once/Nonce (e.g., CSRFGuard):
- Initially: Have the server generate a (cryptographically strong) random number when the user signs in, store it in the session information, and include it as a hidden FORM field in all responses (so that it is automatically sent back to the server in the request)
- Subsequently: Only respond to requests that include the correct nonce
- Notes: (a) This is not a defense against a person-in-the-middle attack or a cross-site scripting attack. (b) This is sometimes called a synchronizer token.
Use a Double-Entry Identifier:
- Initially: Have the server include a one-way hash of the session ID in both a cookie and in a hidden FORM field
- Subsequently: The user-agent includes the cookie and the FORM data in all requests and the server checks to ensure that they are the same (without having to store any state information)
- Notes: (a) This is not a defense against a person-in-the-middle attack or a cross-site scripting attack. (b) This is sometimes called a double-cookie.
Use Reauthentication:
- Authenticate every request (or, at least, those requests that can do the most harm)

Mitigation During Validation/Verification