Cross-site request forgery: Difference between revisions

From David's Wiki
(Created page with "Cross-site request forgery, also known as CSRF or XSRF, is a attack in which an alternate website sends fake requests to a real website. The attack usually works like this: #...")
 
No edit summary
Line 1: Line 1:
Cross-site request forgery, also known as CSRF or XSRF, is a attack in which an alternate website sends fake requests to a real website.
Cross-site request forgery, also known as CSRF or XSRF, is a attack in which an alternate website sends fake requests to a real website.


The attack usually works like this:
==Attack==
The attack is like this:
 
# A user is logged into <code>shopping.com</code>, an online store where he shops regularly.
# A user is logged into <code>shopping.com</code>, an online store where he shops regularly.
#* <code>shopping.com</code> leaves a session id in a cookie so the user doesn't need to login every visit.
#* <code>shopping.com</code> leaves a session id in a cookie so the user doesn't need to login every visit.
Line 9: Line 11:
#* Without CSRF protection, the order will go through.
#* Without CSRF protection, the order will go through.


==Defense==
To protect against CSRF, the website <code>shopping.com</code> should do the following:
To protect against CSRF, the website <code>shopping.com</code> should do the following:
# While the user is browsing <code>shopping.com</code>, it backend sets a CORS cookie using an HTTP header in a response.
# While the user is browsing <code>shopping.com</code>, it backend sets a CORS cookie using an HTTP header in a response.

Revision as of 03:24, 16 August 2020

Cross-site request forgery, also known as CSRF or XSRF, is a attack in which an alternate website sends fake requests to a real website.

Attack

The attack is like this:

  1. A user is logged into shopping.com, an online store where he shops regularly.
    • shopping.com leaves a session id in a cookie so the user doesn't need to login every visit.
  2. The user is sent a email linking to attacker-website.com. They visit this website.
  3. The JS code in attacker-website.com sends a POST request to shopping.com to order an item.
    • This request will carry the session id which is already authenticated.
    • Without CSRF protection, the order will go through.

Defense

To protect against CSRF, the website shopping.com should do the following:

  1. While the user is browsing shopping.com, it backend sets a CORS cookie using an HTTP header in a response.
    My-Xsrf-Cookie:UKL7smHAK4xENQj5pYbi
    • This cookie will be different for each session.
  2. When making requests to checkout, the front-end will add the XSRF token to the HTTP request.
    My-Xsrf-Header:UKL7smHAK4xENQj5pYbi
  3. Before processing the order, the backend will check the Xsrf header to make sure that it matches what was sent originally.

This works for the following reasons:

  1. When sending the XSRF token, the backend sends it in an HTTP header telling the browser to stores it as a cookie,
    • If other websites make a request (via fetch or XmlHTTPRequest) to get an XSRF token, the token will be sent in the HTTP header.
      By default, the browser will only let the other website see a few whitelisted HTTP headers due to same-origin policy so they will not see the XSRF token.
  2. Next the browser stores the cookie under shopping.com.
    • Due to same-origin policy, other websites cannot see the cookies for shopping.com.