Cross Site Request Forgery Examples

Introduction

Cross Site Request Forgery (CSRF) is one of the oldest but still most dangerous web application vulnerabilities. It tricks authenticated users into unknowingly performing actions on a web application using their active session. A csrf attack is a malicious exploit that tricks authenticated users into submitting unauthorized requests, often by leveraging browser behaviors and crafted requests. A well-known history CSRF in the OpenX advertising platform caused rogue ads to spread across the platforms users.

Attackers have used CSRF to create admin accounts, change configurations, and even distribute malware at scale. This type of exploit is also known as session riding, where trusted user sessions are hijacked or manipulated by exploiting the trust web applications have in their session cookies and request handling mechanisms.

Case Study: The OpenX CSRF Exploit

Back in 2011, researchers disclosed a Cross-Site Request Forgery (CSRF) vulnerability in OpenX Source 2.8.7, the self-hosted version of the popular ad server. The flaw was actively exploited in the wild, with attackers using it to silently create rogue administrator accounts and serve malicious ads through compromised OpenX installations.

When a compromised installation was investigated, security teams found:

A rogue admin account (“openx-manager”) silently created via a malicious request.
Audit logs showing the account appeared to be created by a legitimate administrator (classic CSRF behavior), where the request includes the victim’s session credentials, allowing the attack to succeed.
Attack payloads delivered from OpenX’s own SaaS infrastructure, hosted under adserver.openx.org. The attack could be triggered by submitting form data through hidden forms or iframes as part of the exploit.
Additional malicious changes, including overwritten .htaccess files and dropped PHP backdoors.

This attack effectively turned compromised OpenX servers into malware distribution hubs, serving malicious ads to anyone who visited affected sites.

Why It Was CSRF (The Actual Exploit Flow)

Here’s how the OpenX CSRF attack really worked:

Admin logs into OpenX.
The victim (a legitimate OpenX administrator) signs into their own OpenX instance. At this point, their browser has a valid session cookie tied to that admin login.
Victim visits a malicious resource.
While still logged in, the admin’s browser automatically loads a file hosted on OpenX’s own SaaS infrastructure (adserver.openx.org/plugins/videoReport/images/items/icons.html).
Malicious code auto-executes.
That file contained a crafted request (a hidden form/POST) pointing back to the victim’s OpenX admin panel (/admin-user.php?submit=1). Because the browser is already authenticated, it automatically attaches the victim’s valid session cookie.
Request succeeds “as the admin.”
To the OpenX server, it looks like the logged-in admin deliberately submitted that request. No CSRF token or second factor was required, so the request was accepted without question.
Result: rogue admin account created.
The malicious payload instructed OpenX to create a new administrator account called openx-manager. From this point forward, the attacker could log in directly with that new account, bypassing the need to ever phish or brute-force the real admin.

This meant attackers didn’t need to brute-force passwords or steal credentials they simply abused the victim’s existing session while logged in. This was a successful csrf attack that resulted in unauthorized account creation.

What Is CSRF?

At its core, Cross Site Request Forgery exploits the trust a site places in a logged-in user’s browser.

Simplified example:

You’re logged into your bank in one browser tab.
In another tab, you visit a malicious site that loads a hidden html form.
That form contains a submit button and is crafted to transfer $500 to the attacker’s own account or bank account. The user submits the form (or is tricked into doing so), which sends the transfer request to the bank using the session cookie information from the browser.
Such a request is processed by the bank as if it were legitimate, since it appears to come from the authenticated user. The bank processes the request as if you authorized it.

Common Real-World CSRF Examples

Account Takeover: Creating new admin accounts (as with OpenX) by submitting a fake request that impersonates the legitimate user.
Password Change: Forcing a user to reset their password to an attacker-chosen one, targeting the user’s login credentials through a fake request.
Fund Transfers: Exploiting banking or fintech apps to move money by sending a fake request that authorizes unauthorized transactions.
Setting Changes: Changing the victim’s email address, security questions, or MFA settings via a fake request, allowing attackers to alter sensitive account details.
Login CSRF: Tricking users into logging into attacker-controlled websites or exploiting the login process itself, enabling attackers to steal login credentials or gain unauthorized access by abusing authentication mechanisms.

Malicious Code and CSRF

Malicious code is a powerful enabler of CSRF attacks, often acting as the bridge between an attacker and an unsuspecting authenticated user. Attackers typically embed malicious code such as JavaScript or crafted HTML forms into a malicious website, phishing email, or even a compromised ad. When an authenticated user visits such a malicious website or interacts with the code, it silently triggers a forged request to a target web application. Because the user’s browser automatically includes session cookies with the request, the web application treats it as a legitimate request from the authenticated user.

This is why CSRF attacks are so dangerous: the forged request leverages the trust established by the user’s session, making it nearly indistinguishable from a genuine user action. To prevent CSRF attacks, web applications must validate user requests and implement robust anti-CSRF measures. The most effective defenses include using CSRF tokens—unique, unpredictable values tied to each user session and ensuring that every state-changing request is protected. By combining these anti-CSRF measures, developers can significantly reduce the risk of malicious code exploiting their web applications.

HTTP Methods and CSRF

CSRF attacks can exploit various HTTP methods to perform unauthorized actions on behalf of an authenticated user. While the GET method is typically used to retrieve data, attackers can abuse it to trigger unintended actions if a web application accepts state-changing requests via GET. However, the real danger lies in forged POST requests, which are commonly used for actions like form submission, updating user settings, or transferring funds.

A malicious website can craft a hidden form that automatically submits a forged POST request to a target web application, causing the user’s browser to send the request along with their session cookies. If the web application does not properly validate these requests, attackers can manipulate user accounts or perform other state-changing actions without the user’s knowledge.

To defend against such CSRF attacks, web applications should avoid using the GET method for any state-changing requests and instead use the POST method or other HTTP methods that require explicit user interaction. Additionally, all state-changing requests should be authenticated and validated using CSRF tokens or similar mechanisms to ensure that only legitimate user actions are processed.

Samesite Cookie Attribute: A Modern Defense

The SameSite cookie attribute has emerged as a powerful tool in the fight against CSRF attacks. By setting the SameSite attribute on cookies, web developers can control whether cookies are sent with cross site requests. When configured as “Strict” or “Lax,” the SameSite attribute instructs web browsers to withhold session cookies from requests originating from other sites, making it much harder for attackers to execute CSRF attacks through malicious websites.

Most modern web browsers now support the SameSite cookie attribute, making it an essential part of any CSRF prevention strategy. However, relying solely on SameSite is not enough. For comprehensive CSRF protection, developers should combine the SameSite cookie attribute with other anti-CSRF measures, such as CSRF tokens and proper validation of user requests. By layering these defenses, web applications can significantly reduce their exposure to CSRF vulnerabilities and protect both their users and their data from malicious activity.

Why CSRF Still Matters in 2025

Many assume CSRF is “solved” — after all, modern frameworks like Django, Rails, and Spring include protections by default. But reality shows otherwise:

Custom apps often disable or misconfigure protections, even though modern web frameworks typically include CSRF protection by default.
Business logic flaws can bypass token checks.
APIs & Single-Page Apps shift attack surfaces to cookies + JWT handling. It’s also crucial to secure ajax requests in these environments, as unprotected ajax requests and API endpoints are common targets for CSRF.
AI-powered phishing can more effectively lure admins to malicious pages.

Common csrf vulnerabilities persist, such as missing or flawed token verification, insecure token handling in cookies, and session management issues, despite modern defenses.

Even giants like Facebook, Google, and PayPal have had CSRF-related bug bounty reports in recent years.

Organizations must remain vigilant against potential csrf attacks as threats and techniques continue to evolve.

Here is a recent example of CSRF leading to XSS in a WordPress plugin found during a web application penetration test.

How to Prevent CSRF Attacks

Modern defenses include:

CSRF tokens — unpredictable, per-request tokens (often called a nonce) tied to user sessions. A common implementation is the synchronizer token pattern, where a unique token is embedded in forms and verified on the server.
SameSite cookies — restricts when cookies are sent with cross-site requests, supporting secure cookie based session handling to help prevent CSRF.
Double-submit cookies — match a cookie and hidden form field.
Secondary confirmation — requiring re-authentication or CAPTCHA for sensitive actions.
Least privilege — don’t stay logged in as an admin unnecessarily.
Referer header validation — check the referer header to ensure requests originate from trusted sources, though this is not foolproof due to possible spoofing or privacy settings.
Custom headers — require a custom header (e.g., X-Csrf-Token) on requests, as browsers only allow scripts from the same site to set custom headers, helping differentiate legitimate requests and strengthen CSRF defenses.
Accept POST requests — configure applications to accept post requests only for state-changing actions, but note that this alone does not fully prevent CSRF.
Same domain and same origin policy — restrict sensitive actions to the same domain and enforce the browser’s same origin policy to prevent cross origin requests from executing protected operations.

Key Lessons from the OpenX Incident

The OpenX case is still a textbook example of CSRF exploitation, and its lessons remain painfully relevant:

Unpatched flaws don’t vanish — they get exploited. Even known vulns can linger for years in enterprise apps.
Vendors don’t always fix quickly. OpenX never issued a clear patch statement, leaving thousands exposed.
CSRF isn’t just theoretical. It can — and has — been weaponized to deliver malware at scale.
Today’s enterprises still struggle with patching. Bureaucracy, legacy systems, and resource constraints mean many orgs remain vulnerable.
If a web console is exposed and lacks proper protections, attackers can exploit CSRF to perform sensitive actions remotely.
If automatic credential sharing is enabled, attacks may exploit windows domain credentials, increasing the risk of unauthorized access.
It is critical that the server validates all sensitive requests, such as those involving user credentials or fund transfers, to prevent CSRF attacks.

Conclusion

Cross Site Request Forgery is a classic web application vulnerability and has been abused in many high profile hacks. The OpenX exploit shows how attackers leveraged a simple CSRF flaw to create admin accounts, inject backdoors, and hijack advertising networks.

CSRF may be decades old, but it’s still one of the simplest and most devastating ways attackers can turn trust against us.