Cross-site request forgery (CSRF) in Cybersecurity - Time & Space Complexity
Start learning this pattern below
Jump into concepts and practice - no test required
When analyzing CSRF protection, we want to understand how the time to check requests grows as more requests come in.
We ask: How does the system handle many requests and keep verifying tokens efficiently?
Analyze the time complexity of the following CSRF token verification code.
function verifyCsrfToken(request) {
const token = request.headers['csrf-token'];
if (!token) return false;
return validTokens.includes(token);
}
This code checks if the CSRF token sent in the request headers matches any valid token stored on the server.
Look for repeated checks or loops in the code.
- Primary operation: Searching the list of valid tokens.
- How many times: Once per request, but the search scans through all stored tokens.
As the number of valid tokens grows, the time to find a matching token grows too.
| Input Size (n) | Approx. Operations |
|---|---|
| 10 | 10 checks |
| 100 | 100 checks |
| 1000 | 1000 checks |
Pattern observation: The time grows directly with the number of tokens to check.
Time Complexity: O(n)
This means the time to verify a token grows linearly with the number of stored valid tokens.
[X] Wrong: "Checking a CSRF token always takes the same time no matter how many tokens exist."
[OK] Correct: If tokens are stored in a list, the system must check each one until it finds a match, so more tokens mean more checks and longer time.
Understanding how token verification scales helps you design secure systems that stay fast even with many users.
"What if valid tokens were stored in a hash set instead of a list? How would the time complexity change?"
Practice
Solution
Step 1: Understand CSRF attack purpose
CSRF attacks aim to make a user unknowingly perform actions they did not intend on a trusted website.Step 2: Compare with other attack types
Phishing steals passwords, DoS overloads servers, and ransomware encrypts data, which are different from CSRF.Final Answer:
To trick a logged-in user into performing unwanted actions on a website -> Option DQuick Check:
CSRF = trick user actions [OK]
- Confusing CSRF with phishing attacks
- Thinking CSRF steals passwords directly
- Mixing CSRF with denial-of-service attacks
Solution
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.Step 2: Eliminate unrelated options
Encrypting passwords, blocking cookies, or disabling JavaScript do not specifically prevent CSRF attacks.Final Answer:
Using secret tokens that must be submitted with requests -> Option CQuick Check:
CSRF protection = secret tokens [OK]
- Thinking password encryption stops CSRF
- Believing blocking cookies prevents CSRF
- Assuming disabling JavaScript is a CSRF fix
Solution
Step 1: Analyze the attack method
The attacker tricks the user into submitting a form without their consent, typical of CSRF.Step 2: Identify effective defense
Requiring a unique CSRF token ensures the form submission is legitimate and from the user, blocking forged requests.Final Answer:
The bank requires a unique CSRF token with each form submission -> Option AQuick Check:
CSRF blocked by unique tokens [OK]
- Thinking HTTPS alone stops CSRF
- Believing strong passwords prevent CSRF
- Confusing login limits with CSRF defense
<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?
Solution
Step 1: Examine the CSRF token usage
The token value "12345" is hardcoded and does not change per user or session, making it predictable.Step 2: Understand CSRF token requirements
Effective CSRF tokens must be unique and unpredictable per user session to prevent attackers from guessing them.Final Answer:
The CSRF token is static and not unique per user session -> Option BQuick Check:
Static tokens fail CSRF protection [OK]
- Thinking POST method alone prevents CSRF
- Assuming CAPTCHA is required for CSRF defense
- Believing relative URLs cause CSRF vulnerabilities
Solution
Step 1: Identify the vulnerability
Cookies alone do not prevent CSRF because browsers send them automatically with requests, allowing forged actions.Step 2: Choose effective mitigation
Adding unique CSRF tokens ensures that only legitimate requests from the user are accepted, blocking forged requests.Final Answer:
Implement a unique CSRF token that must be submitted with sensitive requests -> Option AQuick Check:
Unique tokens prevent CSRF despite cookies [OK]
- Thinking GET requests are safer than POST
- Believing password re-entry on every page is practical
- Assuming disabling cookies is the only fix
