CSRF Exploitation: Forcing Unauthorized Actions Without the User's Knowledge

To understand how CSRF works, it is crucial to examine the anatomy of an HTTP request and the default behavior of web browsers regarding cookies.

When a user logs into an application (e.g., bank.com), the server validates their credentials and sets a session cookie in the user's browser. From that moment on, whenever the browser makes an HTTP request to bank.com—whether it is to view a balance or initiate a transfer—it automatically includes that session cookie in the HTTP headers. The server receives the request, inspects the cookie, verifies the session, and processes the action.

A CSRF attack exploits this exact, intended behavior. The attack relies on three essential prerequisites being met simultaneously:

1. A Relevant Action: There must be an action within the application that the attacker wants to induce. This action must be state-changing, meaning it alters data on the server. Examples include updating an account's password, changing an email address, assigning administrative privileges, or transferring money.
2. Cookie-Based Session Handling: The application must rely solely on HTTP cookies to track the user's session and authenticate their requests. If the application requires a dynamic token in the HTTP header (like a Bearer token in an Authorization header) that the browser does not automatically send, traditional CSRF is not possible.
3. No Unpredictable Request Parameters: The requests that perform the action must not contain any parameters whose values the attacker cannot guess. For example, if changing a password requires the user to input their current password (which the attacker does not know), the CSRF attack will fail.

If all three conditions are met, the application is vulnerable. The attacker's goal is to craft a malicious web page that generates an HTTP request identical to the legitimate request the application expects.

Crafting the Payload

Let us assume that bank.com has a vulnerability in its money transfer function. The application uses a simple HTTP GET request to initiate a transfer:

GET /transfer?amount=1000&destinationAccount=Attacker123 HTTP/1.1
Host: bank.com
Cookie: session_id=abc123xyz

An attacker can easily exploit this by hosting an invisible image tag on a malicious website they control:

<img src="https://bank.com/transfer?amount=1000&destinationAccount=Attacker123" width="0" height="0">

When the victim, who is already logged into bank.com in another tab, visits the attacker's website, the victim's browser attempts to load the image. To do so, the browser automatically sends an HTTP GET request to the URL specified in the src attribute. Crucially, because the destination is bank.com, the browser automatically attaches the victim's valid session_id cookie.

The bank's server receives the request, sees a valid session cookie, processes the transaction, and transfers the funds to the attacker. The victim sees nothing but a broken image icon (or nothing at all, if hidden), completely unaware that their account has been drained.

While the example above uses a GET request, CSRF is equally viable against POST requests. If the transfer function requires a POST request, the attacker can use a hidden HTML form and a snippet of JavaScript to automatically submit it when the page loads:

<form action="https://bank.com/transfer" method="POST" id="csrf-form">
    <input type="hidden" name="amount" value="1000">
    <input type="hidden" name="destinationAccount" value="Attacker123">
</form>
<script>
    document.getElementById('csrf-form').submit();
</script>

Again, the browser sends the POST request, automatically appending the victim's cookies, and the server blindly executes the malicious action.

CSRF attacks are highly versatile and can be tailored to compromise various types of systems, from social media platforms to corporate internal networks.

Account Hijacking via Email Alteration

One of the most common and devastating uses of CSRF is account hijacking. Many web applications allow users to update their profile information, including their email address. If this endpoint is vulnerable to CSRF, an attacker can force the victim to change their account's associated email address to one controlled by the attacker.

Once the email address is changed, the attacker simply navigates to the application's login page, clicks "Forgot Password," and requests a password reset link. The reset link is sent to the attacker's email address, allowing them to lock the victim out and take complete control of the account.

Exploiting IoT and Internal Network Devices

CSRF is particularly dangerous when targeting internal network devices that users frequently leave authenticated, such as home routers or corporate intranets.

Home routers often use default IP addresses (like 192.168.1.1) and simple, cookie-based authentication. An attacker can craft a CSRF payload targeting a router's configuration page to change its DNS settings. If a user visits a malicious website while authenticated to their router, the router's DNS settings are silently updated to point to a rogue DNS server controlled by the attacker. From that point on, whenever the victim tries to visit a legitimate website like their bank, the rogue DNS server redirects them to a highly convincing phishing page, leading to massive credential theft. This technique, known as DNS hijacking via CSRF, is incredibly difficult for an average user to detect.

CSRF is often confused with Cross-Site Scripting (XSS), but the two vulnerabilities operate on fundamentally different principles and require different defenses.

In an XSS attack, the attacker injects malicious JavaScript into a trusted website. The code executes within the context of the trusted site in the victim's browser. XSS allows the attacker to read the victim's cookies, access the DOM, and rewrite the page content. XSS represents a complete compromise of the browser's trust in the site.

In a CSRF attack, the malicious code executes on a different, untrusted website (the attacker's site). The attacker cannot read the victim's cookies or see the server's response. It is a "blind" attack. The attacker merely forces the browser to send a request. CSRF exploits the server's blind trust in the browser's automatic credential submission.

It is critical to note that if an application has an XSS vulnerability, almost all CSRF defenses can be bypassed. An attacker can use XSS to read anti-CSRF tokens directly from the page and construct the forged requests dynamically within the trusted domain. Therefore, mitigating XSS is a prerequisite for effective CSRF defense.

Securing an application against CSRF requires disrupting one of the three prerequisites required for the attack to succeed. Because we cannot stop the browser from sending cookies, and we cannot eliminate state-changing actions, developers must introduce unpredictable parameters into the request that an attacker cannot guess.

The Synchronizer Token Pattern (Anti-CSRF Tokens)

The most robust and historically proven defense against CSRF is the Synchronizer Token Pattern. This involves generating a unique, cryptographically strong, and unpredictable token on the server side for every user session.

When the server renders an HTML page containing a form, it includes this unique token as a hidden input field.

<form action="/update-profile" method="POST">
    <input type="hidden" name="csrf_token" value="8f2a7b...e91c">
    <input type="text" name="email" value="[email protected]">
    <button type="submit">Update</button>
</form>

When the user submits the form, the browser sends the POST data, including the hidden csrf_token, along with the session cookie. Upon receiving the request, the server compares the token provided in the form data with the token stored in the user's session on the server. If they match, the request is processed. If they do not match, or if the token is missing, the server rejects the request.

Because an attacker cannot read data from the target domain due to the Same-Origin Policy, they cannot predict or extract the correct CSRF token to include in their forged HTML form. The attack fails.

These tokens should be unique per user session, highly unpredictable (generated using a secure random number generator), and never transmitted in HTTP GET requests, as GET parameters are often logged in browser history and server access logs, potentially leaking the token.

The SameSite Cookie Attribute

A more modern and highly effective defense mechanism that operates at the browser level is the SameSite cookie attribute. This attribute instructs the browser on whether to attach cookies to cross-site requests. It has three possible values: Strict, Lax, and None.

• SameSite=Strict: This is the most secure setting. The browser will only send the cookie if the request originates from the same site that set the cookie. If a user clicks a link to the application from an external website or an email, the cookie will not be sent, and the user will appear unauthenticated. This completely eliminates CSRF, but it can severely impact user experience by forcing users to log in again when navigating from external links.
• SameSite=Lax: This is a balanced approach and is now the default setting in modern browsers. With Lax, the browser will not send cookies for cross-site POST requests (which are typically used for state-changing actions). However, it will send the cookie for "safe" top-level navigations, such as clicking a standard hyperlink (a GET request). This prevents traditional CSRF attacks via hidden forms while maintaining a smooth user experience.
• SameSite=None: The browser will send the cookie with all requests, including cross-site POST requests. This setting essentially disables the protection and must only be used in conjunction with the Secure attribute (requiring HTTPS), typically for third-party cookies used in widgets or embedded iframes.

Implementing SameSite=Lax or Strict on session cookies provides a massive baseline of defense against CSRF. However, it should be used as a layer in a defense-in-depth strategy, not as a complete replacement for Anti-CSRF tokens, as legacy browsers may not support the attribute.

Double Submit Cookie Pattern

In stateless architectures where maintaining server-side sessions (to store CSRF tokens) is problematic, the Double Submit Cookie pattern is a viable alternative.

When a user authenticates, the server generates a cryptographically strong, random token. The server sends this token to the client twice: once in a cookie (separate from the session cookie), and once as a hidden field in the HTML or injected into the DOM for use by JavaScript.

When the client makes a state-changing request, it must include the token in both the cookie and a request parameter (or a custom HTTP header). The server simply checks if the token in the cookie matches the token in the parameter.

Because of the Same-Origin Policy, an attacker cannot read or modify the token cookie set by the target domain. Therefore, they cannot inject the matching token into the forged request body. The server will see a mismatch and reject the request.

Custom Request Headers

For applications that rely heavily on AJAX or single-page application (SPA) frameworks (like React or Angular) communicating with a REST API, using custom request headers is a highly effective defense.

Browsers' Same-Origin Policy and Cross-Origin Resource Sharing (CORS) rules strictly prohibit cross-origin requests from setting custom HTTP headers without explicit permission (via a CORS preflight request).

A defense strategy involves requiring a custom header, such as X-Requested-With: XMLHttpRequest, on all state-changing API requests. Because an attacker's malicious website cannot force the victim's browser to append this custom header to a cross-origin request, the API server can simply reject any request missing the header. This approach provides robust protection without the need to manage unique tokens.