What is Cross Site Request Forgery (CSRF)?

What is a CSRF attack?

Cross-site request forgery (CSRF), also referred to as Session Riding or XSRF, is an attack vector that exploits the trust a website has in an authenticated user’s browser, tricking it into executing unwanted actions. These attacks typically involve malicious social engineering, such as emails or links, that deceive the user into sending forged requests to the server. Since the targeted user is authenticated by their application during the attack, it becomes impossible to differentiate between legitimate and forged requests.

CSRF attacks are particularly insidious because they work behind the scenes, focusing on state changes rather than initial data theft. The unsuspecting user may inadvertently execute malicious actions simply by clicking on a seemingly legitimate link, allowing the attacker to impersonate the user and access their privileges. If the targeted user is a web administrator, the entire web application could be compromised.

Successful CSRF attacks can result in severe consequences, such as unauthorized fund transfers, changed passwords, and stolen data, impacting both businesses and users.

Contents

How does Cross Site Request Forgery work?

For a CSRF attack to occur, three conditions must be present:

A request that can be performed over HTTP: The majority of interactive websites meet this first condition. This could be a privileged action (like altering permissions for other users) or any action related to user-specific data (like updating the user’s password).
Session handling via cookies: To execute the action, one or more HTTP requests are needed, and the application solely depends on session cookies to recognize the user initiating the requests. No other method is available for session tracking or user request validation.
Predictable request parameters: The structure of the request needs to be predictable for the attacker to successfully fabricate it, since the malicious actor relies on the user to take an action, without the ability to observe the user’s actions.

Once these three conditions are met, then the attacker needs to deliver their malicious code to the victim’s browser.

Cross Site Request Forgery Example

As an example, consider the following scenario:

Imagine you’re going about your day when an email lands in your inbox. The message claims that a package addressed to you is currently stuck in customs. To resolve the issue, you’re instructed to visit a specified URL.

So, you click on the link, only to be directed to your own website. At the moment, this may not seem unusual or alarming. However, what if a plugin on your website has a CSRF vulnerability that can be exploited simply by visiting a specially crafted URL?

For the sake of illustration, let’s assume that a music plugin you installed on your website has a security flaw. This weakness occurs because the plugin fails to perform adequate security, capability, and intention checks when altering its settings. Consequently, visiting the URL www.yourwebsite[.]com/music/settings?default_user=admin&anyonecanregister instantly enables anyone to register, automatically granting them admin privileges.

In this scenario, an attacker could craft an email that exploits this vulnerability, unknowingly allowing them to gain unauthorized access to your website’s administrative functions. The importance of robust web security measures, such as using CSRF tokens and validating the origin and the intention of requests, cannot be overstated to protect against such attacks.

Note:

Although CSRF is generally associated with cookie-based session handling, it also occurs in other situations where the application automatically adds user credentials to requests, such as HTTP Basic authentication and certificate-based authentication.

What is the difference between CSRF and XSS?

Cross-Site Request Forgery (CSRF) and Cross-site scripting (XSS) attacks share some common traits. Both aim to execute malicious code within the context of a victim’s legitimate web session. However, XSS focuses on injecting malicious code directly into a susceptible page, while CSRF typically relies on social engineering techniques (such as phishing emails) to introduce malicious code on an unrelated page in the victim’s browser.

The distinctions between the two are significant. A malicious XSS script can directly access a page on the targeted site, potentially exposing everything on the page to the attacker, including any anti-CSRF token value. Flawless CSRF defenses offer minimal protection for a site that is vulnerable to XSS.

What is the impact of a CSRF attack?

A successful CSRF attack can have severe consequences for both businesses and users. The impact may include damaged client relationships, unauthorized fund transfers, altered passwords, and even data theft — including stolen session cookies.

Typically, attackers exploiting a CSRF vulnerability trick users into visiting a malicious page or clicking a specially crafted link. This malicious page sends requests through the user’s browser, appearing as a legitimate user action. Once a CSRF vulnerability is exploited, an attacker can force changes to passwords and personal information, as well as access sensitive data.

The specially crafted link relies on a pre-existing CSRF vulnerability to be present on the target website.

The severity of a successful CSRF attack depends on the targeted user’s privileges within the application. If the victim has basic user privileges, the damage may be limited to their account. However, if the victim has an administrator account, a CSRF attack can compromise the entire web application.

Attackers often use social engineering techniques, such as phishing emails with malicious links, to improve their chances of success. When combined with a successful social engineering attack, the impact of a CSRF attack can be significantly amplified.

How to prevent cross-site request forgery

Since CSRFs are highly customized and specific to environmental conditions, one-size-fits all solutions are challenging. However, as a user there are a number of security measures you can take to mitigate the risk of attack.

Security best practices include:

Using strong, unique passwords for your accounts
Logging out of websites when you’re done with your browsing session
Never storing passwords in your web browser

If you are looking protect your web application from CSRF attacks, consider implementing the following security measures.

1. CSRF tokens:

Generate unique, secret, and unpredictable values (known as a CSRF token) on the server-side and share them with the client. When the client performs sensitive actions, like submitting a form, they must include the correct CSRF token in the request. The server then validates before processing the request. If the token is missing or invalid, the server rejects the request. This makes it challenging for an attacker to create a valid request on the victim’s behalf.

2. SameSite cookie attribute:

Utilize the SameSite cookie attribute which dictates when a website’s cookies will be included in requests coming from other sites. Since sensitive actions often require an authenticated session cookie, setting the appropriate SameSite restrictions can help prevent an attacker from triggering these actions from another site.

There are two values for the SameSite attribute: Lax and Strict.

Lax allows top-level navigation
Strict only allows cookies to be sent to its own website without exceptions

3. Referer-based validation:

Some web apps use the HTTP Referer header to defend against CSRF attacks, typically by checking if the request came from the app’s domain. While this method is not as effective as CSRF token validation, it does add an extra layer of security to your environment.

4. Cross-Origin Resource Sharing (CORS):

CORS is a mechanism that allows servers to specify which origins are allowed to access their resources and under which conditions. By implementing cross-origin resource sharing, browsers can prevent unauthorized cross-origin requests, which can help mitigate CSRF attacks.

The way it works is quite simple, when a browser tries to send a request from one origin to another, it will check the CORS header in the response from the server to ensure that that request is allowed If the response from the server doesn’t contain the appropriate CORS headers or the origin of that request is not allowed, the browser itself will block the request.

This is a great step in securing against CSRF attacks directly on the user-level.

Need help blocking attackers?

Our Website Application Firewall (WAF) blocks bad bots, virtually patches known vulnerabilities, and intercepts XSS, RCE, and SQLi attacks before they reach your site.

Sucuri Resource Library

Say on top emerging website security threats with our helpful guides, email, courses, and blog content.

Webinar

Learn how to identify issues if you suspect your WordPress site has been hacked.

Email Course

Join our email series as we offer actionable steps and basic security techniques for WordPress site owners.

Report

Based on our data, the three most commonly infected CMS platforms were WordPress, Joomla! and Magento.