Cross-site request forgery

Revision as of 03:24, 16 August 2020 by David (talk | contribs)
\( \newcommand{\P}[]{\unicode{xB6}} \newcommand{\AA}[]{\unicode{x212B}} \newcommand{\empty}[]{\emptyset} \newcommand{\O}[]{\emptyset} \newcommand{\Alpha}[]{Α} \newcommand{\Beta}[]{Β} \newcommand{\Epsilon}[]{Ε} \newcommand{\Iota}[]{Ι} \newcommand{\Kappa}[]{Κ} \newcommand{\Rho}[]{Ρ} \newcommand{\Tau}[]{Τ} \newcommand{\Zeta}[]{Ζ} \newcommand{\Mu}[]{\unicode{x039C}} \newcommand{\Chi}[]{Χ} \newcommand{\Eta}[]{\unicode{x0397}} \newcommand{\Nu}[]{\unicode{x039D}} \newcommand{\Omicron}[]{\unicode{x039F}} \DeclareMathOperator{\sgn}{sgn} \def\oiint{\mathop{\vcenter{\mathchoice{\huge\unicode{x222F}\,}{\unicode{x222F}}{\unicode{x222F}}{\unicode{x222F}}}\,}\nolimits} \def\oiiint{\mathop{\vcenter{\mathchoice{\huge\unicode{x2230}\,}{\unicode{x2230}}{\unicode{x2230}}{\unicode{x2230}}}\,}\nolimits} \)

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.