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?
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.
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.
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:
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.
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.
Practically every PC user fears Trojan horses and computer viruses. Security is paramount if you are managing sensitive data or setting up a server. You need a comprehensive security concept to protect yourself against insidious malware. It’s helpful to know the different types of malicious software that exist, and how to combat and safely remove them.
A man-in-the-middle attack is a deceitful espionage attack which aims to listen, record, or manipulate sensitive data being sent between unsuspecting internet users. To do this, hackers rely on methods that enable them to position themselves, unnoticed, between two or more computers communicating with one another. We introduce you to some well-known attack patterns and countermeasures that can be...
DHCP snooping makes a network more secure. There are no two ways about it: DHCP makes network configuration so much easier. This is especially the case in large networks, where devices are constantly changing and the manual assignment of IP addresses is a never-ending task. Yet by using DHCP to simplify the process, you do relinquish controls, and criminals can take advantage of this. By using...
The same-origin policy (SOP) prevents client-side scripting languages, such as JavaScript, from accessing objects located on another URL that are not part of the running internet application. A convenient way to perform this cross-domain query regardless is through the JSON application JSONP. We explain what exactly this involves and how this method works.
You access a website and, in the background without your knowledge, content is loaded from a third-party server. This is a security risk and is rightly prevented by the same-origin policy (SOP). But what do you do if you need the connection to both servers? Cross-origin resource sharing (CORS) provides secure technology for creating exceptions.
Provide powerful and reliable service to your clients with a web hosting package from IONOS.
View packages
