Indirect eval (0, eval)() Escape — Known Limitation (unfixable per JS Spec) #70

New issue

Open

opened 2026-06-18 16:44:53 +00:00 by Artur · 1 comment

Artur commented

2026-06-18 16:44:53 +00:00

Owner

Indirect eval `(0, eval)()` Escape — Known Limitation

Problembeschreibung

(0, eval)("typeof Bun") (indirect eval) läuft per JavaScript-Spezifikation IMMER im globalen Scope, unabhängig von with()-Blöcken, Closure-Scopes oder Proxy-Tricks. Das ist ein fundamentaler Sprachmechanismus der nicht überschrieben oder abgefangen werden kann.

// LÄUFT IN BUN'S GLOBALEM SCOPE — sieht Bun, process, etc.
(0, eval)("typeof Bun") // → "object" (obwohl var Bun = void 0 gesetzt ist)

Warum ist das nicht fixbar?

eval in (0, eval) ist eine indirekte Referenz — der 0-Trick erzwingt globalen Scope
Der with(_win)-Block hat KEINE Kontrolle über indirect eval — das ist JS-Spec, Section 18.2.1
Selbst wenn wir _win.eval überschreiben: (0, eval) nutzt den ORIGINALEN eval aus dem globalen Realm
Einziger Fix: Prozess-Sandboxing (isolated-vm, Bun Worker — aktuell nicht geplant)

Impact

Praktisch irrelevant: Kaum eine Seite nutzt (0, eval)() — das ist ein Pattern für JavaScript-Compiler/Optimizer-Tools
Webseiten: UMD-Bundles nutzen this oder self zur globalen Detektion, nicht indirect eval
Sicherheit: Wenn Angreifer (0, eval) aufrufen können, haben sie schon andere Wege (XSS)

Akzeptanzkriterien

Als known limitation dokumentiert (dieses Issue)
Test in sprint14 oder sprint11 dokumentiert den Escape

Betroffene Dateien

Datei	Änderung
`tests/unit/sprint11-script-security.test.ts`	Test existiert: `(0, eval) escaped den with(_win)-Scope`

## Indirect eval `(0, eval)()` Escape — Known Limitation ### Problembeschreibung `(0, eval)("typeof Bun")` (indirect eval) läuft per JavaScript-Spezifikation IMMER im **globalen Scope**, unabhängig von `with()`-Blöcken, Closure-Scopes oder Proxy-Tricks. Das ist ein fundamentaler Sprachmechanismus der nicht überschrieben oder abgefangen werden kann. ```javascript // LÄUFT IN BUN'S GLOBALEM SCOPE — sieht Bun, process, etc. (0, eval)("typeof Bun") // → "object" (obwohl var Bun = void 0 gesetzt ist) ``` ### Warum ist das nicht fixbar? 1. `eval` in `(0, eval)` ist eine **indirekte Referenz** — der `0`-Trick erzwingt globalen Scope 2. Der `with(_win)`-Block hat KEINE Kontrolle über indirect eval — das ist JS-Spec, Section 18.2.1 3. Selbst wenn wir `_win.eval` überschreiben: `(0, eval)` nutzt den ORIGINALEN `eval` aus dem globalen Realm 4. Einziger Fix: Prozess-Sandboxing (isolated-vm, Bun Worker — aktuell nicht geplant) ### Impact - **Praktisch irrelevant:** Kaum eine Seite nutzt `(0, eval)()` — das ist ein Pattern für JavaScript-Compiler/Optimizer-Tools - **Webseiten:** UMD-Bundles nutzen `this` oder `self` zur globalen Detektion, nicht indirect eval - **Sicherheit:** Wenn Angreifer `(0, eval)` aufrufen können, haben sie schon andere Wege (XSS) ### Akzeptanzkriterien - [ ] Als known limitation dokumentiert (dieses Issue) - [ ] Test in `sprint14` oder `sprint11` dokumentiert den Escape ### Betroffene Dateien | Datei | Änderung | |-------|----------| | `tests/unit/sprint11-script-security.test.ts` | Test existiert: `(0, eval) escaped den with(_win)-Scope` |

Artur added the

bug

label

2026-06-18 16:44:53 +00:00

glow was assigned by Artur

2026-06-18 16:44:53 +00:00

Artur referenced this issue

2026-06-18 16:48:05 +00:00

Sprint 15.1: Dynamic import() in Page-Sandbox ausführen #71

Artur commented

2026-06-19 20:56:11 +00:00

Author

Owner

Stand: Hinzunehmende Limitation

`(0, eval)()`` escape ist ein JS-Spec-Problem, kein Bug. Chromium hat das gleiche Verhalten.

CSP-Phase 7 (#103, completed) hat unsafe-eval Sandbox-Patching eingeführt: window.eval wird bei fehlendem unsafe-eval durch eine throwing-Funktion ersetzt. Das blockt direkte eval()-Aufrufe, aber (0, eval)() ist per JS Spec nicht blockbar (ruft eval im globalen Scope auf, nicht im window-Scope).

Aktuelle Mitigation: 'unsafe-eval' in CSP-Policy erlauben, wenn die Seite eval-basierte Frameworks nutzt.

## Stand: Hinzunehmende Limitation `(0, eval)()`` escape ist ein JS-Spec-Problem, kein Bug. Chromium hat das gleiche Verhalten. CSP-Phase 7 (#103, completed) hat `unsafe-eval` Sandbox-Patching eingeführt: window.eval wird bei fehlendem `unsafe-eval` durch eine throwing-Funktion ersetzt. Das blockt direkte eval()-Aufrufe, aber `(0, eval)()` ist per JS Spec nicht blockbar (ruft eval im globalen Scope auf, nicht im window-Scope). Aktuelle Mitigation: `'unsafe-eval'` in CSP-Policy erlauben, wenn die Seite eval-basierte Frameworks nutzt.