Understanding CSRF Attacks: Risks, Detection, and Defense Strategies

CSRF Introduction

CSRF (Cross‑site request forgery), also known as “OneClick Attack” or Session Riding, is a malicious exploitation of a trusted website.

The diagram shows a simple CSRF model: a user visits a malicious site B, which forces the browser to send a request to trusted site A; because the user already has a trusted relationship with A, the request is executed as if the user initiated it.

Harms of CSRF Attacks

Attackers hijack a victim’s identity to send malicious requests that appear legitimate to the server, such as sending emails, posting messages, stealing accounts, adding administrators, purchasing items, or transferring virtual currency.

If the CSRF payload includes worm links, recipients who click the links can further spread the malicious content, potentially causing massive data theft, trojan implantation, site crashes, user complaints, loss of reputation, and even business failure. Historical examples include the Samy worm on MSN and similar incidents on Sina Weibo.

CSRF Attack Principles and Process

1. User C logs into trusted site A. 2. After authentication, site A issues a cookie to the browser. 3. While still logged in, the user opens a tab to malicious site B. 4. Site B returns malicious code that triggers a request to site A. 5. The browser automatically includes the cookie when sending the forged request to site A, which processes it as a legitimate action from user C.

Example – Simple Version: If a blog platform provides a GET endpoint for following a user (e.g., blogUserGuid), an attacker can embed an <img> tag pointing to that URL in a malicious post. Anyone viewing the post will automatically trigger the follow action.

Example – Advanced Version: Even if the endpoint requires POST, an attacker can host a third‑party page with a hidden form that auto‑submits via social engineering (e.g., QQ, email). Because the form can submit cross‑origin, the victim’s browser will send the request with the valid session cookie.

Embedding an <iframe> directly does not work due to same‑origin restrictions; the attacker must use a double‑iframe trick to bypass redirects and avoid XMLHttpRequest limitations.

CSRF Vulnerability Detection

The simplest detection method is to capture a legitimate request, remove the Referer header, and resend it; if the request still succeeds, a CSRF vulnerability likely exists.

Tools such as CSRFTester and CSRF Request Builder automate this process by capturing all links and forms, modifying parameters, and replaying the requests to see if the server accepts them.

CSRF Defense Strategies

Common defenses include verifying the HTTP Referer header, adding a token to request URLs, and using custom HTTP header attributes.

1. Prefer POST over GET – GET endpoints are easy to exploit with an <img> tag; restricting sensitive actions to POST reduces risk.

2. Browser Cookie Policies – Older browsers block third‑party cookies, but many modern browsers do not, so relying on cookie policies alone is insufficient.

3. Captcha – Requiring user interaction can deter automated CSRF attacks, though it may affect usability.

4. Referer Check – Validate that the Referer header matches an allowed domain; however, the header may be absent, limiting reliability.

5. Anti‑CSRF Token – Generate a random, unpredictable token stored in the user’s session or cookie and embed it in forms; the server validates the token on submission, preventing forged requests.

Tokens should be random, kept secret, and used with POST requests to avoid leakage. When XSS vulnerabilities exist, token‑based protection alone is ineffective.

Additional method: include the token in a custom HTTP header via XMLHttpRequest, which avoids exposing the token in URLs or forms, but this approach requires AJAX‑based interactions and may not be feasible for legacy systems.

Brief Overview of XSS

Cross‑Site Scripting (XSS) involves injecting malicious scripts into web pages that execute in the victim’s browser.

There are two main categories: internal attacks (exploiting existing application vulnerabilities) and external attacks (crafting malicious pages to target victims). XSS can be stored (persistent) or reflected (non‑persistent), with stored XSS being more dangerous due to its ability to spread worms and steal cookies.