Cross-site request forgery (CSRF) in Cybersecurity - Full Explanation

Introduction

Imagine you are logged into your bank website and then visit another website that tricks your browser into sending a money transfer request without your knowledge. This problem happens because websites trust your browser too much. Cross-site request forgery (CSRF) is the attack that exploits this trust to perform unwanted actions on your behalf.

Explanation

How CSRF Works

CSRF tricks your browser into sending a request to a trusted website where you are already logged in. The attacker creates a fake request that looks normal to the website, so it processes the action as if you made it. This happens because browsers automatically include your login information like cookies with every request.

CSRF exploits the trust a website has in your browser by sending unauthorized requests using your credentials.

Why CSRF is Dangerous

CSRF can cause serious problems like changing your password, transferring money, or posting unwanted messages without your permission. Since the website thinks the request is from you, it performs the action immediately. This can lead to loss of money, data, or control over your account.

CSRF attacks can make websites perform harmful actions without the user's consent.

Common CSRF Protection Methods

Websites use special tokens called CSRF tokens that are unique for each user session and included in forms or requests. When a request comes in, the website checks if the token matches what it expects. If it doesn't, the request is rejected. This stops attackers because they cannot guess or send the correct token.

CSRF tokens help websites verify that requests come from the legitimate user and not an attacker.

Role of SameSite Cookies

SameSite cookies are a browser feature that restricts cookies from being sent with cross-site requests. Setting cookies to SameSite helps prevent CSRF by stopping the browser from including cookies when requests come from other websites. This reduces the chance that an attacker can use your login cookies in a forged request.

SameSite cookies limit cookie sharing across sites, reducing CSRF risks.

Real World Analogy

Imagine you have a trusted assistant who always follows your instructions. One day, a stranger sneaks in and whispers a fake order to your assistant, who then carries it out thinking it came from you. You never gave that order, but the assistant trusted the stranger because they looked like you.

How CSRF Works → The stranger whispering fake orders to your trusted assistant

Why CSRF is Dangerous → The assistant doing harmful tasks you never asked for

Common CSRF Protection Methods → Giving your assistant a secret code word that only you know to confirm orders

Role of SameSite Cookies → Making sure your assistant only listens to you when you are in the same room

Diagram

Diagram

┌───────────────┐       ┌───────────────┐       ┌───────────────┐
│   User's      │       │  Attacker's   │       │  Trusted      │
│  Browser      │──────▶│  Website      │       │  Website      │
│ (Logged in)   │       │ (Malicious)   │       │ (Bank, etc.)  │
└───────────────┘       └───────────────┘       └───────────────┘
        │                      │                      ▲          
        │                      │                      │          
        │                      └───────────────┐      │          
        │                                      │      │          
        └───────────────Forged Request────────┘      │          
                                                   │          
                                        Accepts request as if from user

This diagram shows how the user's browser is tricked by the attacker's website into sending a forged request to the trusted website.

Key Facts

CSRF → An attack that tricks a user's browser into sending unauthorized requests to a trusted website.

CSRF Token → A secret value included in requests to verify they come from the legitimate user.

SameSite Cookie → A cookie setting that restricts cookies from being sent with cross-site requests.

Cookie → Data stored by the browser that helps websites remember who you are.

Common Confusions

CSRF is the same as Cross-site scripting (XSS).

CSRF is the same as Cross-site scripting (XSS). CSRF tricks your browser to send unwanted requests, while XSS injects malicious code into websites to steal data or control the page.

Logging out prevents CSRF attacks.

Logging out prevents CSRF attacks. CSRF attacks require you to be logged in; logging out stops them, but while logged in, protection methods like CSRF tokens are needed.

Summary

CSRF tricks your browser into sending harmful requests to websites where you are logged in without your permission.

Websites protect against CSRF by using secret tokens and cookie settings that verify requests are genuine.

Understanding CSRF helps you recognize why websites ask for extra confirmation before sensitive actions.

Practice

1. What is the main goal of a Cross-site request forgery (CSRF) attack?

easy

A. To encrypt user data for ransom

B. To steal a user's password by phishing

C. To overload a website with traffic causing it to crash

D. To trick a logged-in user into performing unwanted actions on a website

Solution

1. Step 1: Understand CSRF attack purpose

   CSRF attacks aim to make a user unknowingly perform actions they did not intend on a trusted website.

2. Step 2: Compare with other attack types

   Phishing steals passwords, DoS overloads servers, and ransomware encrypts data, which are different from CSRF.

3. Final Answer:

   To trick a logged-in user into performing unwanted actions on a website -> Option D

4. Quick Check:

   CSRF = trick user actions [OK]

Hint: CSRF tricks users into unwanted website actions [OK]

Common Mistakes:

• Confusing CSRF with phishing attacks
• Thinking CSRF steals passwords directly
• Mixing CSRF with denial-of-service attacks

2. Which of the following is a common method to protect a website against CSRF attacks?

easy

A. Blocking all cookies from the browser

B. Encrypting all user passwords with SHA-1

C. Using secret tokens that must be submitted with requests

D. Disabling JavaScript on the website

Solution

1. Step 1: Identify CSRF protection techniques

   Websites use secret tokens (CSRF tokens) that must be included in requests to verify they come from the user intentionally.

2. Step 2: Eliminate unrelated options

   Encrypting passwords, blocking cookies, or disabling JavaScript do not specifically prevent CSRF attacks.

3. Final Answer:

   Using secret tokens that must be submitted with requests -> Option C

4. Quick Check:

   CSRF protection = secret tokens [OK]

Hint: CSRF defense uses secret tokens in requests [OK]

Common Mistakes:

• Thinking password encryption stops CSRF
• Believing blocking cookies prevents CSRF
• Assuming disabling JavaScript is a CSRF fix

3. Consider this scenario: A user is logged into their bank website. An attacker sends a hidden form on another site that submits a money transfer request to the bank without the user's knowledge. Which security measure would stop this CSRF attack?

medium

A. The bank requires a unique CSRF token with each form submission

B. The bank uses HTTPS for all pages

C. The bank requires a strong password

D. The bank limits login attempts

Solution

1. Step 1: Analyze the attack method

   The attacker tricks the user into submitting a form without their consent, typical of CSRF.

2. Step 2: Identify effective defense

   Requiring a unique CSRF token ensures the form submission is legitimate and from the user, blocking forged requests.

3. Final Answer:

   The bank requires a unique CSRF token with each form submission -> Option A

4. Quick Check:

   CSRF blocked by unique tokens [OK]

Hint: Unique CSRF tokens stop forged form submissions [OK]

Common Mistakes:

• Thinking HTTPS alone stops CSRF
• Believing strong passwords prevent CSRF
• Confusing login limits with CSRF defense

4. A developer wrote this code snippet to protect against CSRF:

<form method="POST" action="/transfer">
  <input type="hidden" name="csrf_token" value="12345" />
  <input type="submit" value="Send" />
</form>

Why might this code still be vulnerable to CSRF attacks?

medium

A. The form uses POST method instead of GET

B. The CSRF token is static and not unique per user session

C. The form does not include a CAPTCHA

D. The form action URL is relative

Solution

1. Step 1: Examine the CSRF token usage

   The token value "12345" is hardcoded and does not change per user or session, making it predictable.

2. Step 2: Understand CSRF token requirements

   Effective CSRF tokens must be unique and unpredictable per user session to prevent attackers from guessing them.

3. Final Answer:

   The CSRF token is static and not unique per user session -> Option B

4. Quick Check:

   Static tokens fail CSRF protection [OK]

Hint: CSRF tokens must be unique per session, not static [OK]

Common Mistakes:

• Thinking POST method alone prevents CSRF
• Assuming CAPTCHA is required for CSRF defense
• Believing relative URLs cause CSRF vulnerabilities

5. A website uses cookies for user sessions but does not implement CSRF tokens. An attacker crafts a malicious link that triggers a fund transfer when clicked by a logged-in user. How can the website improve security to prevent this CSRF attack without removing cookies?

hard

A. Implement a unique CSRF token that must be submitted with sensitive requests

B. Switch all requests to use GET method instead of POST

C. Require users to re-enter their password on every page load

D. Disable cookies and use URL parameters for sessions

Solution

1. Step 1: Identify the vulnerability

   Cookies alone do not prevent CSRF because browsers send them automatically with requests, allowing forged actions.

2. Step 2: Choose effective mitigation

   Adding unique CSRF tokens ensures that only legitimate requests from the user are accepted, blocking forged requests.

3. Final Answer:

   Implement a unique CSRF token that must be submitted with sensitive requests -> Option A

4. Quick Check:

   Unique tokens prevent CSRF despite cookies [OK]

Hint: Add unique CSRF tokens to protect cookie-based sessions [OK]

Common Mistakes:

• Thinking GET requests are safer than POST
• Believing password re-entry on every page is practical
• Assuming disabling cookies is the only fix