Cross-site request forgery (CSRF) in Cybersecurity - Step-by-Step Execution

Concept Flow - Cross-site request forgery (CSRF)

User logged into Site A

↓

User visits malicious Site B

↓

Site B sends hidden request to Site A

↓

Browser sends request with User's cookies

↓

Site A processes request as if from User

↓

Unintended action happens on Site A

This flow shows how a user logged into one site can be tricked by another site to perform unwanted actions without their knowledge.

Execution Sample

Cybersecurity

User logged in to BankSite
User visits MaliciousSite
MaliciousSite sends hidden form POST to BankSite
Browser sends request with BankSite cookies
BankSite processes request as valid

This example shows how a malicious site can cause a user's browser to send a request to a trusted site using the user's credentials.

Analysis Table

Step	Action	Request Sent?	Cookies Included?	Site Processing	Result
1	User logs into BankSite	No	No	N/A	User authenticated on BankSite
2	User visits MaliciousSite	No	No	N/A	User on MaliciousSite page
3	MaliciousSite creates hidden form targeting BankSite	No	No	N/A	Form ready to submit
4	MaliciousSite auto-submits form	Yes	Yes (BankSite cookies)	BankSite receives request	Request treated as from user
5	BankSite performs action (e.g., transfer money)	N/A	N/A	Action executed	Unintended transaction occurs
6	User unaware of action	N/A	N/A	N/A	Security breach due to CSRF

💡 Process ends after BankSite executes the unintended action triggered by the forged request.

State Tracker

Variable	Start	After Step 2	After Step 4	Final
User Authentication	Logged in	Logged in	Logged in	Logged in
Request Sent	No	No	Yes	Yes
Cookies Included	No	No	Yes	Yes
Site Action	None	None	Unintended action	Unintended action

Key Insights - 3 Insights

Why does the malicious request include the user's cookies even though the user did not submit it?

Because the browser automatically includes cookies for the target site with any request sent to that site, as shown in step 4 of the execution_table.

Why does the trusted site process the malicious request as if it came from the user?

Because the request includes valid authentication cookies, so the site assumes it is a legitimate user action, as seen in step 4 and 5.

Why is the user unaware of the unintended action?

Because the malicious request happens in the background without user interaction, and the user is on a different site, as shown in step 6.

Visual Quiz - 3 Questions

Look at the execution_table at step 4. What is true about the request sent?

A It is sent from the user directly

B It does not include any cookies

C It includes the user's cookies for BankSite

D It is blocked by the browser

💡 Hint

Check the 'Cookies Included?' column at step 4 in the execution_table.

At which step does the BankSite perform the unintended action?

A Step 3

B Step 5

C Step 4

D Step 6

💡 Hint

Look at the 'Site Processing' and 'Result' columns in the execution_table.

If the browser did not send cookies with the request, what would happen?

A The request would be rejected or treated as unauthenticated

B The malicious site would gain access to user data

C The request would still be processed as valid

D The user would be logged out automatically

💡 Hint

Refer to the importance of cookies in the 'Cookies Included?' column in the execution_table.

Concept Snapshot

Cross-site request forgery (CSRF) tricks a logged-in user's browser into sending unwanted requests to a trusted site.
The browser includes authentication cookies automatically.
The trusted site processes the request as if from the user.
This can cause unintended actions like money transfers.
Protection involves verifying requests with tokens or checking origins.

Full Transcript

Cross-site request forgery (CSRF) happens when a user logged into a trusted site visits a malicious site that secretly sends a request to the trusted site. The browser automatically includes the user's authentication cookies with this request. The trusted site processes the request as if it came from the user, causing unintended actions like unauthorized transactions. The user does not realize this because the malicious request happens in the background. Understanding this flow helps in recognizing why CSRF is a security risk and why protections like tokens are necessary.

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