A number of cybercrimes involve forgery, which essentially involves creation, modification, or possession of false documents to be used in fraudulent schemes. It entails misrepresentation to achieve an illegal or felonious goal.
Phishing, for one, incorporates some form of forgery as it attempts to deceive people. A forged website or login interface, for example, makes victims believe that they are using an official website, so they end up compromising their private information. Fake news and propaganda used 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 simple acts of creating or modifying documents, web pages, or entire websites to defraud others. It also comes in a more sophisticated form, as demonstrated by cross-site request forgery attacks.
What is cross-site request forgery?
Also referred to as one-click attacks or session riding, cross-site request forgery is a method of exploiting 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 the reputation of a brand.
How are CSRF attacks undertaken?
Usually, cross-site request forgery attacks are conducted with the aid of 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 succeeds in making a web browser execute a command because the user (victim) is logged in to a web application or account at the time the button or link was clicked. This means the user unwittingly sends a request (after clicking on the link) while authenticated by the application they are using, 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 will be used by the potential victims. They need to devise ways to modify requests that appear as legitimate and unsuspicious as possible. 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 the modification of 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” here 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 be using 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 same GET string for file transfers as above) clicks on the link, it results in the execution of a fund transfer command.
Take 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 they are 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 in insecure platforms. Additionally, it’s not a good idea 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 with the use of tokens and custom rules.
Random tokens can be generated whenever a session request is made to make sure 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 are not allowed to reach an application.
Another way to prevent CSRF attacks is double the submission of cookies. This method also makes use of 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.
The use of tokens, unfortunately, is not a foolproof solution against CSRF. Tokens can be exposed to sniffers at various points. They can be extracted from the HTTP log files, browser history, as well as network appliances if the site being secured by the tokens links to an external URL.
A more effective solution against cross-site request forgery is the use of custom rules. There is no all-encompassing solution to address all kinds of such attacks because they are highly individual in nature. That’s why it’s more effective to set specific rules that plug vulnerabilities in the way requests are handled. This is not going to be an easy task. The security team needs to study their setup meticulously to spot security weaknesses and introduce the protective rules.
Some security firms, however, offer solutions that make it easy to prevent CSRF attacks using custom rules. A proprietary solution called IncapRules, for example, 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. As such, the key to addressing them is to prevent unwitting application authorizations from legitimizing requests or creating the impression of legitimacy. It’s important to view forgery-based threats individually to set up defenses that address unique schemes while ensuring that the “human weakness” factor is minimized.