CSRF Protection by using Double Submit Cookie

What is CSRF?

Cross-site Request Forgery (CSRF), also known as XSRF, Sea Surf or Session Riding, is an attack vector that tricks a web browser into executing an unwanted action in an application to which  a user logged in.
A successful CSRF attack can be devastating for both the business and user. It can result in damaged client relationships, unauthorized fund transfers, changed passwords and data theft – including stolen session cookies. With a little help of social engineering (such as sending a link via email or chat), an attacker may trick the users of a web application into executing actions of the attacker’s choosing.

How to prevent CSRF vulnerabilities?

According to the recommendations of  OWASP (Open Web Application Security Project), there are two separate checks as standard CSRF defence which does not require user intervention.

1. Check standard headers to verify the request is same origin
2. AND check CSRF token

Corresponding to the topic of the post, Check CSRF token is focused.

There are several recommended methods to implement CSRF token check.

1. Synchronizer Tokens
2. Double Submit Cookie Defense
3. Encrypted Token Patterns
4. Custom Header

 

Double Submit Cookie Defense

as above figure when client login to the system server generates the CSRF token and store it in the client side (on cookie) when next reques goes to server, client embed the csrf token in to submit form and sends with CSRF token cookie. when server receive an request from client, it will validate user by comparering  both CSRF token field on the submit form and CSRF token cookie.

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:

1. Cookies cannot be tagged as HTTPONLY
2. 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 to implement -:

step 1- login page.