Cross Site Request Forgery (CSRF)

What is Cross Site Request Forgery (CSRF)?

Cross site request forgery (CSRF) is a type of attack where a web browser is tricked or driven to execute unexpected and unwanted functions on a website application where the user is logged in.

In many cases, CSRF attacks are initiated through social engineering, such as bogus emails that entice victims to select a link that in reality is a forged request to another site or server. The request leverages authentication that has already been established by the user with that site and the session is treated as a legitimate request to the application.

Cross site request forgery vulnerability is common and damaging enough that the OWASP community has placed these attacks on the top 10 list of web application vulnerabilities.

What is a cross site request forgery example?

CSRF attackers have to analyze website applications carefully to properly design their forged requests. Additionally, they typically design their attacks such that their intrusions go unnoticed by the user. A common ploy by CSRF attackers is to capture legitimate application activity such as financial funds transfers, and then modify them substituting the transfer information to their accounts.

In such cases where the user victim has administrative authority, a CSRF attacker could potentially take charge of the entire website application.

How and why are CSRF attacks performed?

Clever CSRF hackers can embed links into legitimate-looking webpages that cause unintended actions. In the case of a balance transfer, the link could be emailed to a list of bank customers, appearing to be totally legitimate.

If the unsuspecting victim is already authenticated to the bank website and clicks the link, the request forgery will take the action of transferring the amount in the forged request to the attacker’s account. Since the user’s existing session is used, this will appear as a legitimate request to the banking application.

If the targeted website includes functions, such as password changes or email address updates, the attacker could effectively take over the user’s account entirely, which is a huge problem for both the user and website owner.

Another use for CSRF attacks that is less problematic includes sending a link that will access a social media site to up-vote videos or similar, less-invasive actions.

CSRF attacks have been used quite creatively for numerous purposes:

1. data theft

2. spread worms on social media

3. falsely manipulate results of online surveys

4. Install malware on mobile devices such as smartphones

What is the Cross Site Request Forgery Vulnerability?

Cross site request forgery can result in various levels of damage, depending on the website application, level of data sensitivity, and user authorization level. The attacker can essentially perform any action, disguised as the victim. Therefore, these actions could be particularly impactful, if the user has administrative privileges to the application. This makes tracking the damage nearly impossible since it appears on the server side and shows that the actions were performed by the user, with legitimate credentials.

Damage could include data theft, corruption, or deletion of data and entire databases, or even installing or uninstalling software. Having administrative access to the application could also allow the attacker to launch other attacks or plant malicious software that could generate damage in the future.

Reasons for implementing protection against CSRF become apparent very quickly. A key attribute of CSRF attacks is that they can often be introduced from essentially any HTML construct or tag, including links, object or embed tags, image tags, and other attributes of background images. With access to a variety of HTML attributes, attackers have a broad pallet to work from.

How to prevent CSRF?

Protecting website applications from CSRF attacks can be addressed by implementing the use of tokens to provide CSRF protection.

CSRF tokens can be utilized to synchronize the client and server-side of the website. Once the session has been initiated, the server and client have set tokenization between them for every action. If a CSRF attack were to occur, the validation of the token values would be checked, found to be a mismatch, and the action would be rejected.

Where maximum protection is desired or necessary, tokens can be generated for each form and compared for validity. Taken to extremes, tokens can be generated for each request. Consideration must be given to the user experience when going to that level of tokenization since users who have multiple tabs will find that requests on outdated tabs no longer validate, and using the back button will break the session flow.

Although anti-CSRF token protection is the best safeguard against CSRF attacks, for web applications that have a vulnerability to cross-site scripting (XSS) attacks, the hacker can execute a script that exposes the new form token which defeats the protection offered by the CSRF token. XSS is a form of injection where malicious scripts can be injected into trusted web applications.

To provide the most effective web application security, all vulnerabilities should be considered and evaluated.