CSRF: Cross-site request forgery attacks explained

Very few Internet users are aware of the dangers they may face when surfing the web. In addition to spear phishing, cross-site request forgery is currently a popular tool for cybercriminals. Hackers can use this method to initiate money transfers to foreign bank accounts via online banking websites. But how exactly does this attack method work? And how can you protect yourself from it?

What is CSRF?

Definition

CSRF: Cross-site request forgery (CSRF or XSRF) is an attack method mostly used for committing Internet fraud. Criminals use HTTP requests to take over a user’s authenticated session (session riding) and perform malicious actions.

Suppose you’ve logged in to a website. After logging in, you remain logged in for the duration of the session (this time period can vary widely depending on the site) without having to re-enter your password. Cybercriminals take advantage of this situation. They know that logged-in users can usually perform more privileged actions than users who are not logged in.

In a nutshell, here’s how CSRF works: While you’re logged into the site, you visit another website created by the hacker. Once there, you perform some action, such as clicking a button. The attacker then sends an HTTP request to the site you’re signed in to and uses your identity to execute a malicious action because your session is still active. All the attacker needs to know is the correct HTTP request, which is relatively easy to figure out.

The server of the website recognizes the HTTP request as correctly structured and sees from your cookies that you (or your browser) are still logged in. The server executes the action and you might not realize that an action has been taken on your behalf.

The CSRF attack is successful because the receiving server doesn’t check where the request is coming from. It doesn’t know whether the HTTP request was generated by the website itself or by an outside source. The attacker takes advantage of a weakness in the browser, which forwards the requests without assessing the consequences.

Three types of CSRF attacks are carried out most frequently. The most popular technique is to plant an exploit URL. This URL is hidden on an external website or in an email. Opening the URL triggers the HTTP request. In principle, you can detect this type of URL if you’re paying close attention. However, social engineering and URL spoofing can be used to disguise the origin of the URL.

There is also potential for cross-site scripting (XSS): Some hackers, instead of setting up their own malicious website, manipulate an existing website through XSS, which is then used to perform criminal actions without the website operator’s knowledge. In this type of attack, JavaScript is typically planted on a website to carry out a CSRF attack.

A cross-site request forgery attack is also possible if attackers manage to place malware on the victim's computer. This allows attackers to directly instruct the browser to send the HTTP request. However, attackers have even more options if they're able to plant viruses or malware on the client.

Example of a cross-site request forgery attack

We’ll use online banking for our example of CSRF because it best illustrates the potential consequences of the attack method. Suppose you log in to your online banking account. You go to the special form for transferring funds. When you complete the form and click the confirmation button, a specific HTTP request is sent to the server and the funds transfer is made. However, the attacker knows exactly how the form and HTTP request are structured and can replicate both. Next, the fraudster’s account details and an amount set by the fraudster are inserted into the form.

The hacker can then set up a website (or send an email) that will attract your interest. The website or email asks you to click on a seemingly harmless link that activates the fake HTTP request. The request is then sent to the bank, which performs the action requested by the hacker. There’s no reason for the server not to execute the action because the session is still active and the request is correct. So the money is simply transferred. You won’t notice anything until the next time you check your account balance.

Note

We’ve used the example of a bank account because it shows how bad the consequences of CSRF can be. But in reality, bank websites and funds transfer mechanisms in particular have multiple layers of protection against such attacks.

Other attack scenarios:

  • Social media: Attackers post comments or likes on behalf of logged-in users.
  • Website administration: If a victim has access to the backend, attackers can create new users or delete the entire website without the administrator’s knowledge.
  • Online shopping: An attacker can make purchases from an online store without the user’s knowledge.
Fact

CSRF attacks always aim to perform specific actions on your behalf. However, CSRF can’t be used to extract information because attackers can’t see into your account. Suppose you’re on a website with a download function for sensitive data (such as account statements). An attacker could trigger the download, but still wouldn’t be able to access the data because it would be on your device.

Security measures: How can you prevent CSRF attacks?

Use caution and care online

As a user, you need to exercise caution. You’re not likely to fall victim to an attack like this if you don’t visit questionable websites or open suspicious emails. To protect yourself from CSRF, you should end active sessions on security-critical websites before you visit sites that may not be trustworthy.

Check your devices for malware

Ensure that your device (PC, laptop, smartphone, etc.) is free of malware. It’s much harder to prevent CSRF if a background application is spying on you. Once your device is infected, you’re vulnerable to many other types of attacks.

CSRF protection by website operators

Website operators can also protect visitors to their sites: Attackers can carry out cross-site forgery attacks because they know the exact structure of vulnerable forms and HTTP requests. But if a random factor is introduced, the hacker will usually give up. The website can create a one-time token (a random string) and make it part of the HTTP request. If the server receives a request that contains no token or an invalid token, the request is automatically rejected.

Two-factor authentication

Online banking sites usually use two-factor authentication. Before making a funds transfer, the user has to enter a TAN code that is not provided via the website. This method protects against CSRF as well as other types of attacks. Even if attackers steal the user’s credentials, they wouldn’t be able to transfer the funds without the second factor.

Referrer header

In theory, the referrer header should offer adequate protection. This part of the HTTP request identifies where the request is coming from. It allows websites to filter out all foreign requests. However, referrer headers have not always proven reliable. Browser extensions such as adblockers change or delete the referrer header. Users with these extensions would then no longer be able to use the website.

Log out when you’re done

One precaution that will deter but not necessarily prevent all attacks is to define session timeouts. As a website operator, you have to strike a balance between risk and user-friendliness. Online banking sites time out after a few minutes of inactivity. But other websites, such as many social media sites that handle less sensitive data, keep sessions active for days. A CSRF attack can’t happen once the user is logged out of the site.


Wait! We’ve got something for you!
Have a look at our great prices for different domain extensions.


Enter the web address of your choice in the search bar to check its availability.
.club
$1/1st year
then $15/year
.com
$1/1st year
then $15/year
.info
$1.60/1st year
then $20/year
.org
$1/1st year
then $25/year