What is Cross Site Request Forgery (CSRF)

Imagine you're logged into your favorite online banking website, checking your account balance, when suddenly, without your knowledge, a malicious website tricks your browser into making unauthorized transactions. This scenario highlights a critical web security vulnerability that affects countless websites and their users. Understanding this threat is essential for both users and developers to ensure safer online experiences.

In this article, we will explore the mechanics of Cross-Site Request Forgery (CSRF), a serious vulnerability that exploits the trust between a user's browser and a website. We'll dive into how attackers leverage this flaw, the potential impacts on users, the attack surfaces involved, a detailed look at how exploitation occurs, and effective prevention strategies for both users and server-side developers.

What is Cross-Site Request Forgery?

Cross-Site Request Forgery (CSRF) is one of the most severe vulnerabilities that can be exploited in various ways, from changing a user's info without their knowledge to gaining full access to a user's account. Almost every website uses cookies today to maintain a user's session. Since HTTP is a "stateless" protocol, there is no built-in way to keep a user authenticated for a series of requests. Asking the user for his credentials at each operation is a very bad idea in terms of user experience. This is why cookies are used.

Cookies are very efficient for this purpose and are secure if they possess enough entropy, cryptographic strength, and are transmitted over a secure channel (using HTTPS). 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 play. 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 its action will be successfully carried out.

Attack Surfaces

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.

Exploitation

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:

1. 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.)
2. 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).
3. 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.

Prevention

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.

Best Practices for Developers

To keep websites safe from CSRF attacks, developers can use these simple, effective methods:

• Use CSRF Tokens: Add a unique, secret code (token) to every form or request that changes data. This code is tied to the user’s session and must be included for the request to work. Hackers can’t guess it, so their fake requests fail.
• Set SameSite Cookie Attribute: Add the "SameSite" setting to cookies (e.g., SameSite=Strict or SameSite=Lax). This tells browsers to only send cookies for requests from the same website, blocking sneaky requests from other sites.
• Allow Only POST for Changes: Ensure actions like updating a password or email only work with POST requests, not GET. This makes it harder for attackers to trick browsers into sending harmful requests via simple links.
• Check Referer or Origin Headers: Verify that requests come from your website by checking the Referer or Origin headers. If they come from an unknown source, block them.
• Use Frameworks with Built-in Protection: Popular tools like Django or Spring come with ready-to-use CSRF defenses. Turn these features on to save time and ensure strong protection.

Must Read

• How to Reduce Risk of Exposure to CSRF, XSRF, or XSS Attacks?
• What is SameSite Cookies and CSRF Protection?
• CSRF Protection in Flask

Conclusion

Cross-Site Request Forgery (CSRF) is a sneaky way hackers can trick your browser into making unwanted changes on websites you're logged into, like changing your password or personal details. By understanding how CSRF works and using simple protections like CSRF tokens on websites, both users and developers can stay one step ahead, keeping online accounts safe and secure.