- Forward


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


Prof. David Bernstein
James Madison University

Computer Science Department
bernstdh@jmu.edu

Print

Motivation
Back Forward
  • 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
Back Forward
  • 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
Back Forward
  • 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
Back Forward
  • 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
Back Forward
  • 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
Back Forward
  • 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
Back Forward
  • 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
Back Forward
  • Code Reviews:
    • Look for command-like requests
  • Testing:
    • Unfortunately, there's not much that can be done
There's Always More to Learn
Back -