Cross Site Request Forgery (CSRF)
What is Cross Site Request Forgery (CSRF)?
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?
In such cases where the user victim has administrative authority, an 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 from 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:
- data theft
- spread worms on social media
- falsely manipulate results of online surveys
- Install malware on mobile devices such as smartphones
What is the Cross Site Request Forgery Vulnerability?
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?
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 an 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.