CSRF Attack: Cross-Site Request Forgery Definition & Defense

A CSRF (cross-site request forgery) tricks authenticated users into granting malicious actors access through the authentic user's account.

During a cross-site request forgery (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 favourites 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 behaviour!)

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.