CSRF Protection Episode 2. Double Submit Cookie Pattern
In my previous blog post, I had discussed about the Synchronizer Token Pattern (STP) and how it is implemented. This post is about the second most common way to use the Anti-CSRF Token, the Double Submit Cookie pattern.
Introduction
Double Submit Cookie Pattern (DSCP) comes into play when you have limited server resources and you cannot afford to keep track of each and every token for each session (and a bigger hassle when one user can have multiple sessions).
Flow of Events of Double Submit Cookie Pattern
The main difference here compared to the Synchronizer Token Pattern is that the generated Token is not stored in the server-side and server has no record of the token. All the server does is generate the token and send to the client-side. From there onward, the token will be only available in the client-side, which requires that you should not set this token cookie as HttpOnly (as JavaScript on the browser needs to read this cookie).
When a user logs into the secure website, his/her credentials are verified and the user is authenticated. The server then creates a session id for the user and sets it as a cookie in the response. Similarly a token cookie is also generated and set as a cookie. The server needs to store the session id for the user (to keep track of the user), but does not store the token for that session.
As soon as the authentication response gets sent to the client browser, the client-side script (JavaScript in this case) reads the token cookie, extracts the value and embeds it in the state-changing operation form as a hidden field. Once the user fills in the fields and submits the form, the request gets sent with the token cookie (and the session cookie) in the header and also the same token value in the request body.
Now when the request is received by the server, the value in the token cookie and the token value in the request body are extracted and compared to see if they match. If yes, the requested state-changing action gets executed.
Sample Implementation
The same example Spring Boot application used in the previous blog post about Synchronizer Token Pattern as before, with minor changes to the server-side code will be used as the demo here as well.
When the user logs in, his credentials will be validated and allowed in to the home page. The code below is the MainController which handles the authentication, and adds the session cookie and the token cookie to the response. Also in the below code is the PostMapping for /blog, which in this case would be the state-changing operation.
The session id and the csrf token cookies can be seen in the client browser as shown in the image below.
The service class implements the authentication and validation mechanisms as shown in the gist below.
If and only if the request that’s being send includes the token in both the header and the body, the request will be authorized to flow through the server.
How secure is this?
A cross-origin attacker will not be able to read any information from the server nor modify the cookie values, as per the same-origin policy. But still an attacker can trick the authenticated user to send a malicious request to the valid url, but without the token cookie value in the attacker’s request body, the request would be immediately failed by the server. Therefore, as long you do not explicitly enable cross-origin requests to the server, your application is safe.
Or is it really?
But recently security researchers from OWASP have released a possible attack that could bypass the Double Submit Cookie pattern and orchestrate a CSRF attack. The server having no knowledge of the token cookie is one of the causes for the aforementioned problem. There are found possibilities for an attacker to set the cookies by Exploiting subdomains and Man-in-the-middle alterations in plain HTTP connections.
Await more interesting posts…
If you enjoyed this article, please hold down the clap button below 👏 to help others find it.
