What is a cross-site request forgery, and how can we avoid falling victim to such attacks?

Last updated: November 30, 2024 Reading time: 6 minutes
Disclosure
Share
avoid falling victim to such attacks?

Several cybercrimes involve forgery, which essentially consists of creating, modifying, or possessing false documents to be used in fraudulent schemes. It entails misrepresentation to achieve an illegal or felonious goal.

Phishing, for example, incorporates some form of forgery in its attempt to deceive people. For example, a forged website or login interface makes victims believe that they are using an official website, so they compromise their private information. Fake news and propaganda in social engineering campaigns may also use forged news articles and fabricated statements from famous personalities to advance an idea.

Online forgery is not just about creating or modifying documents, web pages, or entire websites to defraud others. It also comes in a more sophisticated form, as cross-site request forgery attacks demonstrate.

What is cross-site request forgery?

Also referred to as one-click attacks or session riding, cross-site request forgery exploits vulnerabilities that target websites, wherein unauthorized commands are sent from a user deemed safe or trusted by a web application. As the term implies, it tricks a website into accepting a command that has not been found anomalous by a web application.

A successful CSRF attack results in a browser executing an unwanted command in an application a user is logged in. It is a highly dangerous attack that affects ordinary internet users and businesses. It means the possibility of making unauthorized purchases and fund transfers. For businesses, it can adversely affect client relationships or a brand’s reputation.

How are CSRF attacks undertaken?

Usually, cross-site request forgery attacks are conducted with social engineering. First, the target/victim is tricked into transmitting a forged request to a server. This can be done through an email (with a call to action and button) or a link (shared on forum boards, comment sections, chat groups, or instant messages) that someone could carelessly click.

The forged request often makes a web browser execute a command because the user (victim) is logged in to a web application or account when the button or link is clicked. This means the user unwittingly sends a request (after clicking on the link) while authenticated by the application, making it extremely difficult for a website or online service to determine if the request is legitimate or a falsification.

The attacker studies the applications that the potential victims will use. They need to devise ways to modify requests that appear legitimate and unsuspicious. Some systems integrate security features that can identify forgeries. However, most systems do not, so CSRF attacks tend to have high success rates.

An example of a CSRF attack

One good example of a CSRF attack is modifying a GET request for a bank transfer.

A bank transfer may use the following GET request string: 

“GET http://netbank.com/transfer.do?acct=PersonB&amount=$500 HTTP?1.1”

“PersonB” refers to the user being attacked, and $500 is the amount to be transferred. This request can be forged to direct the transfer to a different account by turning it into the following:

“GET http://netbank.com/transfer.do?acct=AttackerA&amount=$500 HTTP?1.1”

Of course, the attacker will not use this string as it is. Typically, they have to embed it in a hyperlink that will likely convince the target user to click. For example, it can be embedded in a truncated message with a “Read More!” link at the bottom. The “Read More!” hyperlink will use the following link.

<a href=”http://netbank.com/transfer.do?acct=AttackerA&amount=$500”>Read More!</a>

This hyperlink can then be sent to someone via email or instant message. It can be shared on discussion boards and the comments sections of blogs and news sites. If someone who happens to be logged in to their bank account (the bank account that uses the exact GET string for file transfers as above) clicks on the link, it executes a fund transfer command.

Note that this is only a simple demonstration of how a CSRF attack works. Banks that only use POST requests are not vulnerable to malicious requests framed using the <a> href tag. However, they may be affected by those sent using the <form> tag with an automatically executing embedded JavasScript.

Protection against CSRF attacks

To avoid falling for CSRF attacks, users must log out of web applications or online accounts when not using them. It is also advisable to turn off password saving on web browsers.

Usernames and passwords should never be shared with anyone or stored on insecure platforms. Additionally, it’s not good to browse the internet simultaneously while logged in to an online bank account. Moreover, enabling multi-factor authentication is an added layer of protection.

On the part of website developers or online service providers, preventing cross-site request forgery attacks is possible using tokens and custom rules.

Random tokens can be generated whenever a session request is made to ensure that sessions are unique; hence sessions requested unwittingly after clicking a CSRF hyperlink are blocked. Also, session requests that don’t match their respective session IDs cannot reach an application.

Another way to prevent CSRF attacks is to double the submission of cookies. This method also uses tokens, wherein a random token is assigned to a cookie for a specific session and another to a request parameter. The server examines both tokens to check if they match. If they do not match, then no session is created.

Unfortunately, the use of tokens is not a foolproof solution against CSRF. Tokens can be exposed to sniffers at various points. If the tokens link to an external URL to secure the site, they can be extracted from the HTTP log files, browser history, and network appliances.

A more practical solution against cross-site request forgery is custom rules. There is no all-encompassing solution to address such attacks because they are highly individual. That’s why it’s more effective to set specific rules that plug vulnerabilities into handling requests. This is not going to be an easy task. The security team must study their setup meticulously to spot security weaknesses and introduce protective rules.

However, some security firms offer solutions that make it easy to prevent CSRF attacks using custom rules. For example, a proprietary solution called IncapRules features a custom rules engine that enables rapid generation of custom security policies. These rules can be used to defy social engineering attempts by evaluating requests based on their HTTP referrer header content and a list of domains deemed secure or trustworthy.

Addressing the impact of forgery risks

Forgery attacks, including CSRF, are undertaken with deception in mind. They are often launched in conjunction with social engineering. The key to addressing them is to prevent unwitting application authorizations from legitimizing requests or creating the impression of legitimacy. Viewing forgery-based threats individually is essential to set up defenses that address unique schemes while ensuring that the “human weakness” factor is minimized.

Share this article

About the Author

Waqas is a cybersecurity journalist and writer who has a knack for writing technology and online privacy-focused articles. He strives to help achieve a secure online environment and is skilled in writing topics related to cybersecurity, AI, DevOps, Cloud security, and a lot more. As seen in: Computer.org, Nordic APIs, Infosecinstitute.com, Tripwire.com, and VentureBeat.

More from Iam Waqas

Related Posts