DOUBLE SUBMIT COOKIES PATTERN

Implementing Mitigation Methods For CSRF Attack — DOUBLE SUBMIT COOKIE PATTERN

What is a double submit cookie?

Double submitting cookies 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 are equal.

How does this work?

When a user authenticates to a site, the site should generate a session identifier and set a cookie in the browser. At the same time, it generates the cryptographically strong random value or the CSRF token for the session and set it as a cookie on the user’s machine separate from the session id. The server does not have to save this value in any way, that’s why this pattern is sometimes also called Stateless CSRF Defense.

The site then requires that every request include this random value as a hidden form value (or another request parameter). A cross origin attacker cannot read any data sent from the server or modify cookie values, per the same-origin policy.

In the case of this mitigation technique the job of the client is very simple; just retrieve the CSRF cookie from the response and add it into a special header to all the requests.

Double-submit cookies are also vulnerable to a Man-In-The-Middle attacker that can intercept and change everything apart from HTTPS traffic. Even if the target site, example.com does not listen over plain HTTP (i.e. port 443 only open for TLS), the attacker could redirect any plain HTTP request with HTTP 3xx (e.g. to http://example.com), and then intercept that request, send back a response with the poisoned CSRF cookie set for example.com. The server will take that value, as again it has no way to determine it is not a cookie with the secure flag. This is again due to the lax same-origin policy for cookies.

Implementation :

In the below example instead of using the real database, I have hard-codded the username and password for the demonstration purpose.

Username:test@gmail.com
Password:123456

STEP 1 - index.html 👇

The user credentials are submitting using the POST method. To create a unique session ID and a CSRF Token a successful login should be there and as well as make sure that the server only stores the session-ID whereas it not going to store the CSRF Token.

After that, a response will occur with the corresponding CSRF Token with the response body.

If the user has provided the correct credentials add_user.html page will be prompted.

STEP 2 — login.php 👇

For each login a new session is made for the user and as well as a new PHP ID is generated for each login after invalidating the already existing session.

Actually, the CSRF token is a randomly generated token and to create this token, hashing algorithms should use and for this implementation, SHA256 has been used.

To create and store a cookie that contains the generated CSRF Token the setcookie() function has been used. Normally this contains five key-value pairs:

• Cookie Name
• Cookie Value
• Domain
• Path
• Expiry Date

After referring to the below image you can figure out that Cookie name is set to the “CSRF_TOKEN”.

Cookie Value is the generated CSRF Token value and the cookie expiration time is set to 86400 seconds which equates to one day and the path is root.

The CSRF Token for the session is retrieved from the CSRF_TOKEN and this happens when the user fills

and submit the form and the details are submitted to validate_token.php page

STEP 3 — add_user.html 👇

the statement, the CSRF token value is retrieved from the cookie stored in the user’s browser by calling getCSRFToken() method, passing the Cookie Name as a parameter, and after retrieving the CSRF token value, a new hidden input field is added to the form, and this input field contains the retrieved CSRF token which is to be passed to the server-side in the attempt in enabling the server to recognize whether the request is legitimate or not.

getCSRFToken() method works by accessing cookies of the current domain using document.cookie, decoding the retrieved value which contains all the cookies for the current domain, and splitting by the delimiter “;” to separate key-value pair cookies of the retrieved cookie set. Then, in a loop, each key-value pair is accessed and the white spaces, in the beginning, are removed, if found, and afterward, if it is possible to find the correct key-value pair which contains the string: “CSRF_TOKEN=” and the CSRF Token value, the CSRF Token value which is the value in the key-value pair is extracted and returned.

When the form details are submitted to validate_token.php on the Insert button click, the CSRF Token values will be compared and validated, and a message will be returned based on the outcome of the comparison.

STEP 4 — validate_token.php 👇

validate_token.php checks whether the request is POST and checks to see whether the PHPSESSID which is the PHP Session Id has been set. Additionally, it checks to see whether a value has been set as the ‘csrf_token’ in the request body and also in the CSRF_TOKEN cookie, and if it has been set, the CSRF Token value stored in the received CSRF Token Cookie is compared with the value sent in the POST request body to see whether the values are equal and the request is legitimate. Either a successful message as in the picture included below, or an error message will be displayed in the client-side based on the equality comparison outcome.

This way we do not need to store a whole set of CSRF Tokens mapped against each user’s every session in the database

NOW WE ARE DONE WITH IMPLEMENTING DOUBLE SUBMIT COOKIES PATTERN WHICH IS USED TO MITIGATE FROM CSRF.

YOU CAN GET MY SOURCE CODE BY GITHUB ACCOUNT.