Cross-site request forgery (CSRF) in Cybersecurity - Deep Dive

Overview - Cross-site request forgery (CSRF)

What is it?

Cross-site request forgery (CSRF) is a type of cyber attack where a malicious website tricks a user's browser into performing unwanted actions on a different website where the user is logged in. It exploits the trust that a website has in the user's browser by sending unauthorized commands without the user's knowledge. This can lead to actions like changing account details or making transactions without permission. CSRF attacks rely on the victim being authenticated on the target site.

Why it matters

CSRF attacks can cause serious harm by making users unknowingly perform harmful actions, such as transferring money or changing passwords. Without protections against CSRF, websites would be vulnerable to attackers who can hijack user sessions and cause damage without needing to steal passwords. This undermines trust in online services and can lead to financial loss, privacy breaches, and damaged reputations.

Where it fits

Before learning about CSRF, one should understand how web sessions and cookies work, especially how browsers store and send authentication tokens. After CSRF, learners can explore related web security topics like Cross-Origin Resource Sharing (CORS), SameSite cookies, and other web attack types such as Cross-site scripting (XSS).

Mental Model

Core Idea

CSRF tricks a trusted website into acting on behalf of a user without their consent by exploiting the user's active login session.

Think of it like...

Imagine someone sneaking a forged letter into your mailbox that looks like it came from you, instructing your bank to transfer money. The bank trusts the letter because it appears to be from you, but you never actually wrote it.

┌───────────────┐       ┌───────────────┐       ┌───────────────┐
│ User's Browser│──────▶│ Malicious Site│       │ Trusted Site  │
│ (Logged in)   │       │ (Sends hidden │──────▶│ (Receives     │
│               │       │  request)     │       │  forged request)│
└───────────────┘       └───────────────┘       └───────────────┘
       │                                              ▲
       └──────────────────────────────────────────────┘
                 (Browser sends cookies automatically)

Build-Up - 7 Steps

1

Foundation

Understanding Web Sessions and Cookies

Concept: Learn how websites remember users using sessions and cookies.

When you log into a website, it gives your browser a small piece of data called a cookie. This cookie tells the website who you are on future visits without logging in again. Your browser automatically sends this cookie with every request to that website, so the site knows it's you.

Result

You stay logged in as you browse different pages without re-entering your password.

Understanding cookies and sessions is key because CSRF attacks exploit the automatic sending of these cookies to perform actions without your knowledge.

2

Foundation

What is a Cross-site Request Forgery?

Concept: Introduce the basic idea of CSRF as an attack that tricks your browser into sending unwanted requests.

CSRF happens when a malicious website causes your browser to send a request to another site where you are logged in. Because your browser sends your login cookie automatically, the other site thinks the request is from you, even though you didn't intend it.

Result

Actions like changing your email or making purchases can happen without your permission.

Knowing that browsers send cookies automatically helps explain why CSRF can happen without the user clicking anything on the trusted site.

3

Intermediate

How Attackers Exploit CSRF

🤔Before reading on: Do you think CSRF requires the attacker to steal your password? Commit to your answer.

Concept: CSRF attacks do not need the attacker to know your password; they rely on your active login session and browser behavior.

Attackers create hidden forms or scripts on their malicious site that send requests to the trusted site. When you visit the malicious site, your browser sends these requests with your cookies automatically. The trusted site processes these requests as if you made them.

Result

The attacker can perform actions on your account without knowing your credentials.

Understanding that CSRF exploits browser behavior rather than stealing credentials reveals why it is a subtle and dangerous attack.

4

Intermediate

Common CSRF Attack Examples

🤔Before reading on: Would a simple link click be enough to cause a CSRF attack? Commit to your answer.

Concept: CSRF attacks can happen through various methods like hidden forms, image tags, or scripts that trigger requests automatically.

Examples include submitting a hidden form that changes your password, or an image tag that triggers a money transfer request. These actions happen without your explicit consent or knowledge.

Result

Your account can be manipulated just by visiting a malicious page.

Knowing the variety of attack methods helps in understanding why CSRF defenses must be comprehensive.

5

Intermediate

CSRF Protection Techniques

🤔Before reading on: Do you think simply checking cookies is enough to stop CSRF? Commit to your answer.

Concept: Websites use special tokens and cookie settings to verify that requests are genuine and intentional.

One common defense is the CSRF token: a secret value included in forms that the server checks on submission. Another is setting cookies with the SameSite attribute to restrict when cookies are sent. These methods ensure that requests come from legitimate user actions.

Result

Unauthorized requests without the correct token or cookie settings are rejected.

Understanding these protections shows how websites distinguish between real user actions and forged requests.

6

Advanced

Limitations and Bypass Techniques

🤔Before reading on: Can attackers bypass CSRF tokens if they steal them? Commit to your answer.

Concept: CSRF protections can be bypassed if attackers find ways to steal tokens or exploit browser weaknesses.

If an attacker uses Cross-site scripting (XSS) to read tokens or cookies, they can bypass CSRF defenses. Also, misconfigured SameSite cookies or legacy browsers may not enforce protections properly. Attackers may also trick users into performing actions that reveal tokens.

Result

CSRF attacks can still succeed if protections are incomplete or combined with other vulnerabilities.

Knowing the limits of CSRF defenses highlights the importance of layered security and fixing all vulnerabilities.

7

Expert

CSRF in Modern Web Architectures

🤔Before reading on: Do you think single-page applications (SPAs) face the same CSRF risks as traditional sites? Commit to your answer.

Concept: Modern web apps using APIs and tokens have different CSRF risks and protection strategies.

SPAs often use tokens like JWTs stored in browser storage instead of cookies. Since these tokens are sent manually in headers, CSRF risks are reduced. However, if cookies are still used for authentication, CSRF remains a threat. Developers must carefully design API authentication and CORS policies to prevent CSRF and related attacks.

Result

CSRF protection strategies must adapt to new web technologies and authentication methods.

Understanding how modern app designs change CSRF risks helps experts build more secure systems.

Under the Hood

CSRF works because browsers automatically include cookies with every request to a domain, regardless of where the request originated. When a user is logged in, the browser sends the session cookie with any request to that site. Attackers exploit this by causing the browser to send requests from a malicious site, which the target site trusts because of the cookie. The server cannot distinguish if the request was intentionally made by the user or forged by another site without additional checks.

Why designed this way?

Browsers were designed to send cookies automatically to simplify user experience, so users don't have to log in repeatedly. This design prioritizes convenience and seamless browsing. However, this trust model did not initially consider cross-site attacks, leading to CSRF vulnerabilities. Defenses like CSRF tokens and SameSite cookies were introduced later to balance security with usability.

┌───────────────┐       ┌───────────────┐       ┌───────────────┐
│ User's Browser│──────▶│ Malicious Site│──────▶│ Trusted Site  │
│ Sends request │       │ Sends forged  │       │ Receives      │
│ with cookies │       │ request       │       │ request with  │
│ automatically│       │ (hidden form) │       │ user cookies  │
└───────────────┘       └───────────────┘       └───────────────┘
       │                                              ▲
       └──────────────────────────────────────────────┘
                 (Browser trusts cookies blindly)

Myth Busters - 4 Common Misconceptions

Quick: Does CSRF require the attacker to know your password? Commit to yes or no before reading on.

Common Belief: CSRF attacks happen because attackers steal your password or login details.

Reality: CSRF attacks do not require the attacker to know your password; they exploit your active login session and browser behavior.

Why it matters: Believing this leads to ignoring CSRF protections, thinking password security alone is enough, leaving accounts vulnerable.

Quick: Can CSRF attacks happen if you only click a link? Commit to yes or no before reading on.

Common Belief: You must actively submit a form or click a button on a malicious site for CSRF to work.

Reality: CSRF can happen just by visiting a page with hidden requests or images that trigger actions automatically.

Why it matters: Underestimating this risk causes users and developers to overlook passive attack vectors, increasing vulnerability.

Quick: Are cookies alone enough to prevent CSRF? Commit to yes or no before reading on.

Common Belief: If a site checks cookies, it is safe from CSRF attacks.

Reality: Cookies are sent automatically by browsers and cannot alone prevent CSRF; additional tokens or cookie settings are needed.

Why it matters: Relying only on cookies leads to false security and leaves sites open to CSRF exploits.

Quick: Can CSRF protections be bypassed if the attacker uses XSS? Commit to yes or no before reading on.

Common Belief: CSRF tokens and protections are foolproof and cannot be bypassed.

Reality: If attackers exploit Cross-site scripting (XSS) vulnerabilities, they can steal tokens and bypass CSRF defenses.

Why it matters: Ignoring this leads to incomplete security strategies, as fixing CSRF alone is not enough without addressing XSS.

Expert Zone

1

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

2

SameSite cookie attribute has different modes (Strict, Lax, None) that affect CSRF protection and user experience differently.

3

APIs using tokens in headers instead of cookies reduce CSRF risk but require careful CORS configuration to avoid other attacks.

When NOT to use

CSRF protections focused on cookies are less relevant when using token-based authentication stored outside cookies, such as in local storage. In such cases, developers should use other methods like strict CORS policies and token validation. Also, CSRF defenses are not a substitute for fixing XSS vulnerabilities, which can bypass CSRF protections.

Production Patterns

In real-world systems, CSRF tokens are embedded in forms and verified on the server side. Many frameworks provide built-in CSRF protection middleware. Developers combine CSRF tokens with SameSite cookie settings and Content Security Policy headers. Single-page applications often use token-based authentication with custom headers to avoid CSRF. Monitoring and logging suspicious requests also help detect CSRF attempts.

Connections

Cross-site scripting (XSS)

XSS can be used to bypass CSRF protections by stealing tokens or cookies.

Understanding XSS helps grasp why CSRF defenses alone are insufficient and why comprehensive web security is necessary.

SameSite cookie attribute

SameSite cookies restrict when cookies are sent, directly reducing CSRF attack surface.

Knowing how SameSite works clarifies modern browser-based CSRF defenses and their tradeoffs.

Social engineering

CSRF exploits user trust and browser behavior, similar to how social engineering exploits human trust.

Recognizing CSRF as a form of trust exploitation connects cybersecurity to psychology and human factors.

Common Pitfalls

#1 Not verifying CSRF tokens on the server side.

Wrong approach:

Accepting form submissions without checking the CSRF token value.

Correct approach:

Rejecting any request where the CSRF token is missing or does not match the expected value.

Root cause:

Misunderstanding that generating tokens alone is not enough; the server must validate them to prevent forgery.

#2 Storing authentication tokens in cookies without SameSite attribute.

Wrong approach:

Set-Cookie: sessionid=abc123; HttpOnly; Secure

Correct approach:

Set-Cookie: sessionid=abc123; HttpOnly; Secure; SameSite=Strict

Root cause:

Ignoring cookie attributes that control cross-site sending allows browsers to send cookies with forged requests.

#3 Using GET requests for state-changing actions.

Wrong approach:

Changing user password via a URL like https://example.com/change?password=newpass

Correct approach:

Using POST requests with CSRF tokens for all state-changing operations.

Root cause:

Misunderstanding that GET requests can be triggered by simple links or images, making them vulnerable to CSRF.

Key Takeaways

CSRF attacks trick a logged-in user's browser into sending unauthorized requests by exploiting automatic cookie sending.

Protecting against CSRF requires verifying unique tokens or using cookie attributes like SameSite to ensure requests are intentional.

CSRF does not require stealing passwords; it exploits browser trust and user sessions, making it a subtle but serious threat.

Modern web apps reduce CSRF risk by using token-based authentication and careful API design, but layered defenses remain essential.

Understanding CSRF alongside related attacks like XSS and social engineering is crucial for building secure web applications.