What is CSRF? (Cross-site request forgery attack)

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?

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 realise 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.

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.

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 shop without the user’s knowledge.

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.

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.

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.

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.

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.

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.