CSRF Attack: Cross-Site Request Forgery Definition & Defense

TL;DR

Cross-site request forgery (CSRF) attacks exploit authenticated browser sessions to perform unauthorized actions on behalf of unsuspecting users. These attacks depend on session cookies, predictable request structures, and social engineering to deceive both users and servers. Effective defenses include anti-forgery tokens, SameSite cookies, Representational State Transfer (REST) design principles, and requiring user verification before sensitive actions.

How does a site get tricked into trusting a malicious request?

CSRF tricks authenticated users into granting malicious actors access through the authentic user's account.

During a CSRF attack, a hacker does something under a victim's authentication. It's a bit like a magic trick. A user logs into a website, and somehow, that person's login does all sorts of things that the person would never do willingly. 

If CSRF attacks sound confusing, that's by design. These are attacks that rely on coding know-how, trickery, trust, and luck. Some say CSRF attacks are as old as the web itself. As soon as one site started making requests of another site, CSRF attacks were born. 

But you can uncover and vanquish even old, sophisticated attack vectors. Read on to learn how these attacks work, and what to do (and avoid) as you pull together CSRF protection plans.

How do CSRF attacks work? 

In technical terms, a CSRF attack is one in which a hacker hijacks the identity and rights of a user and puts them to work to perform an undesired function. In layman's terms, a CSRF attack involves someone fooling you, stealing your identity, and doing something online like transferring money from your bank account under your login. 

A CSRF attack focuses on changing something on the host server. A hacker might change your username or steal your money or change a common shipping address. The site won't notify you that anything is wrong, as the hacker will get all associated notifications. 

Let's walk through CSRF attacks step by step:

1. Normal login: A victim taps in a known username and password.
2. Standard setup: The site creates session cookies and stores them in the victim's browser. 
3. Approach: The victim interacts with the attacker for the very first time. They might meet via a phishing email, or the victim might load a compromised website. 
4. Mistake: The victim interacts with the attacker's bait. 
5. Attack: The hacker's code submits a request to the site the user is logged into. The browser responds, and in that note, it includes the victim's saved credentials. 
6. Result: The server checks the request, and since it seems legitimate, it executes the code. 

CSRF attacks require each one of these steps, and they must be performed in sequence. Skip even one of them, and the attack will fail.

Is your site vulnerable to CSRF attacks?

A hacker can't perform a CSRF attack without a specific set of conditions. 

They need three elements in particular.

1. Cookies: The target site might use simple, one-time cookies to validate sessions for logged-in users. 
2. Simple programming: A predictable, simple set of parameters define the requests. A hacker knows just what will happen next. 
3. Target actions: A hacker must be able to do something important (like transfer money) to make the effort worthwhile. 

Understand the risks involved with CSRF attacks by examining prior victims. Large websites have been attacked, including:

• ING Direct. A vulnerability allowed hackers to both create new accounts and transfer money from one place to another. 
• YouTube. Hackers were able to add users as friends or favorites and then send notes on behalf of victims under their logins. 
• The New York Times. Hackers could find the email addresses of users. 

Note: The companies have fixed all of these vulnerabilities.

How can CSRF attacks affect individuals?

Individuals can get hacked too. Security experts often cite email vulnerabilities. A hacker could steal your credentials and send thousands of threatening email messages to government officials. They could come to your home, demanding your arrest, as they have no idea a hacker is involved.

How are CSRF attacks created and delivered? 

CSRF attacks lean on common browser functionality. Any time you make a request, it's encoded with steal-able data, such as your:

• Username 
• Session cookie 
• Internet Protocol (IP) address 
• Credentials 

A hacker must have the ability to grab this data. And the hacker must use HTML coding to fool the server into executing the desired function. Unfortunately, the software to make such an attack is readily available online. (And we won't link to it here, as we don't like to encourage hacking behavior!)

With a target site selected and the code built, a hacker must deliver the goods. That might involve:

• Email. About half of all people click anything sent to them. If a hacker sends a note at the exact moment a user is already logged in, the attack is already in progress. 
• Forgery. A hacker creates a normal-seeming form or script on a page a victim might look at while also logged into the target site. While many visitors to that site might not be logged into the target site, a hacker needs just one visitor to make the work worthwhile. 
• Social engineering. A hacker might induce a victim to visit a forged site via notes that seem to come from trusted sources on social media messaging apps.  

What can an attacker do with your credentials?

If the victim is a standard user, the hacker can take over common tasks like changing passwords, transferring money, and swapping shipping addresses. But if the victim is an administrator on the target site, the hacker can assume full control.

CSRF protection checklist 

If you run a compromised site and a hacker attacks someone there, you'll share in the blame. It's wise to do all you can to build a safe, protected community. 

How should you respond to a suspected CSRF attack?

Train your employees to watch for discrepancies in their online lives. And if your customers complain that hackers targeted them while visiting your site, pay attention. You might need to lock down your code until you track down the vulnerability and stop it. 

If you're looking for even more ways to protect your customers, we can help. Contact us to find out more about Okta's identity solutions. We can help secure logins on your site and protect data both at rest and in transit.

Frequently asked questions

What conditions must exist for a cross-site request forgery (CSRF) attack to succeed?

Three conditions must be present for a CSRF attack to succeed: the target site must use cookies to validate sessions for logged-in users, the request parameters must be predictable and simple enough for a hacker to replicate, and there must be a valuable target action — such as transferring money or changing account details — that makes the effort worthwhile.

How does a hacker deliver a cross-site request forgery (CSRF) attack to a victim?

A hacker can deliver a CSRF attack through several methods: sending a malicious link via email at the moment a user is already logged into the target site, embedding a forged form or script on a page the victim might visit, or using social engineering to lure the victim to a forged site through messages that appear to come from trusted sources on social media or messaging apps.

What makes cross-site request forgery (CSRF) attacks difficult to detect?

CSRF attacks are difficult to detect because the server receives the malicious request and, since it appears to come from a legitimately authenticated user, it executes the code without raising any alerts. All associated notifications go to the hacker rather than the victim, so the victim has no immediate indication that anything has gone wrong.

Which cross-site request forgery (CSRF) protection methods are ineffective?

According to The Open Web Application Security Project® (OWASP) Foundation, several commonly attempted protections do not work: secret cookies (which can still be shared as session identifiers), POST restrictions (since hackers will simply find another method), adding extra steps to a process (which an attacker can still predict and replicate), and URL rewriting (which still exposes the user's session ID).

What are the recommended defenses against cross-site request forgery (CSRF) attacks?

Four recommended defenses exist against CSRF attacks: following REST design principles to assign actions to specific HTTP verbs, implementing anti-forgery tokens that the server requires for all subsequent requests, using SameSite Cookie settings to block cookies sent with third-party requests, and requiring users to verify their login details before performing any sensitive action.

Can cross-site request forgery (CSRF) attacks affect individual users as well as websites?

Yes, individual users can be targeted by CSRF attacks as well. For example, a hacker could steal a user's credentials and use them to send thousands of threatening email messages to government officials — leaving the victim exposed to serious consequences with no knowledge that a hacker was responsible.

References

Cross-Site Request Forgery Is Dead. (February 2017). Scott Helme. 

Mitigating CSRF Attacks in Single-Page Applications. (January 2020). Medium. 

Popular Websites Vulnerable to Cross-Site Request Forgery Attacks. (September 2008). Freedom to Tinker. 

So Much for Counter-Phishing Training: Half of People Click Anything Sent to Them. (August 2016). Ars Technica. 

Threat Watch: Cross Site Request Forgery (CSRF). (December 2007). CSO. 

Cross-Site Request Forgery (CSRF). OWASP. 

Protecting Your Users Against CSRF. Hacksplaining. 

Is Your Site Vulnerable to CSRF Attacks?

A hacker can't perform a CSRF attack without a specific set of conditions. 

They need three elements in particular.

1. Cookies: The target site might use simple, one-time cookies to validate sessions for logged-in users. 
2. Simple programming: A predictable, simple set of parameters define the requests. A hacker knows just what will happen next. 
3. Target actions: A hacker must be able to do something important (like transfer money) to make the effort worthwhile. 

Understand the risks involved with CSRF attacks by examining prior victims. Large websites have been attacked, including:

• ING Direct. A vulnerability allowed hackers to both create new accounts and transfer money from one place to another. 
• YouTube. Hackers were able to add users as friends or favorites and then send notes on behalf of victims under their logins. 
• The New York Times. Hackers could find the email addresses of users. 

Note: The companies have fixed all of these vulnerabilities.

Individuals can get hacked too. Security experts often cite email vulnerabilities. A hacker could steal your credentials and send thousands of threatening email messages to government officials. They could come to your home, demanding your arrest, as they have no idea a hacker is involved.

CSRF Attack Creation & Delivery Explained 

CSRF attacks lean on common browser functionality. Any time you make a request, it's encoded with steal-able data, such as your:

• Username 
• Session cookie 
• IP address 
• Credentials 

A hacker must have the ability to grab this data. And the hacker must use HTML coding to fool the server into executing the desired function. Unfortunately, the software to make such an attack is readily available online. (And we won't link to it here, as we don't like to encourage hacking behavior!)

With a target site selected and the code built, a hacker must deliver the goods. That might involve:

• Email. About half of all people click anything sent to them. If a hacker sends a note at the exact moment a user is already logged in, the attack is already in progress. 
• Forgery. A hacker creates a normal-seeming form or script on a page a victim might look at while also logged into the target site. While many visitors to that site might not be logged into the target site, a hacker needs just one visitor to make the work worthwhile. 
• Social engineering. A hacker might induce a victim to visit a forged site via notes that seem to come from trusted sources on social media messaging apps.  

If the victim is a standard user, the hacker can take over common tasks like changing passwords, transferring money, and swapping shipping addresses. But if the victim is an administrator on the target site, the hacker can assume full control.

CSRF Protection Checklist 

If you run a compromised site and a hacker attacks someone there, you'll share in the blame. It's wise to do all you can to build a safe, protected community. 

The OWASP® Foundation warns that these CSRF protection steps do not work:

• Secret cookies: They might be shared as session identifiers, just as other cookies might be. 
• POST restrictions: It's common for hackers to target the POST functionality in these attacks. But if you restrict this form, hackers will find another way. 
• Adding steps: As long as an attacker can figure out the standard sequence, this offers no protection. 
• URL rewriting: The user's session ID is still exposed, so this step won't help. 

Here are four protection steps you SHOULD take:

• REST: Follow these design principles and assign actions to different HTTP verbs. A hacker can't use a GET request to grab data, as it will be specific to viewing. 
• Anti-forgery tokens: The server should request this code for any subsequent requests, and if it's not there, it should drop those requests.
• SameSite Cookie: This Google-created anti-CSRF tool can help block cookies sent along with requests from third parties. 
• Verify: The user will confirm login details before taking a sensitive action. 

Train your employees to watch for discrepancies in their online lives. And if your customers complain that hackers targeted them while visiting your site, pay attention. You might need to lock down your code until you track down the vulnerability and stop it. 

If you're looking for even more ways to protect your customers, we can help. Contact us to find out more about Okta's identity solutions. We can help secure logins on your site and protect data both at rest and in transit.

References

Cross-Site Request Forgery Is Dead. (February 2017). Scott Helme. 

Mitigating CSRF Attacks in Single-Page Applications. (January 2020). Medium. 

Popular Websites Vulnerable to Cross-Site Request Forgery Attacks. (September 2008). Freedom to Tinker. 

So Much for Counter-Phishing Training: Half of People Click Anything Sent to Them. (August 2016). Ars Technica. 

Threat Watch: Cross Site Request Forgery (CSRF). (December 2007). CSO. 

Cross-Site Request Forgery (CSRF). OWASP. 

Protecting Your Users Against CSRF. Hacksplaining.