CSRF token - Double Submit Cookies Pattern
Cross-site Request Forgery Protection in web applications via Double Submit Cookies Pattern
What is Cross-site Request Forgery Protection(CSRF)?
This is a kind of attack and type of a malicious exploit of a website. We also name this attack as the one-click attack or session riding. This forces an end user to execute unwanted actions on a web application in which they're currently authenticated. This attack is mainly focusing on state-changing request, not theft data.
![](https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgu2XeAFnbbw03RCVXB9H5DbxWjCJTzA0IgoNBHCnLU8shJTK9yPK7HwM1VkeEoPLDigv9yTPqI6B7NDInKndqCGsKs1WsyYmmYn9bWO9dYJyTxkz6IzY4ol_5t8h2ec_8T5Yn0Kf2tjX9f/s320/57BlC.png)
As an example, if the user 'A' wants to transfer the 200$ to the bank 'B'.He needs to send a request to the bank 'B' and bank will send the response by authenticating user 'A'.There is an attacker he/she needs to fraud this money form user 'A'.what the attacker can do is he will create a malicious web link and send it to the user by forcing to click that link . while the user clicks the link for the transferring purpose but the thing is attacker was transferring the money to his account. To avoid such kind of stateful attacks we need to enable CSRF protection in our web pages.
What is Double Submit Cookie pattern?
Similarly to the cookie-to-header approach, but without involving JavaScript, a site can set a CSRF token as a cookie, and also insert it as a hidden field in each HTML form sent to the client. When the form is submitted, the site can check that the cookie token matches the form token. The same-origin policy prevents an attacker from reading or setting cookies on the target domain, so they cannot put a valid token in their crafted form.
The advantage of this technique over the Synchronizer pattern is that the token does not need to be stored on the server.
The advantage of this technique over the Synchronizer pattern is that the token does not need to be stored on the server.
In this blog post, we are going present how to mitigate such kind of attack by enabling CSRF token validation.
We have a simple login page to provide username and password which is checked with the hardcoded values. Once the authenticated user login to the system it will create a session and also generate the CSRF token on the server side. When login successful, token will be stored in a cookie on the web page. After authenticating his or her identity to the website user wants to continue his or her activity by submitting whatever the action. At this time stored token in the cookie will check with stored CSRF token value in server side. If the stored token value in the cookie field wrong the system will redirect to the login page by avoiding your response. Otherwise, it will continue the process by assuming an authenticated user has logged in to that session.
Let's see this source code....
- Front End - Angular CLI
- Back End - Node JS
- This is the login component we create it as for our login page. You can enter your username and password. If the entered values are correct it will redirect to the profile component.
- Send username and password to the backend using a POST request. If the response is success get the CSRF token and save in a cookie. If server failed to authenticate the user display an error message.
- In the server side validate the username and password, if it valid create a token. Then server will send the token to the frontend.
- After successfully login to the system user will redirect to the profile page. When the profile page load, get the token and save in a hidden field. And the same time save the token in a cookie.
- Along with all state changing operations, this cookie's value should be sent in HTTP header. The server should receive both the cookie and the header for comparing them.
- In server side get the token in request body and the request header. Then server will compare both token. If it valid do the action else send a error message to frontend.
https://github.com/ShalithaM/Double_Submit_Cookies_Pattern.git
Comments
Post a Comment