Cross-site request forgery (CSRF) attacks are common web application vulnerabilities that take advantage of the trust a website has already granted a user and their browser. In a CSRF attack, an attacker typically uses social engineering techniques to manipulate an authenticated user into executing malicious actions without their awareness or consent. Simply by clicking on a legitimate-seeming link in an email or chat message, the user may unwittingly give an attacker the ability to co-opt their identity and access privileges.
From that point on, the attacker can impersonate their victim and use their account to perform anything from a harmless prank on an unsuspecting user to an illicit money transfer that drains the victim’s bank account. If the targeted user is a web administrator with broad access privileges, a CSRF attack can compromise the entire web application.
When successful, a CSRF attack can be harmful both to the business operating the site and the user who has accessed it. Such exploits can negatively impact client relationships, damage customer confidence, and result in instances of fraud or theft of financial resources. CSRF attacks have been employed against major services and sites such as Gmail and Facebook, among others.
CSRF is also known by a number of other names, including XSRF, "sea surf," session riding, cross-site reference forgery, and hostile linking. Microsoft refers to this type of attack as a one-click attack in its threat modeling process and many places in its online documentation. CSRF is considered a flaw under the A5 category in the OWASP Top 10.
When users attempt to access a site, their browser often automatically includes any credentials associated with the site along with their request so that the login process is more convenient. These credentials can include the user's session cookie, basic authentication credentials, IP address, Windows domain credentials, and so on. Once the user is authenticated to the site, however, the site has no way to distinguish a forged request from a legitimate user request.
CSRF attacks usually target functions that cause a state change on the server but can also be used to access sensitive data. Upon performing a successful CSRF attack on a victim’s account, a malicious actor can initiate a transfer of funds, purchase an item, place a product in a shopping cart, alter account information such as a shipping address, change a password, or use any other function that is available on the vulnerable website.
In some cases, it is possible to store a CSRF attack directly on the vulnerable site itself. Such vulnerabilities are called stored CSRF flaws. An attacker can create a stored CSRF flaw simply by storing an IMG or IFRAME tag in a field that accepts HTML, or by conducting a more complex cross-site scripting (XSS) attack. The Samy MySpace worm is a notable case in which XSS techniques compromised a site on a mass scale.
If an attacker is able to store a CSRF attack on the target site, the impact can be far more severe. In this case, since the page containing the malicious payload is now contained within the site and therefore appears entirely legitimate, the victim is more likely to view and trust the page containing the attack than a random page on the internet. And since the victim has already been authenticated to the site in this scenario, the attacker will have an even better opportunity to target them with a CSRF attack.
There are several methods for strengthening your web application security program so that you will be less vulnerable to a potential CSRF attack. As with other web application security measures, the best defense involves regularly scanning and testing the security of your web applications:
If your web application does not currently have CSRF protection, it could be vulnerable to this form of attack. Web application security tools can help you quickly determine whether such a vulnerability exists within your web application and provide you with steps to remediate the issue.
You can help reduce the likelihood of a CSRF attack by having advanced validation techniques in place for anyone who may visit pages on your site, especially if you are operating a social media or community site. CSRF tokens, which are sometimes also referred to as anti-CSRF tokens since they are intended to deflect CSRF attacks, are one such example. Typically comprised of a large, random string of numbers that is unique to both the individual session and the user, they make it much harder for attackers to guess the proper token required to create a valid request.
By implementing CSRF tokens in your form submissions and side-effect URLs, you can better ensure that every form submission or request is tied to an authenticated user and shielded from a potential CSRF attack. In cases involving highly sensitive operations, OWASP notes that you may also want to consider implementing a user interaction based protection (either re-authentication/one-time token along) along with token based mitigation techniques.
Even after you have successfully resolved a vulnerability in a web application that would have enabled a CSRF attack, it is still possible for vulnerabilities to arise in the future as the application is updated and changes are made to its code. For this reason, it’s wise to continually scan and test your web applications for any security vulnerabilities they may harbor, including vulnerabilities associated with CSRF attacks, using web application security tools.