Preventing Cross-Site Request Forgery (CSRF) with Double Submit Token Pattern
This post is a continuation of the previous post which refers what is Cross Site Request Forgery (CSRF) and how we can prevent this attack using Synchronizer Token Pattern. As I've mentioned in the previous post there are mainly two ways of preventing a CSRF attack. In this post we will discuss how to prevent a CSRF attack using Double Submit Cookie Pattern. To get a basic understanding of how CSRF work please refer the previous post.
- Double Submit Cookie 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) pseudo-random value 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 also called Stateless CSRF Defense.
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.
- Implementation
We have used java with JSP to implement the above scenario.
Login Page is as follows and user has to provide "admin" for both username and password.
Login Page is as follows and user has to provide "admin" for both username and password.
In the Home page the CSRF token is sent through the body of the form as well with cookie request. Hence, the double submit part.
Validation Page, Here the CSRF token received with the request is matched with the CSRF token received from the body of the form.
These are the cookies and tokens stored in browser with requests. Here, the session id is stored with respective CSRF token.
Now, let's move on to the code base of the project. This is the index.jsp page and handles the login aspects of the project.
- index.jsp
- home.jsp
We have included CSRF token as a hidden field inside the body of form to be submitted with the request.
- confirm.jsp
- web.xml
- Login.java
Here, we store the generated session ID with generated CSRF token in the browser.
- Validator.java
Here, the CSRF token received in the body of the form is matched against CSRF token received with cookie and verified. Therefore, CSRF atatck can be mitigated easily by providing token in both session cookie header and in the body of the request.
The full implementation of this example can be found at Github. See you guys with another blog series regarding security of modern online applications.
Comments
Post a Comment