A CSRF attack forces a logged-on victim's browser to send a request to a vulnerable web application, which performs the chosen action on behalf of the victim - without their knowledge or permission. Because a CSRF attack piggybacks on the unwitting victim's online activity, it's also called 'session riding'.
CSRF vulnerabilities can lead to severe attacks, including full account takeovers. For example, email addresses can be changed, passwords reset, funds transferred, products purchased, and shipping addresses altered.
If the compromised user has admin rights for the application, the attacker can even take complete control of all the app's data and functionality.
How does a Cross Site Request Forgery attack work?
A CSRF relies on the user's browser automatically providing their credentials when accessing a site. Credentials can include the user's session cookie, basic authentication credentials, IP address, and Windows domain credentials – all or any of which can make the login process more convenient.
However, providing these credentials makes it easier for an attacker to impersonate the user. Once a user meets the site's identity verification requirements, the site can't spot the difference between a legitimate user request and a forged one. So from that point on, the attacker can do whatever they like using the victim's identity.
Attacks start with an email, chat message, SMS, or even a post in a discussion group containing a malicious link or a link to a website the user is familiar with. A visit to the site triggers a request, which, as it supposedly comes from an authenticated user, is carried out in the background without user awareness.
The 2020 Verizon Data Breach Investigations Report suggests that stolen and reused credentials are implicated in 80% of hacking-related breaches.
High profile examples of Cross Site Request Forgery attacks and exposed vulnerabilities
A 2019 audit of Meetup, the community-building events platform, uncovered "serious cross-site scripting (XSS) and cross-site request forgery (CSRF) vulnerabilities". These security issues put the platform's 44 million enrolled members at risk of both data theft and monetary loss.
Used and loved by over 1 billion members, social media platform Tik Tok likewise discovered CSRF vulnerabilities in 2020, leading to one-click account takeovers if exploited.
A respected bug hunter (aka security researcher) also revealed that five large hosting providers (Bluehost, DreamHost, Hostgator, OVH and iPage) all had serious vulnerabilities, including CSRF flaws that would have allowed account takeovers. All are now fixed.
Common CSRF vulnerability examples
The NVD (National Vulnerability Database), a US government site, lists these CSRF examples:
- The profile page does not have a CSRF token present when changing the account's email address
- Drupal: CVE-2007-6752: Cross-site request forgery (CSRF) vulnerability
- WordPress: CVE-2020-28040: Cross-Site Request Forgery (CSRF) / WordPress before 5.5.2 allows CSRF attacks that change a theme's background image.
- WordPress: CVE-2014-9033 and CVE-2015-5731: Cross-site request forgery (CSRF) vulnerability in 'wp-login.php'
- WordPress: CVE-2016-6635, CVE-2016-6897, CVE-2017-5489, CVE-2017-5492, CVE-2017-6819, CVE-2017-9064, CVE-2019-17675, and CVE-2019-9787: Cross-Site Request Forgery (CSRF)
- WordPress: CVE-2016-6635: Cross-site request forgery (CSRF) in script compression options
- WordPress: CVE-2016-6897: Cross-site request forgery (CSRF) in the wp_ajax_update_plugin function of 'wp-admin/includes/ajax-actions.php'
- WordPress: CVE-2017-5489: Cross-site request forgery (CSRF) bypass via uploading a Flash file
- WordPress: CVE-2017-5492: Cross-site request forgery (CSRF) in the accessibility mode of widget editing
- WordPress: CVE-2017-6819: Cross-site request forgery (CSRF) in Press This, leading to excessive use of server resources
- WordPress: CVE-2014-9033: Cross-Site Request Forgery (CSRF) // description: There is a CSRF vulnerability on the password reset functionality, allowing an attacker to trigger a password reset via CSRF. (This does not allow them to set the password themselves).
CSRF mitigation techniques
First, what issues need to occur to allow a CSRF attack?
1. The HTML elements are allowed to make cross-origin requests
2. Then HTML elements send all cookies with requests
3. The cookies authenticate the user to the website
Technique 1 - Token-based mitigation: A CSRF token is a unique, unpredictable secret value generated by a server-side application. The token is sent to the user for inclusion in any subsequent HTTP requests they make. If the token is missing from the further request, the server rejects the interaction.
Because an attacker does not know the random value in the token, they cannot create forged requests to the web server.
Technique 2 – Same-Site cookies: SameSite cookies allow developers to define where the cookie can be sent. For example, they can stop them from being shared to a third-party site, which helps mitigate the risk of cross-origin information leakage, and provides (some) protection against cross-site request forgery attacks.
A developer can choose from three cookie values – none, lax or strict. Each setting aims to achieve a different balance between security and usability. Contrary to the name, the 'lax' control stops the cookie from being sent outside the originating domain.
The browser respects the Same-Site cookie setting, and no longer sends the cookie on any requests from attackers site. This means that a request will not be authenticated, and the target application will not perform any action.
How RedShield helps mitigate CSRF attacks
RedShield's baseline security service prevents many known attacks against CSRF vulnerabilities, starting with setting SameSite=Lax cookie flag on authentication cookies.
Advanced shields can be deployed to further strengthen protection against CSRF if necessary. For example, we can add SMS-based or Time-Based One Time Password (TOTP) Second Factor Authentication (2FA) to your entire application stack.
