Double Submit Cookies Pattern

CSRF PROTECTION: DOUBLE SUBMIT COOKIES PATTERN

Cross-Site Request Forgery (CSRF) is an attack that enables or forces an user access unwanted websites of web application by accessing unwanted actions, which there users may be authenticated. CSRF attack takes place specially on target state-changing requests, such as transferring funds, changing their email address etc. Here the attacker may force or trick the user into executing actions of the attacker's choosing of web application.

PREVENTION OF CSRF

To prevent these kind of attacks, there are most notably two specification of famous techniques, such as
  • Synchronizer Token Pattern
  • Double Submit Cookies Pattern
But in this post we are only going to look about Double Submit Cookies Pattern and the way of prevention. 

DOUBLE SUBMIT COOKIES PATTERN

As regards with synchronizer token pattern, it stores the generated CSRF token value in the server-side and uses that to validate and check if the CSRF token is not changed.

This causes to cost memory and result in imbalances in terms of load distribution across web servers. To avoid these, this is where Double Submit Cookies come to play.
 A double submit cookie is defined as sending a random value in both a cookie and as a request parameter, with the server verifying if the cookie value and request value match [1].




How prevention of Synchronizer Token Pattern (STP) Works ?

To make use of the demonstration, you can download it from the following link : https://github.com/suga95/CSRF_Double_Submit_Cookies_Pattern.git

Prerequisite needs : XAMPP Server

  • Place the downloaded Software Under installed folder, which is xampp -> htdocs and paste the downloaded app.
  • Run the XAMPP's Apache Server.

  • Can run the application by calling the URL: localhost://CSRF Double Submit Cookies Pattern/userLogin.php  -> This can be called in any respective browser.


  • Can login to the system by providing SUGA and 1234 as Username and Password Respectively.
  • After loging in, the system will display the UI like below screenshot

  • By selecting the inspect element option, we can see the CSRF cookie value set in the hidden field of the form, which the value is posted using the the "POST" method.

  • Like shown on above screenshot, we haven't modified anything there in the CSRF token field, the page redirects us to the success page.
  • So if the CSRF field is modified by any chance, the system will show the UI like below page after submission.
  • The screen shot shown below is when the CSRF token is changed.

Lets look at how we get these kind of protection

  1. First the user is asked to login to the system by providing his/hers user credentials.
  2. Upon successful login, the system will redirect to the user registration page, where the user should provide relevant details in the form.
  3. Upon logging in, the system will create a session and set in the browser using set cookie. As well as CSRF token is generated and set as cookie in browser too.
  4. CSRF token is generated using Cryptography secure code, which the token is not saved in the server side.
  5. During the loading of the above page, generated set CSRF token cookie value and session id is also formed in the hidden fields of registration form when redirected.
  6. In that, the server will read the session cookie based on the session id and posts the csrf token value for further processing.
  7. When posting, the posted token and the value stored in the browser as cookie, that is Stored  as CSRF token value with session id is validated, which both the posted and set cookie CSRF value should be equal, if so it will show the success message else it will show the CSRF attack forgery page.

Full structure of the System

userLogin.php




UserRegister.php







checkCSRFToken.php


  • REFERENCE
[1] https://www.owasp.org/index.php/Cross-Site_Request_Forgery_(CSRF)_Prevention_Cheat_Sheet

Comments

Popular posts from this blog

OAuth 2.0 Using Social Login :Facebook

CSRF PROTECTION: SYNCHRONIZER TOKEN PATTERN