Why is it common to put CSRF prevention tokens in cookies

Question

I m trying to understand the whole issue with CSRF and appropriate ways to prevent it   Resources I ve read  understand  and agree with  OWASP CSRF Prevention CHeat Sheet  Questions about CSRF    As I understand it  the vulnerability around CSRF is introduced by the assumption that  from the webserver s point of view  a valid session cookie in an incoming HTTP request reflects the wishes of an authenticated user  But all cookies for the origin domain are magically attached to the request by the browser  so really all the server can infer from the presence of a valid session cookie in a request is that the request comes from a browser which has an authenticated session  it cannot further assume anything about the code running in that browser  or whether it really reflects user wishes  The way to prevent this is to include additional authentication information  the  CSRF token   in the request  carried by some means other than the browser s automatic cookie handling  Loosely speaking  then  the session cookie authenticates the user browser and the CSRF token authenticates the code running in the browser   So in a nutshell  if you re using a session cookie to authenticate users of your web application  you should also add a CSRF token to each response  and require a matching CSRF token in each  mutating  request  The CSRF token then makes a roundtrip from server to browser back to server  proving to the server that the page making the request is approved by  generated by  even  that server   On to my question  which is about the specific transport method used for that CSRF token on that roundtrip   It seems common  e g  in AngularJS  Django  Rails  to send the CSRF token from server to client as a cookie  i e  in a Set-Cookie header   and then have Javascript in the client scrape it out of the cookie and attach it as a separate XSRF-TOKEN header to send back to the server    An alternate method is the one recommended by e g  Express  where the CSRF token generated by the server is included in the response body via server-side template expansion  attached directly to the code markup that will supply it back to the server  e g  as a hidden form input  That example is a more web 1 0-ish way of doing things  but would generalize fine to a more JS-heavy client    Why is it so common to use Set-Cookie as the downstream transport for the CSRF token   why is this a good idea  I imagine the authors of all these frameworks considered their options carefully and didn t get this wrong  But at first glance  using cookies to work around what s essentially a design limitation on cookies seems daft  In fact  if you used cookies as the roundtrip transport  Set-Cookie  header downstream for the server to tell the browser the CSRF token  and Cookie  header upstream for the browser to return it to the server  you would reintroduce the vulnerability you are trying to fix   I realize that the frameworks above don t use cookies for the whole roundtrip for the CSRF token  they use Set-Cookie downstream  then something else  e g  a X-CSRF-Token header  upstream  and this does close off the vulnerability  But even using Set-Cookie as the downstream transport is potentially misleading and dangerous  the browser will now attach the CSRF token to every request including genuine malicious XSRF requests  at best that makes the request bigger than it needs to be and at worst some well-meaning but misguided piece of server code might actually try to use it  which would be really bad  And further  since the actual intended recipient of the CSRF token is client-side Javascript  that means this cookie can t be protected with http-only  So sending the CSRF token downstream in a Set-Cookie header seems pretty suboptimal to me

User · Answer

Using a cookie to provide the CSRF token to the client does not allow a successful attack because the attacker cannot read the value of the cookie and therefore cannot put it where the server-side CSRF validation requires it to be.

The attacker will be able to cause a request to the server with both the auth token cookie and the CSRF cookie in the request headers. But the server is not looking for the CSRF token as a cookie in the request headers, it's looking in the payload of the request. And even if the attacker knows where to put the CSRF token in the payload, they would have to read its value to put it there. But the browser's cross-origin policy prevents reading any cookie value from the target website.

The same logic does not apply to the auth token cookie, because the server is expects it in the request headers and the attacker does not have to do anything special to put it there.

User · Answer

Besides the session cookie  which is kind of standard   I don t want to use extra cookies    I found a solution which works for me when building a Single Page Web Application  SPA   with many AJAX requests  Note  I am using server side Java and client side JQuery  but no magic things so I think this principle can be implemented in all popular programming languages   My solution without extra cookies is simple   Client Side  Store the CSRF token which is returned by the server after a succesful login in a global variable  if you want to use web storage instead of a global thats fine of course   Instruct JQuery to supply a X-CSRF-TOKEN header in each AJAX call   The main  index  page contains this JavaScript snippet      Intialize global variable CSRF TOKEN to empty sting      This variable is set after a succesful login window CSRF TOKEN           the supplied callback to  ajaxSend   is called before an Ajax request is sent    document   ajaxSend  function  event  jqXHR         jqXHR setRequestHeader  X-CSRF-TOKEN   window CSRF TOKEN          Server Side  On successul login  create a random  and long enough  CSRF token  store this in the server side session and return it to the client  Filter certain  sensitive  incoming requests by comparing the X-CSRF-TOKEN header value to the value stored in the session  these should match    Sensitive AJAX calls  POST form-data and GET JSON-data   and the server side filter catching them  are under a  dataservice   path  Login requests must not hit the filter  so these are on another path  Requests for HTML  CSS  JS and image resources are also not on the  dataservice   path  thus not filtered  These contain nothing secret and can do no harm  so this is fine    WebFilter urlPatterns      dataservice          String sessionCSRFToken   req getSession   getAttribute  CSRFToken      null    String  req getSession   getAttribute  CSRFToken     null  if  sessionCSRFToken    null    req getHeader  X-CSRF-TOKEN      null     req getHeader  X-CSRF-TOKEN   equals sessionCSRFToken         resp sendError 401     else     chain doFilter request  response

User · Answer

My best guess as to the answer  Consider these 3 options for how to get the CSRF token down from the server to the browser    In the request body  not an HTTP header   In a custom HTTP header  not Set-Cookie  As a cookie  in a Set-Cookie header    I think the 1st one  request body  while demonstrated by the Express tutorial I linked in the question   is not as portable to a wide variety of situations  not everyone is generating every HTTP response dynamically  where you end up needing to put the token in the generated response might vary widely  in a hidden form input  in a fragment of JS code or a variable accessible by other JS code  maybe even in a URL though that seems generally a bad place to put CSRF tokens   So while workable with some customization   1 is a hard place to do a one-size-fits-all approach   The second one  custom header  is attractive but doesn t actually work  because while JS can get the headers for an XHR it invoked  it can t get the headers for the page it loaded from   That leaves the third one  a cookie carried by a Set-Cookie header  as an approach that is easy to use in all situations  anyone s server will be able to set per-request cookie headers  and it doesn t matter what kind of data is in the request body   So despite its downsides  it was the easiest method for frameworks to implement widely

User · Answer

A good reason  which you have sort of touched on  is that once the CSRF cookie has been received  it is then available for use throughout the application in client script for use in both regular forms and AJAX POSTs  This will make sense in a JavaScript heavy application such as one employed by AngularJS  using AngularJS doesn t require that the application will be a single page app  so it would be useful where state needs to flow between different page requests where the CSRF value cannot normally persist in the browser    Consider the following scenarios and processes in a typical application for some pros and cons of each approach you describe  These are based on the Synchronizer Token Pattern   Request Body Approach   User successfully logs in  Server issues auth cookie  User clicks to navigate to a form  If not yet generated for this session  server generates CSRF token  stores it against the user session and outputs it to a hidden field  User submits form  Server checks hidden field matches session stored token    Advantages    Simple to implement  Works with AJAX  Works with forms  Cookie can actually be HTTP Only    Disadvantages    All forms must output the hidden field in HTML  Any AJAX POSTs must also include the value  The page must know in advance that it requires the CSRF token so it can include it in the page content so all pages must contain the token value somewhere  which could make it time consuming to implement for a large site    Custom HTTP Header  downstream    User successfully logs in  Server issues auth cookie  User clicks to navigate to a form   Page loads in browser  then an AJAX request is made to retrieve the CSRF token   Server generates CSRF token  if not already generated for session   stores it against the user session and outputs it to a header   User submits form  token is sent via hidden field    Server checks hidden field matches session stored token    Advantages    Works with AJAX  Cookie can be HTTP Only    Disadvantages    Doesn t work without an AJAX request to get the header value  All forms must have the value added to its HTML dynamically  Any AJAX POSTs must also include the value  The page must make an AJAX request first to get the CSRF token  so it will mean an extra round trip each time  Might as well have simply output the token to the page which would save the extra request    Custom HTTP Header  upstream    User successfully logs in  Server issues auth cookie  User clicks to navigate to a form   If not yet generated for this session  server generates CSRF token  stores it against the user session and outputs it in the page content somewhere  User submits form via AJAX  token is sent via header    Server checks custom header matches session stored token    Advantages    Works with AJAX  Cookie can be HTTP Only    Disadvantages    Doesn t work with forms  All AJAX POSTs must include the header    Custom HTTP Header  upstream  amp  downstream    User successfully logs in  Server issues auth cookie  User clicks to navigate to a form   Page loads in browser  then an AJAX request is made to retrieve the CSRF token   Server generates CSRF token  if not already generated for session   stores it against the user session and outputs it to a header   User submits form via AJAX  token is sent via header     Server checks custom header matches session stored token    Advantages    Works with AJAX  Cookie can be HTTP Only    Disadvantages    Doesn t work with forms  All AJAX POSTs must also include the value  The page must make an AJAX request first to get the CRSF token  so it will mean an extra round trip each time    Set-Cookie   User successfully logs in  Server issues auth cookie  User clicks to navigate to a form  Server generates CSRF token  stores it against the user session and outputs it to a cookie  User submits form via AJAX or via HTML form  Server checks custom header  or hidden form field  matches session stored token  Cookie is available in browser for use in additional AJAX and form requests without additional requests to server to retrieve the CSRF token    Advantages    Simple to implement  Works with AJAX  Works with forms  Doesn t necessarily require an AJAX request to get the cookie value  Any HTTP request can retrieve it and it can be appended to all forms AJAX requests via JavaScript  Once the CSRF token has been retrieved  as it is stored in a cookie the value can be reused without additional requests    Disadvantages    All forms must have the value added to its HTML dynamically  Any AJAX POSTs must also include the value  The cookie will be submitted for every request  i e  all GETs for images  CSS  JS  etc  that are not involved in the CSRF process  increasing request size  Cookie cannot be HTTP Only    So the cookie approach is fairly dynamic offering an easy way to retrieve the cookie value  any HTTP request  and to use it  JS can add the value to any form automatically and it can be employed in AJAX requests either as a header or as a form value   Once the CSRF token has been received for the session  there is no need to regenerate it as an attacker employing a CSRF exploit has no method of retrieving this token  If a malicious user tries to read the user s CSRF token in any of the above methods then this will be prevented by the Same Origin Policy  If a malicious user tries to retrieve the CSRF token server side  e g  via curl  then this token will not be associated to the same user account as the victim s auth session cookie will be missing from the request  it would be the attacker s - therefore it won t be associated server side with the victim s session    As well as the Synchronizer Token Pattern there is also the Double Submit Cookie CSRF prevention method  which of course uses cookies to store a type of CSRF token  This is easier to implement as it does not require any server side state for the CSRF token  The CSRF token in fact could be the standard authentication cookie when using this method  and this value is submitted via cookies as usual with the request  but the value is also repeated in either a hidden field or header  of which an attacker cannot replicate as they cannot read the value in the first place  It would be recommended to choose another cookie however  other than the authentication cookie so that the authentication cookie can be secured by being marked HttpOnly  So this is another common reason why you d find CSRF prevention using a cookie based method

[security] Why is it common to put CSRF prevention tokens in cookies?

Examples related to security

Examples related to cookies

Examples related to web

Examples related to csrf

Examples related to owasp