Cross Site Request Forgery (CSRF) is one of the most severe vulnerabilities which can be exploited in various ways- from changing user’s info without his knowledge to gaining full access to user’s account.
However, there is a problem, browsers submit cookies to a website whenever a request is made to that website without checking the “origin” of the request. This is where CSRF comes into picture.
The attacker places some code on his website that makes a genuine looking request to the target website. The cookies of the target website will be added by the browser in the request . This will make that forged request a legal one and it’s action will be successfully carried out.
The attack surfaces for CSRF are mostly HTTP requests that cause a change in something related to the victim, for example: name, email address, website and even password. It is sometimes used to alter the state of authentication as well. (Login CSRF, Logout CSRF) which are less severe but can still be problematic in some cases.
Consider a website example.com and the attacker’s website evil.com. Also assume that the victim is logged in and his session is being maintained by cookies. The attacker will:
- Find out what action he needs to perform on behalf of the victim and find out its endpoint (for example, to change password on target.com a POST request is made to the website that contains new password as the parameter.)
- Place HTML code on his website evil.com that will imitate a legal request to target.com (for example, a form with method as post and a hidden input field that contains the new password).
- Make sure that the form is submitted by either using “autosubmit” or luring the victim to click on a submit button.
When the victim visits evil.com and that form is submitted, the victim’s browser makes a request to target.com for a password change. Also the browser appends the cookies with the request. The server treats it as a genuine request and resets the victim’s password to the attacker’s supplied value. This way the victim’s account gets taken over by the attacker.
- On user side:
User side prevention is very inefficient in terms of browsing experience, prevention can be done by browsing only a single tab at a time and not using the “remember-me” functionality.
- On Server Side:
There are many proposed ways to implement CSRF protection on server side, among which the use of CSRF tokens is most popular. A CSRF token is a string that is tied to a user’s session but is not submitted automatically. A website proceeds only when it receives a valid CSRF token along with the cookies, since there is no way for an attacker to know a user specific token, the attacker can not perform actions on user’s behalf.
- Cross-Site Request Forgery (CSRF) Protection Methods and Bypasses
- What is Cross Site Scripting (XSS) ?
- Cookie Tracking and Stealing using Cross-Site Scripting
- Difference between site to site VPN and remote access VPN
- Handling Ajax request in Django
- Introduction to RSS(Rich Summary Site)
- Top 5 Common Mistakes in Technical On-site Interviews
- If we delete cookies of a site, we can still logged in without logging again
- Making your first Open Source Pull Request | Github
- Why Cross Browser Testing Gaining Importance?
- Introduction to Kivy ; A Cross-platform Python Framework
- Getting Started with Cross-Platform Mobile Application using Flutter
- Benefits of Automated Cross-Browser Testing for Online Business
If you like GeeksforGeeks and would like to contribute, you can also write an article using contribute.geeksforgeeks.org or mail your article to email@example.com. See your article appearing on the GeeksforGeeks main page and help other Geeks.
Please Improve this article if you find anything incorrect by clicking on the "Improve Article" button below.