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 cy­ber­crim­i­nals. 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. Cy­ber­crim­i­nals take advantage of this situation. They know that logged-in users can usually perform more priv­i­leged 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 rel­a­tive­ly easy to figure out.

The server of the website rec­og­nizes the HTTP request as correctly struc­tured 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 suc­cess­ful 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 con­se­quences.

Three types of CSRF attacks are carried out most fre­quent­ly. 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 en­gi­neer­ing 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, ma­nip­u­late 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 il­lus­trates the potential con­se­quences of the attack method. Suppose you log in to your online banking account. You go to the special form for trans­fer­ring funds. When you complete the form and click the con­fir­ma­tion 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 struc­tured 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 trans­ferred. 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 ad­min­is­tra­tion: If a victim has access to the backend, attackers can create new users or delete the entire website without the ad­min­is­tra­tor’s knowledge.
• Online shopping: An attacker can make purchases from an online store 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 ques­tion­able websites or open sus­pi­cious emails. To protect yourself from CSRF, you should end active sessions on security-critical websites before you visit sites that may not be trust­wor­thy.

Ensure that your device (PC, laptop, smart­phone, etc.) is free of malware. It’s much harder to prevent CSRF if a back­ground ap­pli­ca­tion is spying on you. Once your device is infected, you’re vul­ner­a­ble 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 vul­ner­a­ble forms and HTTP requests. But if a random factor is in­tro­duced, 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 au­to­mat­i­cal­ly rejected.

Online banking sites usually use two-factor au­then­ti­ca­tion. 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 cre­den­tials, they wouldn’t be able to transfer the funds without the second factor.

In theory, the referrer header should offer adequate pro­tec­tion. This part of the HTTP request iden­ti­fies where the request is coming from. It allows websites to filter out all foreign requests. However, referrer headers have not always proven reliable. Browser ex­ten­sions such as ad­block­ers change or delete the referrer header. Users with these ex­ten­sions would then no longer be able to use the website.

One pre­cau­tion that will deter but not nec­es­sar­i­ly prevent all attacks is to define session timeouts. As a website operator, you have to strike a balance between risk and user-friend­li­ness. Online banking sites time out after a few minutes of in­ac­tiv­i­ty. 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.