CSRF Vulnerability Testing and Anti-CSRF Token Analysis

Hello! Welcome back.

In our last lesson, we explored a powerful attack chain where you used a Cross-Site Scripting (XSS) vulnerability to bypass anti-CSRF defenses. By executing JavaScript on the same origin, your script was able to read a valid CSRF token from the page and use it to forge a request, leading to account takeover.

That exercise naturally raises the question: what if there's no XSS vulnerability? Can we still find and exploit Cross-Site Request Forgery? The answer is a resounding yes. Today, we shift our focus to CSRF as a standalone vulnerability. You will learn how to identify the conditions that make CSRF possible and how to bypass weak implementations of its primary defense mechanism, the anti-CSRF token.

Your learning outcome for this lesson is to test for Cross-Site Request Forgery (CSRF) vulnerabilities and analyze the effectiveness of anti-CSRF tokens.

1. The Anatomy of a CSRF Vulnerability

As a brief refresher, Cross-Site Request Forgery is an attack that tricks an authenticated user's browser into sending an unwanted, state-changing request to a web application. The attack works because browsers automatically include cookies (including session cookies) in requests to a given domain, regardless of where the request was initiated.

For a CSRF attack to be successful, a few key conditions must be met. The Intigriti blog provides a clear breakdown of these prerequisites.

CSRF: A Complete Guide to Exploiting Advanced CSRF Vulnerabilities

Let's read a short section from the article 'CSRF: A Complete Guide to Exploiting Advanced CSRF Vulnerabilities' by Intigriti. It perfectly outlines the three conditions that make an endpoint vulnerable to CSRF.

Read the section titled 'When is it vulnerable to CSRF?'. Pay close attention to the three conditions it describes: Privileged action: The request must perform a sensitive action. Session handling: The session must be managed via cookies, and the SameSite attribute must be permissive (None or Lax). No unpredictable values: The request must not contain any unpredictable, secret values that an attacker can't guess (like a strong anti-CSRF token).

The second point, concerning the SameSite cookie attribute, is a crucial modern defense. It instructs the browser on whether to send cookies with cross-site requests.

SameSite=Strict: Cookies are never sent on cross-site requests. Highly secure but can break functionality.
SameSite=Lax: Cookies are sent on cross-site requests only for top-level navigations using "safe" HTTP methods (like GET). This is the default in most modern browsers.
SameSite=None: Cookies are sent on all cross-site requests. For this to work, the Secure attribute must also be set.

As a bug bounty hunter, analyzing the SameSite policy of session cookies is one of your first steps when assessing a target for CSRF.

2. Basic CSRF: Exploitation without Defenses

Let's start with the simplest case: a sensitive function protected by a session cookie but with no anti-CSRF token. This is the classic CSRF scenario. Your job is to create a Proof of Concept (PoC) that demonstrates the vulnerability. Burp Suite makes this incredibly easy.

The following video demonstrates this exact scenario in a lab environment.

Uncle Rat's CSRF Bug Bounty Methodology Demonstrated

The video 'Uncle Rat's CSRF Bug Bounty Methodology Demonstrated' by The XSS Rat provides a perfect walkthrough of identifying and exploiting a basic CSRF vulnerability. It also shows the practical skill of generating a PoC in Burp Suite.

Watch the demonstration from the beginning to 06:04. Focus on these key steps: Reconnaissance (00:00 - 02:26): The presenter maps the application and identifies the 'change email' functionality. Vulnerability Identification (02:26 - 03:20): In Burp Suite's HTTP history, notice that the POST request to change the email has a session cookie but no anti-CSRF token. This is the indicator of a potential CSRF flaw. PoC Generation (03:20 - 06:04): Observe how Burp's 'Generate CSRF PoC' feature is used to create an HTML form. Pay special attention to the 'include auto-submit script' option—this is critical for creating a high-impact PoC where the victim doesn't need to click anything.

This simple, auto-submitting form is all you need for a basic CSRF report. You host this HTML on your own server, send the link to a "victim," and if they are logged into the target application, their email address will be changed without their interaction.

3. Analyzing and Bypassing Anti-CSRF Tokens

Most modern applications do implement anti-CSRF tokens. However, the implementation is often flawed. Your job as a tester is to find these flaws.

The flowchart below provides an excellent mental model for a CSRF testing workflow. It walks you through checking for tokens, SameSite policies, and other factors.

CSRF Exploitation Testing Flowchart — This flowchart from Intigriti outlines a systematic process for CSRF testing. It starts with identifying a state-changing request and guides you through checking for anti-CSRF tokens and other defenses.

As the flowchart suggests, when you encounter an anti-CSRF token, your next step is to test its validation. The PortSwigger Web Security Academy provides the definitive guide on how to break weak token implementations.

Bypassing CSRF token validation

This article from PortSwigger is essential reading. It details the most common ways that anti-CSRF token validation can fail, giving you a checklist of things to try.

Read the section 'Common flaws in CSRF token validation'. You don't need to memorize every detail, but understand the core idea behind each bypass technique: Changing the request method (e.g., from POST to GET). Removing the token parameter entirely. Using a token from a different user session (if the token isn't tied to the session). Bypassing 'double submit' cookie defenses.

Let's see one of these techniques in action. One of the most common and easiest bypasses to test is changing the request method. Some applications only validate the token on POST requests, completely ignoring it if you submit the same parameters in a GET request.

Uncle Rat's CSRF Bug Bounty Methodology Demonstrated

Let's return to 'The XSS Rat' video. The second half demonstrates exactly how to bypass a CSRF token that is only validated for POST requests.

Watch the segment from 06:04 to 09:10. Observe how the presenter: Confirms Token Validation (07:30 - 08:15): First, they confirm the token is being validated by changing its value and omitting it, which correctly results in an error. Changes the Request Method (08:15 - 08:45): In Burp Repeater, they right-click the request and choose 'Change request method'. This automatically moves the parameters from the POST body to the URL. Bypasses Validation (08:45 - 09:10): With the request method changed to GET, they can now remove the CSRF token parameter entirely, and the request succeeds. This is a clear bypass.

Test your understanding!

You are testing an application's password change function. You log in with two different accounts in two different browsers: attacker_acct and victim_acct.

You capture the password change request for attacker_acct and note its CSRF token. You then craft a CSRF PoC to change the password for victim_acct, but you use the token from attacker_acct. The attack works.

Which vulnerability from the PortSwigger article does this demonstrate?

Show answer

This demonstrates that the CSRF token is not tied to the user session. The application accepts any valid token it has issued, regardless of which user it was issued to. This is a critical flaw that completely undermines the protection.

4. CSRF in 2024: Is It Still Relevant?

With modern browsers defaulting to SameSite=Lax, many classic CSRF attacks are no longer possible. This has led some to believe CSRF is a "dead" vulnerability. This is incorrect. As a bug bounty hunter, knowing the edge cases and modern bypass techniques is what will earn you bounties.

This final video dives into real-world bug bounty reports to show how CSRF is still being found and rewarded today.

CSRF - how to find it in 2024? CSRF bug bounty case study

The channel 'Bug Bounty Reports Explained' created an excellent case study on modern CSRF. This will give you the advanced knowledge needed to find these bugs in the wild.

Watch the following key segments. The presenter speaks quickly, so feel free to pause and re-watch. GET-based CSRF (00:44 - 02:45): Pay attention to the idea that a GET request might not perform a direct action but could trigger client-side JavaScript that does perform a state-changing POST request, effectively bypassing SameSite=Lax. The 2-Minute Attack Window (11:35 - 14:06): This is a critical, subtle point. For two minutes after a cookie is set, Chrome does not apply the Lax policy. If you can force a victim's cookie to be refreshed, you can open this window to perform a CSRF attack. SameSite=None (as mentioned in the summary at 14:06 - 15:09): Always look for sensitive cookies explicitly set with SameSite=None. This is often done to support features like embedded content (e.g., YouTube videos) and is a direct invitation for CSRF.

Conclusion

You've now taken a deep dive into CSRF, moving from the theory of the attack to the practical steps of bypassing its defenses. This is a fundamental skill for any web penetration tester or bug bounty hunter.

Key Takeaways:

Conditions are Key: A CSRF vulnerability requires a privileged action, session-based authentication (with a permissive SameSite policy), and the absence of a strong, unpredictable token.
Tokens Can Be Flawed: Never assume a CSRF token provides complete protection. Always test for common validation bypasses, such as changing the request method, removing the token, or checking if it's tied to the user session.
SameSite is the Modern Battleground: While SameSite=Lax has mitigated many attacks, it is not a silver bullet. Understanding its weaknesses, like the two-minute attack window or how it can be bypassed with clever GET requests, is essential for finding modern CSRF bugs.
Tooling is Your Friend: Use Burp Suite to generate CSRF PoCs quickly and Repeater to manually test for token validation flaws.

Next Lesson Preview:
In our final lesson of this module, we'll explore another client-side vulnerability that leverages user interaction in a deceptive way: Clickjacking. You will learn how to identify and demonstrate the impact of clickjacking vulnerabilities, where a user is tricked into clicking something different from what they perceive.