WHAT IS CSRF ?
Cross-Site Request Forgery (CSRF) is an attack that forces an end user to execute unwanted actions on a web application in which they're currently authenticated. CSRF attacks specifically target state-changing requests, not theft of data, since the attacker has no way to see the response to the forged request.
Most CSRF prevention techniques work by embedding additional authentication data into requests that allows the web application to detect requests from unauthorized locations.
What is Double Submit Cookies Pattern ?
There are numerous ways you can specifically defend against CSRF. On of such defense technique is double submit cookies pattern. If storing the CSRF token in session is problematic, an alternative defense is use of a double submit cookie. 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.
When a user authenticates to a site, the site should generate a (cryptographically strong) pseudorandom value and set it as a cookie on the user's machine separate from the session id. The site does not have to save this value in any way, thus avoiding server side state. The site then requires that every transaction request include this random value as a hidden form value (or other request parameter). A cross origin attacker cannot read any data sent from the server or modify cookie values, per the same-origin policy. This means that while an attacker can force a victim to send any value he wants with a malicious CSRF request, the attacker will be unable to modify or read the value stored in the cookie. Since the cookie value and the request parameter or form value must be the same, the attacker will be unable to successfully force the submission of a request with the random CSRF value.
When the UI and the function service reside in different hosts, the Double Submit Cookie guard turns difficult to implement because the UI body and the Set-Cookie response header will be generated as part of different requests to different processes. The Set-Cookie response header would need to be induced by a request from the client javascript. In that case, making sure that both the UI and the service request came from a client serviced by the same UI origin appears as difficult as the original issue.
Here an example of the double submit cookies pattern that uses for Cross-Site Request Forgery (CSRF).
I have created a simple login page to enter username and password as follows.
It’s basically a simple form that the method is post and the action is login.php. Login button capture the values from the input fields and submit it to the action.
Please enter the username as "admin" and password as "123". Here I have hardcoded values for username and password, since this a simple demo application which I have develop to explain double submit cookies pattern.
Upon login, generate session identifier and set a cookie in the browser. At the same time, generate the CSRF token for the session and set a cookie in the browser. The CSRF token value is not stored in the server side.
When username and password is correct it will be directed to page index.php where you need to add few comments as follows.
When the form is loaded, a javascript which reads
the CSRF token cookie value in the browser will be run and a hidden field is added to the HTML
form modifying the DOM.
The following code snippet represents the hidden input field.
<input type="hidden" id="csrf_token" name="csrf_token" value="csrf" />
When the form is submitted to the
action, the CSRF token cookie will be submitted and also in the form body, the
CSRF token value will be submitted. By obtaining the CSRF token
received in the cookie and also in the message body, it will compare the two values
received and if they match, show success message as follows.
Otherwise an error message will be displayed as follows.
You can find the source code here.
