Double Submit Cookies Pattern

Cookies

Another solution for CSRF.This pattern is a more lightweight implementation of CSRF-protection. While relatively new and generally considered somewhat untested (it’s just as effective as the Synchronizer Token Pattern in my opinion; the arguments against it are weak at best), it achieves protection while avoiding the use of state. The implementation of this pattern, like the Synchronizer Token Pattern, produces design and security consequences:

• Cookies cannot be tagged as HTTPONLY.

• Potential XSS vulnerabilities in subdomains can introduce poisoned cookies in upper domains. 

Cookies that contain sensitive server metadata, such as session cookies, should be tagged as HTTPONLY. This prevents client-side scripts from reading values from the cookie, adding a layer of protection. Given that this pattern requires client-side scripts to read the token from the cookie and apply it to the HTTP header, we cannot tag the cookie as HTTPONLY, introducing a potential security concern.

Leveraging this pattern requires that all software in our suite of applications are fully XSS-resistant. If an application in a subdomain, below our application domain, is compromised within the context of an XSS attack, an attacker could potentially introduce a poisoned cookie to that site, which would be valid in our upper domain, and allow an attacker to circumnavigate our CSRF protection framework.

How it works?  

 

SAMPLE WEB APPLICATION

This web application demonstrates how double submit cookie patterns work. PHP and JavaScript were used in developing.Source code can be found here.

First, you have to log into the application providing the hardcoded username and password.

Login Page

Once the user submits the user credentials, the server will authenticate the user will be redirected to login.php where you can update the name. Also, the server will generate the Session ID and the CSRF token (The server does not save the token). Then the server sets the Session ID and the token into the cookie.

login.php

 After the user logs in, the below function will retrieve cookies and split them to get only the CSRF token. Then it will embed it to the hidden field in the form.

token pass as hidden field.

 The user can enter a name and update the form at the login.php page. When the form is submitted, Then the server validates session-id which is in the request header using the one that is stored in the server-side, and also it compares the CSRF token in the hidden field with the token in the request header.

success message.

 server side validation is done using the following code.

server.php

For deeper explanations I recommend  to read chapter 5 of Iron-Clad Java: Building Secure Applications book and/or the OWASP Cross-Site Request Forgery (CSRF) Prevention Cheat Sheet.