XSS → JIT → Sandbox Escape

The most extreme attack chain for browser security (architecture-level analysis)

• This is the typical route for Country Level Vulnerability/Pwn2Own/Chrome 0day
• It’s not something ordinary hackers or business security can do.

1. First, I will give you an "Attack Height Map"

Web 页面（JS / XSS）
 ├─ JS 执行权限（最低）
 │
 ↓ 利用引擎 Bug
 │
V8 JIT（内存破坏）
 ├─ 读写 Renderer 内存
 │
 ↓ 逃逸 JS 沙箱
 │
Renderer 进程
 ├─ OS 沙箱限制
 │
 ↓ 利用系统 / IPC Bug
 │
Browser / OS（完全失陷）

👉 Chrome’s goal is not to be “perfectly safe”, but to:

• Make each layer extremely difficult, extremely unstable, and extremely impractical

2. The first step: XSS - why it is just the "starting point"

1️⃣ What exactly does XSS give the attacker?

Only this:

• 👉 Execute JS in the Renderer process of a certain site

After XSS you "still can't":

• Visit other sites
• Read browser memory
• Tuning system API
• Break through the same origin
• Access OS

👉 XSS itself ≠ Sandbox escape

2️⃣ So why is XSS still dangerous?

Because:

• JS is JIT compiled
• JIT = complex + high authority + many historical vulnerabilities

3. The second step: JIT - the real "breaking point"

• JIT is an important attack surface, but a fixed share of browser vulnerabilities requires a source and defined dataset.V8 security context.

1️⃣ What is JIT doing?

For the sake of performance, V8 will make radical assumptions:

function add(a, b) {
  return a + b
}

JIT may assume:

• a is always number
• b is always number
• No type checking required

2️⃣The nature of JIT vulnerabilities (very important)

There is only one core question:

• "Engine assumptions ≠ actual operation"

Typical vulnerability types:

• Type Confusion
• Out-of-Bounds
• Use-after-free

3️⃣ What happens once the JIT is broken down?

⚠️ This is the point of qualitative change

JS from:

受限语言

becomes:

可控内存读写

An attacker can:

• Read any Renderer memory
• Write arbitrary Renderer memory
• Construct fake object
• Hijack execution flow

👉 JS security model ends here

4️⃣ Why is this the “hardest step”?

Because:

• JIT is very complex
• Vulnerability version is strongly related
• Extremely unstable to use
• Chrome is often repaired

So:

• This step is usually 0day

4. The third step: Renderer sandbox - the final "iron gate"

Even if you:

• Can read and write memory
• Can execute arbitrary code

You are still at:

Renderer Process（OS Sandbox）

1️⃣ What are the limitations of the Renderer sandbox?

Even native code:

• ❌ File system
• ❌ Network socket
• ❌ System call
• ❌ Process operations

👉 You are the "root behind bars"

2️⃣ How to escape from the sandbox?

Can only pass:

• Chrome IPC interface
• kernel vulnerability
• GPU/driver vulnerability
• Browser Process logic vulnerability

Renderer → Browser（IPC）

⚠️ The Browser process is:

• High authority
• small entrance
• Strict verification

3️⃣ Why is this step more difficult?

Because:

• Few IPC interfaces
• Strict parameter verification
• The attack surface is extremely compressed
• The OS sandbox is a system-level

👉 This step is usually a "kernel-level vulnerability"

5. Why Chrome’s defense is “layered failure security”

Chrome does not assume:

• XSS will not happen
• JIT has no loopholes
• OS has no bugs

Instead, assume:

• Each layer will be broken through, but not all at once

Real-life defense strategies for Chrome

Layers	Defense Objectives
XSS	CSP / Frame Escape
JS	Language restrictions
JIT	Deopt / Audit
Renderer	OS Sandbox
Site Isolation	Process Isolation
OS	Permission isolation

6. Why do “front-end engineers” also need to understand this chain?

because you are here Increase or decrease attack surface ：

Behavior	Impact
eval	Expand JIT attack surface
Dynamic script	Expand execution scope
Third-party SDK	Introducing unknown JS
Close CSP	Tear down the first wall
Wasm	Reaching the Boundaries of JIT

👉 Security is not about "whether there are vulnerabilities", but "how big the attack surface is"

7. Real-world conclusions (very important)

• ❌ XSS ≠ The browser is compromised

• ❌ JS ≠ native code

• ❌ Wasm ≠ High authority

• ✅ Chrome assumes "attacks will definitely happen" and minimizes the impact through architecture

8. Interview/architecture level summary

XSS can only obtain JavaScript execution permissions within the site; true browser escape usually requires exploiting JIT compiler vulnerabilities to achieve memory corruption and break through the language sandbox; even so, it is still necessary to further bypass the Renderer's operating system-level sandbox before it can affect the browser or system. This multi-layered defense makes the complete attack chain extremely difficult.