Cross-Site Request Forgery (CSRF or XSRF), also called Client-Side Request Forgery, is a type of attack that targets web applications. It allows an attacker to induce users into accessing and changing a state on a website inadvertently.

In this article, we are going to explain how CSRF attacks work; why do they pose a threat to web applications; and what are some of the security safeguards that we can implement to protect our websites against them.

How does a CSRF attack work?

A CSRF attack targets users that are authenticated to a vulnerable website. Through this attack, an attacker can take the identity of a user and perform an action on their behalf. These actions will then appear to the website as if they were performed by the legitimate user.

To better understand how the process works, let’s consider the following scenario.

Let’s say that a legitimate user is authenticated to their bank’s website. Now, let’s assume that this website is vulnerable to CSRF. A user can send money to other users from their account by accessing the following link:

www.bank.com/transfer.php?to=recipient&amount=1000

An attacker can forge a link that would make the logged-in user send him money, This link will look something like this:

www.bank.com/transfer.php?to=attacker&amount=1000

The attacker can then induce the legitimate user to access this link by sending it through a phishing email, or through another malicious website that the attacker controls.

Once the user clicks on the link, then an amount of 1000$ will get transferred to the attacker from the victim’s account.

This is just one example of the many CSRF attack scenarios. Other examples include password resets, items added to a shopping cart, and stolen sensitive information. All that without the user’s knowledge.

GET vs POST

In this example, the website allows state changing operations using the GET method. Such websites are a golden mine for a malicious actor. Since the GET method contains the parameters in the link, the attacker will only have to send a forged link to a legitimate user as we did here.

For this reason, using the POST method for state-changing operations is preferrable. It does not include parameters in its link, and requires using a form to send these parameters.

Although the POST method is not entirely immune to CSRF, it just adds another step for the attacker and complicates the delivery process. Instead of delivering a simple link, the attacker will have to create an HTML page with a form that sends the malicious request to the victim’s website.

Web developers should not rely solely on the POST method as the solution to the problem, we will discuss more effective controls against CSRF later in this article.

Causes

As the above process shows, what makes this attack vector possible is the trust that the website has in the browser.

When a user logs in, the website starts a session and provides the associated cookie to the user’s browser. From then on, the browser will include this cookie in all future requests. The website then trusts all requests originating from that browser.

Now, when a user with an active session receives a forged link from an attacker, and they click on it, the browser will include the user’s cookie with the request and the website will see that the request originates from a legitimate user with an active session.

Impact

The impact of CSRF can be devastating for any organization having a website that is vulnerable to this attack. They might have their reputation tarnished, users may become mistrustful of them, and they may even run the risk of incurring regulatory fines.

In addition to attacks targeting end users, an attacker can use CSRF against users with privileged account, such as admins. When successful, this might give the attacker control over the entire web application.

All these are reasons enough to implement good practices to protect against CSRF attacks.

How to protect against CSRF?

Thankfully, your website doesn’t have to be vulnerable to this attack. There are some good practices that you can implement if you want to protect your website against CSRF.

Some of these good practices include:

• A website should not permit state-changing operations based on GET requests.
• Always limit session duration for connected users. Websites should terminate sessions whenever users leave the website.
• Cross-Site Scripting (XSS) prevention controls should also be implemented, since XSS can be used to exploit CSRF.

More importantly, there are two main controls that can help in preventing CSRF attacks against a website, and these are CSRF tokens and SameSite cookie.

CSRF Tokens

Use anti-CSRF tokens with every request that changes a state in the website. The web application should generate these tokens on the server-side and their value should be unpredictable. If a malicious user attempts a CSRF attack, they will never be able to change a state on the website since their request would need to include the associated token, which they do not know.

SameSite Cookie

The SameSite cookie attribute will prevent cookies from being sent in cross-site requests. A website should specify within its response header “Set-Cookie” the value of SameSite to Lax or Strict. This will prevent the browser from sending the session cookie to the website with requests originating from other websites.

---

This article was just a brief introduction to Cross-Site Request Forgery (CSRF). It should be your first step in the topic. If you wish to learn more, you can check OWASP’s page about this attack.