CSRF in WebApps | Double Submit Cookie Patterns

In this blogpost we will look at how we can implement Cross-Site Request Forgery protection via Double Submit Cookie Patterns.

First things first

This blog is primarily focused on security. Hence, firstly, I will integrate the OWASP dependency check plugin to my project. With Maven, we blindly add many dependencies/ 3rd party libraries without checking how secure those dependencies are. This in turn can make the whole application that we are developing a vulnerable application. So it is important that we have OWASP dependency check plugin in place to check for vulnerable dependencies.

Maven Configurations

Here I have added it with a configuration – apart from generating a report I have instructed OWASP dependency check to fail the Build if a certain vulnerability is greater than or equal to 8. This is because I may not pay attention to the report and just ignore it during the build and in that case if there are any critical vulnerabilities then the build must fail as I must take note of it and remove that version of the vulnerable plugin.

<plugin>
    <groupId>org.owasp</groupId>
    <artifactId>dependency-check-maven</artifactId>
    <version>3.1.2</version>
    <configuration>
        <failBuildOnCVSS>8</failBuildOnCVSS>
    </configuration>
    <executions>
        <execution>
            <goals>
                <goal>check</goal>
            </goals>
        </execution>
    </executions>
</plugin>

Now that all the good practices are out of the way, lets get in to the actual application.

Double Submit Cookie Patterns

I already covered what CSRF is, how we can mitigate it using one of the methods provided by OWASP. Now I will be talking you through another approach of how we can protect web applications from CSRF. For this purpose, I have used my previous code with a few new changes. I will explain the changes shortly. Now for the burning question – what is double submit cookie patterns? Let us address this question with the help of our previous example (in previous blog). In Synchronizer Token Patterns we set only one cookie in the client side, that is the session cookie. But here we are setting 2 cookies – session cookie and csrf cookie. Hence, I have removed the CSRFTokenObtainer.java class from previous example.

In this example, we set the csrf token value as a hidden value in the form. Here we use a scripting language to access the client side cookie and set its value as a hidden field in the form.

Above is a screenshot of the 2 cookies set on the client side. DBLSesID, helps us identify the user across the web application. The value of CSRFDubSub is appended to the form as a hidden field.

OWASP’s recommendation

In the above example we validate the request to transfer funds contain a CSRF token as well as a session token. Another thing that is prudent in this situation is that we generate cryptographically secure random numbers. OWASP recommends this as follows.

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

I really wanted bring this to your attention because I have used the java class SecureRandom exactly for this reason. I have used this in the last example too. If this was not in place, then hackers can use cryptoanalysis methods to derive or generate these values themselves. Because other random classes are more deterministic.

Conclusion

Double Submit cookie patterns are another way how we can prevent CSRF attacks. I did not add screenshots for each step as in earlier example as this is the same flow. The differences have been stated. In the earlier case(synchronizer token patterns) we had a thick server and a thin client. Here we have a thin server and a thick client. Depending on which is suitable to our requirement of our application, we can select one of the 2 approaches.