Cloud and Data SecurityCross-Site Forgery — Web-based Application Security, Part 2
Cross-site forgery (CSRF) is a malicious technique designed to take advantage of unsuspecting users who are actively logged into web applications. Learn more about this threat to your data and how to safeguard against it.
By
Brian Rutledge
4 minute read
With the pervasiveness of an organization, large or small, having a digital presence, web-based application security has been gaining importance. edgescan’s Vulnerability Stats Report 2019 finds that even though application vulnerabilities form 19% of vulnerabilities in enterprise IT systems (network vulnerabilities account for the remaining 81%), application vulnerabilities are either high or critical risk, compared to just 2% of network vulnerabilities. Consequently, understanding, detecting and preventing these vulnerabilities is central to securing your IT systems. In the second part of our series on web-based Application Security, we analyze another critical vulnerability – Cross Site Forgery (Read Part 1 on the Open Redirection Vulnerability).## Understanding the Cross-Site Forgery Vulnerability
OWASP describes a Cross-Site Request Forgery (CSRF), also known as XSRF, Sea Surf or Session Riding as follows, “Cross-Site Request Forgery is an attack that forces an end user to execute unwanted actions on a web application in which they’re currently authenticated.”
Using CSRF, a hacker can forge a request from a legitimate website to the unsuspecting logged in user. By sending this forged link via email or chat, an attacker can trick the users of a web application into executing actions of the attacker’s choosing. For example, the malicious request can take the form of an unauthorized fund transfer, password change, or unintended purchase. The success of the attack hinges on the user being logged on to the website/app. The extent of the attack is based on the role of the user – for a normal user, the attack is limited to the user, but if the victim is an admin, CSRF can compromise the entire web application.
In Action: Cross-Site Forgery
Consider that you get an email from mybank. It has a 1×1 tiny image pixel with the code below.
If you’re logged into your mybank account and your browser loads images, it will lead to a bank transfer of $100 into the hacker’s account, without any visible indication such as the link opening in a new window.
This is an example of using CSRF to exploit mybank.com’s GET request to transfer parameters and execute actions. Similarly, other HTTP requests such as POST, PUT or DELETE can also be hacked.
There have been more than a few prominent instances of cross-site forgery impacting even seasoned tech giants. Last October, Facebook admitted to a bug that gave third-party apps access to the photos of over 6.8 million users. Security researchers put it down to a CSRF hack which, “allowed information to cross over domains — essentially meaning that if a user visits a particular website, an attacker can open Facebook and can collect information about the user and their friends”. This meant that if you had logged into Facebook, the bug could be exploited in many ways. From obtaining personal information about your friends, likes and interests to sell to prospective advertisers, and stealing photos from your timeline to using it in more sinister ways like Facebook’s Cambridge Analytica scandal demonstrated.
Preventing the Cross-Site Forgery Vulnerability
From a user’s perspective, best practices include logging off web applications, not allowing browsers to remember passwords, auto-download images, securing usernames and passwords, etc.
For web apps and sites, these are the two prevalent ways of preventing CSRF hacks:
Anti-CSRF Tokens
The most common way of preventing a CSRF vulnerability is Token Based Mitigation, known as anti-CSRF or synchronizer tokens. It is a cryptographically secure token added as a hidden field on forms. The anti-CSRF token is then included in any authenticated state-changing request that requires a cookie. The web app only accepts the request if the token is validated. As the token is in a hidden field and is randomly generated every time the page is served, it secures the web app against CSRF attacks.
Same-Site Cookies
CSRF attacks work because they exploit the fact that when website A makes a request to website B, the cookies belonging to website A are appended to it. To prevent that, the Google Chrome team introduced the concept of same-site cookies. A new attribute was added to the Set-Cookie header to flag cookies from the same origin. Thus only requests being made from the origin related to the cookie, and not cross-domain, are accepted.
For further ways to prevent CSRF attacks, here is OWASP’s complete list.
Read More About Cloud & Data Security