CSRF attacks and token protection in PHP - Step-by-Step Execution

Concept Flow - CSRF attacks and token protection

User visits form page

↓

Server generates CSRF token

↓

Token stored in session and form

↓

User submits form with token

↓

Server checks token validity

↓

Process form

The server creates a unique token for the user session and includes it in the form. When the form is submitted, the server checks the token to confirm the request is genuine.

Execution Sample

PHP

<?php
session_start();
if (empty($_SESSION['csrf_token'])) {
  $_SESSION['csrf_token'] = bin2hex(random_bytes(32));
}
if ($_SERVER['REQUEST_METHOD'] === 'POST') {
  if (!hash_equals($_SESSION['csrf_token'], $_POST['csrf_token'] ?? '')) {
    die('CSRF token invalid');
  }
  echo 'Form processed';
}
?>

This PHP code generates a CSRF token, stores it in the session, and checks it on form submission to protect against CSRF attacks.

Execution Table

Step	Action	Token in Session	Token in POST	Check Result	Output
1	Start session, check token	none	none	Token generated	none
2	User loads form	abc123token...	none	none	Form with token sent
3	User submits form	abc123token...	abc123token...	Tokens match	Form processed
4	User submits form with wrong token	abc123token...	wrongtoken	Tokens do not match	CSRF token invalid
5	End	abc123token...	varies	Process ends	none

💡 Execution stops when token check fails or form is processed successfully.

Variable Tracker

Variable	Start	After Step 1	After Step 2	After Step 3	After Step 4	Final
$_SESSION['csrf_token']	none	abc123token...	abc123token...	abc123token...	abc123token...	abc123token...
$_POST['csrf_token']	none	none	none	abc123token...	wrongtoken	varies

Key Moments - 3 Insights

Why do we store the CSRF token in the session?

The session stores the token securely on the server side so it can be compared with the token submitted by the user to verify authenticity, as shown in step 3 of the execution_table.

What happens if the token in the POST data does not match the session token?

The server rejects the request and stops processing, outputting 'CSRF token invalid' as shown in step 4 of the execution_table.

Why do we generate a new token only if none exists?

To keep the same token for the user's session until it expires or changes, ensuring consistency between form and session tokens, as seen in step 1.

Visual Quiz - 3 Questions

Look at the execution_table, what is the output when the tokens match at step 3?

A CSRF token invalid

B Form with token sent

C Form processed

D Token generated

💡 Hint

Check the 'Output' column at step 3 in the execution_table.

At which step does the server generate the CSRF token?

A Step 3

B Step 1

C Step 2

D Step 4

💡 Hint

Look at the 'Action' and 'Check Result' columns in the execution_table for token generation.

If the token in the POST data is missing, what will happen according to the code?

A CSRF token invalid error

B Token is generated again

C Form processed normally

D Session token is deleted

💡 Hint

Refer to the token check in the code and the 'Check Result' column in the execution_table for invalid tokens.

Concept Snapshot

CSRF protection uses a unique token stored in the user session and included in forms.
On form submission, the server compares the submitted token with the session token.
If tokens match, the request is valid; otherwise, it is rejected.
Tokens prevent attackers from forging requests on behalf of users.
Generate tokens once per session and verify on every POST request.

Full Transcript

This visual trace shows how CSRF token protection works in PHP. First, the server starts a session and generates a unique token if none exists. This token is saved in the session and included in the HTML form sent to the user. When the user submits the form, the server compares the token sent in the POST data with the session token. If they match, the form is processed safely. If not, the server rejects the request to prevent CSRF attacks. The execution table tracks these steps, showing token values and outcomes. Key moments clarify why the token is stored in the session and what happens on mismatch. The quiz tests understanding of token generation, matching, and failure cases.

Practice

1. What is the main purpose of a CSRF token in a PHP web application?

easy

A. To speed up the loading time of the website

B. To prevent unauthorized commands from being transmitted from a user the website trusts

C. To encrypt user passwords before storing them

D. To validate user input format on forms

Solution

1. Step 1: Understand CSRF attack basics

   CSRF attacks trick a user into submitting unwanted actions on a trusted site.

2. Step 2: Role of CSRF token

   A CSRF token is a unique value that verifies the request is from the legitimate user, preventing unauthorized commands.

3. Final Answer:

   To prevent unauthorized commands from being transmitted from a user the website trusts -> Option B

4. Quick Check:

   CSRF token purpose = prevent unauthorized commands [OK]

Hint: CSRF tokens stop fake requests from trusted users [OK]

Common Mistakes:

• Confusing CSRF tokens with password encryption
• Thinking CSRF tokens speed up websites
• Believing CSRF tokens validate input format

2. Which PHP function is commonly used to generate a CSRF token?

easy

A. random_bytes()

B. md5()

C. htmlspecialchars()

D. strtoupper()

Solution

1. Step 1: Identify secure token generation

   CSRF tokens must be random and hard to guess, so secure random functions are used.

2. Step 2: Choose the correct function

   random_bytes() generates cryptographically secure random bytes, suitable for tokens.

3. Final Answer:

   random_bytes() -> Option A

4. Quick Check:

   Secure token generation = random_bytes() [OK]

Hint: Use random_bytes() for secure token generation [OK]

Common Mistakes:

• Using md5() which is not secure for tokens
• Confusing htmlspecialchars() with token generation
• Using strtoupper() which only changes case

3. What will the following PHP code output if the CSRF token in session matches the token sent in POST?

$_SESSION['csrf_token'] = 'abc123';
if (isset($_POST['csrf_token']) && $_POST['csrf_token'] === $_SESSION['csrf_token']) {
    echo 'Valid request';
} else {
    echo 'Invalid request';
}

medium

A. No output

B. Invalid request

C. Valid request

D. Undefined index error

Solution

1. Step 1: Check token comparison logic

   The code compares the POST token with the session token for equality.

2. Step 2: When tokens match

   If tokens match, it echoes 'Valid request'. If not, 'Invalid request'.

3. Final Answer:

   Valid request -> Option C

4. Quick Check:

   Matching tokens = Valid request [OK]

Hint: Matching tokens means valid request output [OK]

Common Mistakes:

• Assuming error if POST token is set correctly
• Ignoring isset() check causing errors
• Thinking output is empty when tokens match

4. Identify the error in this PHP CSRF token validation snippet:

session_start();
if ($_POST['csrf_token'] == $_SESSION['csrf_token']) {
    echo 'Token valid';
} else {
    echo 'Token invalid';
}

medium

A. session_start() should be called after token check

B. Using == instead of === causes token mismatch

C. Tokens should be compared with strtolower()

D. Missing check if $_POST['csrf_token'] is set before comparing

Solution

1. Step 1: Analyze token existence check

   The code compares $_POST['csrf_token'] without verifying if it exists, risking undefined index error.

2. Step 2: Importance of isset()

   Using isset() prevents errors by ensuring the token is present before comparison.

3. Final Answer:

   Missing check if $_POST['csrf_token'] is set before comparing -> Option D

4. Quick Check:

   Check token existence before compare = Missing isset() [OK]

Hint: Always check if POST token exists before comparing [OK]

Common Mistakes:

• Ignoring isset() causing runtime errors
• Thinking == vs === affects token validation here
• Calling session_start() after token check

5. You want to protect a PHP form from CSRF attacks. Which sequence correctly implements token generation, embedding, and validation? A) Generate token on form display, store in session, embed in hidden input, then check token on form submission. B) Generate token on form submission, embed in hidden input, then store in session. C) Store token in session after form submission, then generate token and embed in form. D) Embed a static token in the form and check it on submission without session.

hard

A. Generate token on form display, store in session, embed in hidden input, then check token on form submission.

B. Generate token on form submission, embed in hidden input, then store in session.

C. Store token in session after form submission, then generate token and embed in form.

D. Embed a static token in the form and check it on submission without session.

Solution

1. Step 1: Token generation and storage

   Token must be generated before showing the form and stored in session to verify later.

2. Step 2: Embedding and validation

   Embed the token in a hidden form field and check it against the session token on submission.

3. Final Answer:

   Generate token on form display, store in session, embed in hidden input, then check token on form submission. -> Option A

4. Quick Check:

   Token lifecycle = generate, store, embed, validate [OK]

Hint: Generate and store token before form, validate after submission [OK]

Common Mistakes:

• Generating token after form submission
• Not storing token in session
• Using static tokens without session storage