CSRF in plain English
Imagine a courier who is known at your bank and carries a permanent pass with your name on it. The bank carries out every order the courier hands in, no questions asked – after all, the pass is valid. With CSRF, a fraudster secretly slips the courier an extra order along the way. The bank sees the valid pass and carries out that order, too.
In the digital world, your browser is that courier. When you sign in to a web application – such as online banking, the admin area of an online shop, or the company portal – the browser stores a session cookie. This is a kind of digital visitor pass. The browser automatically sends it along with every request to that application so you don’t have to sign in over and over again.
About the name: “cross-site” means that the request originates from a different website; “request forgery” means a forged request. You’ll occasionally also see the abbreviation XSRF.
How CSRF works
A CSRF attack typically unfolds in four steps:
- The victim is signed in: A person is logged in to a web application, for example the admin area of an online shop.
- The bait: The attacker lures the person to a crafted web page, for example via a link in an email.
- The hidden request: The page contains invisible code that sends a request to the web application in the background – such as “Create a new administrator.” The browser automatically attaches the session cookie.
- The execution: The web application sees a request with a valid session cookie and carries it out. It can’t tell whether the person really wanted the action.
As a rule, the attacker doesn’t get to see the application’s response. So they can’t read data directly – but they can trigger actions with serious consequences.
CSRF is often confused with cross-site scripting (XSS). In XSS, the attacker injects their own code into the web application’s pages, which then runs in other people’s browsers. With CSRF, the application itself remains unchanged – what is abused is the trust it places in the signed-in person’s browser. However, an XSS vulnerability can undermine CSRF protections. CSRF should also not be confused with SSRF: there, it’s not the browser but a server that is tricked into sending unwanted requests.
A practical example
A wholesaler of plumbing supplies runs an ordering portal for trade businesses. An employee is signed in to the admin area when he clicks a link in an email that supposedly leads to a supplier’s price list. The web page looks harmless, but in the background it sends a request to the portal that creates a new administrator account – and because the employee is signed in, the portal executes it. The attacker can now log in with the new account and manipulate prices, customer data, and orders.
The subsequent analysis reveals the cause: the forms in the admin area contain no anti-CSRF tokens – secret verification values – and the session cookie isn’t restricted with the SameSite attribute. The development contractor enables the framework’s built-in CSRF protection (the framework is the software foundation the portal is built on), sets the cookie attribute, and from now on requires users to re-enter their password before creating a new administrator.
Why does this matter for businesses?
CSRF mainly affects web applications in which signed-in users trigger important actions: online shops, customer portals, online banking, internal admin interfaces, and the web interfaces of routers or firewalls. The higher the privileges of the deceived person, the greater the potential damage – up to and including takeover of the entire application.
Modern browsers and frameworks have raised the bar for CSRF: some browsers no longer send cookies without an explicit SameSite setting on many cross-site requests. But you shouldn’t rely on that – not all browsers behave this way, and a single unprotected function can be enough.
How to protect your organization
- Use anti-CSRF tokens: Every form receives a secret random value that the application checks with each request. An outside web page doesn’t know it and therefore can’t create a valid request.
- Set the SameSite attribute: With the setting “Strict” or “Lax,” the browser sends session cookies on requests from other websites either not at all or only in limited cases.
- Check the origin: The application uses the origin information the browser sends along (the Origin header) to check where a request comes from, and rejects requests from other sites.
- Require confirmation for critical actions: Password changes, transfers, or new administrator accounts require re-entering the password or a second factor.
- No changes via a simple link: Actions that change data must never be triggered by a simple page request (GET request).
- Use framework protection: Many web frameworks come with built-in CSRF protection. Ask your development contractor whether it’s enabled everywhere.
- Adopt safe habits: Anyone working with administrator rights should log out when they’re done and ideally use a separate browser profile for this work.
How Rootsektor can help
In a web application penetration test, we check, among other things, whether functions that change data or settings can be abused via CSRF and whether protective measures have been implemented effectively. The retest of remediated vulnerabilities is free of charge; you can get your fixed-price quote via our Pentest Quote page.