Double Submit Cookie Pattern
today's blog I am going to talk about another method of CSRF attack prevention mechanism. in my previous blogs, I have talked about what is a CSRF Attack.
I have talked about another method that used to prevent this CSRF attack called Synchronizer Token Pattern.
so let's see how does this double submit cookie patter works
what is double submit cookie?
when we are maintaining the state for CSRF token at the server-side. it is problematic, an alternative defense is to use for this is double submit cookie technique. This technique is easy to implement and it is stateless. In this technique, we send a randomly generated hash 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 visits even before authenticating to prevent login CSRF, the site should generate a strong value and set it as a cookie on the user’s machine separate from the session identifier. The site then requires that every transaction request include this strong value as a hidden form value. If both of them match at the server-side, the server accepts it as a legitimate request and if they don’t, it would reject the request.
who does it implement?
I have created a sample project to implement this method click here to get the source code
first, we need to login to the site using
username → admin
password → pass
when we log in to the server it server starts a session cookie and a session id then it creates 2 set-cookie to send the data to the browser along with CSRF token value and session id.
The setcookie() function defines a cookie to be sent along with the rest of the HTTP headers.
setcookie(name, value, expire, path, domain, secure, httponly);
After the user logged in, I have implemented an Ajax call to get browser cookies(from docmunet.cookie) and I used a split function to get only CSRF token and append it to the hidden field.
When a user updates a status the post request contains this generated CSRF token and the server validates the cookie header from session-id and also server compares CSRF token from request body(hidden field value) against CSRF token from the header cookie. If these tokens are matched then the server accepts the request.
if it is a valid request its show the result like this
if is it invalid it shows result like this.
see you in another blog !!!!
be curious….