glow-all/true-headless-browser

Fork 0

Sprint 24: AWS WAF Challenge lösen — CSS/Layout-Fakes + Async-Drain (Option A) #90

New issue

Closed

opened 2026-06-19 05:25:55 +00:00 by Artur · 1 comment

Artur commented

2026-06-19 05:25:55 +00:00

Owner

Problembeschreibung

amazon.de (und weitere AWS WAF-geschützte Seiten) erhalten keinen Content — der WAF-JavaScript-Challenge-Token wird nicht korrekt gelöst.

Aktuelle Messung:

1  https://amazon.de   ✅ PASS   650ms    1.9KB    4     1    0

Die 1.9KB sind ausschließlich die WAF-Challenge-Seite (kein Amazon-Content).

Debug-Ergebnisse (Sprint 19, Issue #86):

Test	Ergebnis
`new Function(challengeJS)` (Bun-Blank)	❌ `document is not defined`
`executeRaw(challengeJS)` mit `with(_win)`	✅ kein Error, aber `AwsWafIntegration` bleibt undefined
Nach 2s warten	`AwsWafIntegration` immer noch undefined
Pre-code + Full-code schrittweise	Kein Error, kein Global gesetzt
Challenge.js Größe	1.353.233 Bytes (1.35MB)

Warum der Code nicht durchläuft

Die Challenge-JS ist eine generator-basierte async State-Machine:

Stats:
  _0xe31008 (generator runner):    25 occurrences
  Promise:                         28 occurrences
  catch/:                         119 occurrences
  setTimeout:                       7 occurrences
  setInterval:                      1 occurrence
  generator:                       32 occurrences
  yield/next:                      via _0x378045 (async step runner)

Struktur:

(function() {
  // 1. String-Array-Dekodierung (1.35MB)
  // 2. Hilfsfunktionen definieren
  // 3. Crypto-Proof-of-Work (crypto.getRandomValues)
  // 4. fetch() an WAF-Backend mit challenge response
  // 5. Token parsen
  // 6. **ASYNC**: window['AwsWafIntegration'] = ...
  // 7. callback: window.location.reload(true)
})();

Die window.AwsWafIntegration-Zuweisung ist innerhalb des async generators, nicht am Ende des IIFE. Der Code:

Lädt synchrone Definitions (OK ✅ — keine Fehler)
Startet async generator via _0xe31008(generator)() (OK ✅ — startet)
Generator yielded für crypto + fetch + timers (❌ — hängt/scheitert async)
👉 AwsWafIntegration wird nie gesetzt

Root-Cause-Analyse

Die Challenge-JS ist identisch mit AWS WAF SDK (token.awswaf.com). Sie implementiert einen vollständigen Challenge-Token-Flow:

Browser → HTTP GET amazon.de → 202 + x-amzn-waf-action: challenge
  → Challenge-Page (HTML mit challenge.js)
  → challenge.js startet Proof-of-Work (CPU + crypto.getRandomValues)
  → Berechnet Challenge-Response + signiert sie
  → fetch() POST an WAF-Backend (AWS API Gateway)
  → Backend validiert → gibt Token zurück
  → Token wird in Cookie gespeichert
  → window.location.reload(true)
  → Reload mit Cookie → echter Content

Warum es bei uns scheitert (Hypothesen):

Hypothese A: Fehlende CSS/Layout-APIs (wahrscheinlich)

Die Challenge prüft Browser-Umgebung via:

document.scripts.length → haben wir ✅
document.querySelector('script[src*="challenge"]') → haben wir ✅
element.offsetWidth / offsetHeight → Happy DOM gibt immer 0 ❌
element.getBoundingClientRect() → alle Werte = 0 ❌
window.matchMedia(...) → vorhanden aber keine Media-Query-Auswertung ❌

In einem echten Browser hat sogar ein leeres <body> non-zero offsetHeight. Viele Anti-Bot-Systeme nutzen Layout-basierte Checks als Browser-Fingerabdruck.

Hypothese B: fetch() ans WAF-Backend scheitert (sehr wahrscheinlich)

Nach dem Proof-of-Work macht challenge.js fetch() an:

POST https://1c5c1ecf7303.7a63328c.eu-central-1.token.awswaf.com/...

Wenn dieser Request fehlschlägt (falsche Headers, fehlende CORS-Credentials, falscher Body), hängt der async generator im Retry-Loop.

Hypothese C: Promise-Microtask-Timing (möglich)

Unsere with(_win) + eval()-Realm könnte Promise-Microtask-Queue anders behandeln als ein Browser. Wenn Generator-Yields aufgelöst werden müssen aber Microtasks nicht korrekt flushen, bleibt der Generator stehen.

Hypothese D: window.setTimeout / setInterval (möglich)

Die Challenge hat 7 setTimeout und 1 setInterval Aufrufe. Wenn unsere Timer-Implementierung (VirtualFrameClock) nicht korrekt mit der Challenge interagiert, können Timeout-basierte Retry-Loops niemals feuern.

Lösungsansätze

Option A: Minimal-CSS/Layout-Engine + WAF-Adaption (empfohlen)

Konzept: Wir müssen nicht das volle CSS-Engine (Layout-Baum, Box-Modell, Painting) implementieren. Aber wir brauchen plausible Default-Werte für die APIs, die Anti-Bot-Systeme checken.

Phase 1: Browser-Fingerprint verbessern (~2h)

Implementiere realistische Defaults für CSS/Layout-APIs:

// Neue Fakes: browser-environment.ts
patchLayoutAPIs(win: Window, doc: Document): void {
  // 1. offsetWidth/Height: Simuliere realistische Elementgrößen
  // body = viewport, divs = normales Inline-Verhalten
  HTMLHtmlElement.prototype.offsetWidth = 1366;  // oder viewport
  HTMLHtmlElement.prototype.offsetHeight = 768;
  HTMLBodyElement.prototype.offsetWidth = 1366;
  HTMLBodyElement.prototype.offsetHeight = 768;
  
  // 2. getBoundingClientRect: Non-zero für root-Elemente
  // body.getBoundingClientRect() = {x:0, y:0, w:1366, h:768, ...}
  
  // 3. matchMedia: Implementiere basic Media-Query-Auswertung
  // window.matchMedia("(max-width: 768px)") → matches: false bei 1366px
  
  // 4. scrollTop / scrollY: = 0 (initial state, kein Scrolling)
  
  // 5. innerWidth / innerHeight: viewport (schon gesetzt: 1024x768)
  
  // 6. screen: width/height/colorDepth/availWidth/availHeight
}

Details zu matchMedia:

interface MediaQueryList {
  readonly matches: boolean;
  readonly media: string;
  addListener(callback: (e: MediaQueryListEvent) => void): void;
  removeListener(callback: (e: MediaQueryListEvent) => void): void;
  addEventListener(type: string, callback: EventListener): void;
  removeEventListener(type: string, callback: EventListener): void;
}

function evaluateMediaQuery(media: string, viewport: {width: number, height: number}): boolean {
  // Parse simple media queries:
  // (max-width: 768px) → viewport.width <= 768
  // (min-width: 769px) → viewport.width >= 769  
  // (prefers-color-scheme: dark) → false (oder konfigurierbar)
  // (pointer: coarse) → false (Desktop)
  // @media print → false
  // not all → false
  // Behandle auch complex queries mit and/or/not
}

Phase 2: Hybrid Fetch mit korrekten WAF-Headers (~2h)

Der challenge.js fetch() ans WAF-Backend muss als "same-origin" behandelt werden (es ist eine CloudFront-Eigenschaft der gleichen Site):

// In RequestManager: WAF-Domain erkennen und korrekte CORS/Cookie-Headers setzen
wafDomainPattern = /\.token\.awswaf\.com$/;
if (wafDomainPattern.test(url.hostname)) {
  credentials: 'include',  // Cookie-Mitgabe
  mode: 'same-origin',     // Simuliere same-origin
  // Wichtig: Kein CORS-Preflight
}

Alternative: AWS WAF Challenge-Request direkt ohne CORS-Prüfung erlauben.

Phase 3: Async-Generator-Drain (~1h)

Nachdem challenge.js per executeRaw() geladen wurde, müssen wir den async-Teil abwarten:

// In parser.ts oder page.ts, nach executeRaw für blocking scripts:
after executeRaw(challengeJS) {
  // 1. Warte auf flushende Microtasks (Promise-Ticks)
  await new Promise(resolve => setTimeout(resolve, 100));
  
  // 2. Checke regelmäßig ob AwsWafIntegration gesetzt wurde
  const maxWait = 10000; // 10s timeout
  const start = Date.now();
  while (!win.AwsWafIntegration && Date.now() - start < maxWait) {
    await new Promise(resolve => setTimeout(resolve, 50));
    // Force microtask flush
    await Promise.resolve();
  }
  
  // 3. Wenn Token vorhanden: Cookie setzen + Reload
  if (win.AwsWafIntegration?.getToken) {
    const token = await win.AwsWafIntegration.getToken();
    if (token) {
      document.cookie = `aws-waf-token=${token}; path=/; domain=.amazon.de`;
      // Page-Reload mit Token-Cookie → echter Content
    }
  }
}

Phase 4: Verifikation und Tests (~1h)

it("amazon.de passes WAF challenge and gets >50KB DOM", async () => {
  const result = await crawl("https://amazon.de");
  expect(result.domSize).toBeGreaterThan(50 * 1024); // >50KB
  expect(result.status).toBe("pass");
  expect(result.pageErrors).toHaveLength(0);
});

Option B: Reines fetch()-Intercept + Token-Injection

Statt die ganze Challenge-JS auszuführen, intercepte den fetch()-Call ans WAF-Backend und antworte mit einem synthetischen Token:

// In RequestManager oder ServiceWorker-artigem Interceptor
interceptWAFRequest(request: Request): Response | null {
  if (request.url.includes('token.awswaf.com') && request.method === 'POST') {
    // Token direkt generieren (geht nicht — crypto-proof-of-work)
    // ODER: Token aus vorherigem Browser-Session wiederverwenden
    return new Response(tokenResponse, {
      headers: { 'content-type': 'application/json' }
    });
  }
  return null;
}

Nachteil: Crypto-Proof-of-Work kann nicht simuliert werden — signierter Token nicht synthetisierbar. Der WAF-Backend verifiziert die Signatur. Ohne echten Proof-of-Work wird der Request abgewiesen.

👉 Option B scheitert, weil wir den Crypto-Teil nicht falschen können.

Option C: Hybrider Ansatz — Playwright für initiale WAF-Seite

flowchart TD
    A[Request amazon.de] --> B{HTTP 202 + \nwaf-action: challenge?}
    B -- Nein --> C[Normaler Engine-Workflow]
    B -- Ja --> D[Playwright öffnen + Challenge lösen]
    D --> E[Cookies exportieren]
    E --> F[Cookie in Engine injizieren]
    F --> G[Reload amazon.de mit Cookie]
    G --> H{Erfolg?}
    H -- Ja --> I[Normal weiter]

Nachteil: Playwright-Abhängigkeit, Performance (braucht echten Browser), Komplexität.

Option D: Systematische Browser-API-Kompatibilität (Ultimativ)

Erstelle eine Browser-API-Gap-Analyse und implementiere alle fehlenden APIs systematisch (nicht nur für WAF):

// roadmap-apis.ts
export const missingAPIs: APIGap[] = [
  {
    api: 'matchMedia',
    status: 'exists',
    quality: 'minimal',  // existiert, aber evaluiert keine media-queries
    priority: 'high',
  },
  {
    api: 'getComputedStyle',
    status: 'exists',
    quality: 'minimal',  // gibt keine CSS-Cascade zurück
    priority: 'medium',
  },
  {
    api: 'offsetWidth/Height',
    status: 'exists',
    quality: 'always-0',  // immer 0 ohne Layout
    priority: 'high',
  },
  {
    api: 'getBoundingClientRect',
    status: 'exists',
    quality: 'always-0',
    priority: 'high',
  },
  // ... plus 100+ weitere
];

Aufwand: ~2-3 Wochen für vollständige Abdeckung. Zu viel für Issue #86.

Empfohlener Ansatz: Option A (Phasen 1+2+3)

Warum Option A:

Minimaler Aufwand (~5h) für maximalen Effekt
CSS/Layout-Checks sind der #1-Fingerabdruck für Anti-Bot-Systeme (siehe Blog-Artikel)
Async-Generator-Drain ist notwendig für JEDE generator-basierte WAF/Challenge
Phasen bauen aufeinander auf — jede Phase alleine bringt Verbesserung
Nichts an der Core-Engine ändern (alles über Fakes/Patches)

Phasen-Zeitplan:

Phase	Beschreibung	Aufwand	Gegen
1	Browser-Fingerprint (CSS/Layout-Defaults)	~2h	20%
2	Hybrid Fetch für WAF-Requests	~2h	40%
3	Async-Generator-Drain + Reload	~1h	70%
4	Verifikation + Tests	~1h	90%
	Restrisiko (WAF ändert challenge-Struktur)	—	10%

Akzeptanzkriterien

AwsWafIntegration wird innerhalb von 10s nach executeRaw() gesetzt
Token wird via getToken() erfolgreich abgerufen
Cookie aws-waf-token wird korrekt gesetzt
Reload mit Token-Cookie liefert >50KB DOM
matchMedia("(max-width: 768px)") evaluiert korrekt
element.getBoundingClientRect() liefert non-zero für body/html
Keine Regression bei anderen Sites (1519+ Tests weiterhin grün)
Keine neuen Console-Errors durch die Fakes

Betroffene Dateien

Datei	Änderung	Phase
`src/fakes/browser-environment.ts`	NEU — CSS/Layout-Fakes + matchMedia	1
`src/fakes/navigator.ts`	Erweitern um screen/device-APIs	1
`src/pages/request-manager.ts`	WAF-Domain erkennen + Credentials	2
`src/dom/parser.ts`	Async-Drain nach executeRaw(blockingJS)	3
`src/pages/page.ts`	WAF-Token erkennen + Reload-Trigger	3
`tests/integration/amazon-waf.test.ts`	NEU — Integrationstest	4

Technische Risiken

Risiko	Wahrscheinlichkeit	Mitigation
Amazon ändert WAF-Struktur	Mittel	Phase 1+2 sind generisch (nicht WAF-spezifisch)
Crypto-Proof-of-Work erfordert Web Crypto API (subtle)	Gering	`crypto.subtle` existiert in Happy DOM bereits
Reload-Mechanismus in Page.ts nicht korrekt	Mittel	Reload = neuen Page-Lauf starten (existiert bereits)
Async-Drain blockt gesamte Page-Load	Niedrig	Timeout von 10s, danach Graceful Fallback

Dependencies

Issue #85 (Scripts im DOM) ✅ gelöst — Grundlage für WAF-Seite
Issue #84 (NameTooLong) ✅ gelöst — 1.35MB challenge.js wird korrekt geladen

Querverweise

AWS WAF JavaScript Challenge Dokumentation
Blog-Artikel: "The real problem isn't JS — it's CSS" (User-geteilt)
Issue #37 (Sprint 10): Browser-Identitäts-Fakes

## Problembeschreibung amazon.de (und weitere AWS WAF-geschützte Seiten) erhalten keinen Content — der WAF-JavaScript-Challenge-Token wird nicht korrekt gelöst. **Aktuelle Messung:** ``` 1 https://amazon.de ✅ PASS 650ms 1.9KB 4 1 0 ``` Die 1.9KB sind ausschließlich die WAF-Challenge-Seite (kein Amazon-Content). **Debug-Ergebnisse (Sprint 19, Issue #86):** | Test | Ergebnis | |------|----------| | `new Function(challengeJS)` (Bun-Blank) | ❌ `document is not defined` | | `executeRaw(challengeJS)` mit `with(_win)` | ✅ kein Error, **aber `AwsWafIntegration` bleibt undefined** | | Nach 2s warten | `AwsWafIntegration` immer noch undefined | | Pre-code + Full-code schrittweise | Kein Error, kein Global gesetzt | | Challenge.js Größe | **1.353.233 Bytes** (1.35MB) | ### Warum der Code nicht durchläuft Die Challenge-JS ist eine **generator-basierte async State-Machine**: ``` Stats: _0xe31008 (generator runner): 25 occurrences Promise: 28 occurrences catch/: 119 occurrences setTimeout: 7 occurrences setInterval: 1 occurrence generator: 32 occurrences yield/next: via _0x378045 (async step runner) ``` **Struktur:** ```js (function() { // 1. String-Array-Dekodierung (1.35MB) // 2. Hilfsfunktionen definieren // 3. Crypto-Proof-of-Work (crypto.getRandomValues) // 4. fetch() an WAF-Backend mit challenge response // 5. Token parsen // 6. **ASYNC**: window['AwsWafIntegration'] = ... // 7. callback: window.location.reload(true) })(); ``` Die `window.AwsWafIntegration`-Zuweisung ist **innerhalb des async generators**, nicht am Ende des IIFE. Der Code: 1. Lädt synchrone Definitions (OK ✅ — keine Fehler) 2. Startet async generator via `_0xe31008(generator)()` (OK ✅ — startet) 3. Generator yielded für crypto + fetch + timers (❌ — hängt/scheitert async) 4. 👉 `AwsWafIntegration` wird **nie gesetzt** ## Root-Cause-Analyse Die Challenge-JS ist identisch mit AWS WAF SDK (token.awswaf.com). Sie implementiert einen vollständigen Challenge-Token-Flow: ``` Browser → HTTP GET amazon.de → 202 + x-amzn-waf-action: challenge → Challenge-Page (HTML mit challenge.js) → challenge.js startet Proof-of-Work (CPU + crypto.getRandomValues) → Berechnet Challenge-Response + signiert sie → fetch() POST an WAF-Backend (AWS API Gateway) → Backend validiert → gibt Token zurück → Token wird in Cookie gespeichert → window.location.reload(true) → Reload mit Cookie → echter Content ``` **Warum es bei uns scheitert (Hypothesen):** ### Hypothese A: Fehlende CSS/Layout-APIs (wahrscheinlich) Die Challenge prüft Browser-Umgebung via: - `document.scripts.length` → haben wir ✅ - `document.querySelector('script[src*="challenge"]')` → haben wir ✅ - **`element.offsetWidth / offsetHeight`** → **Happy DOM gibt immer 0** ❌ - **`element.getBoundingClientRect()`** → **alle Werte = 0** ❌ - **`window.matchMedia(...)`** → vorhanden aber **keine Media-Query-Auswertung** ❌ In einem echten Browser hat sogar ein leeres `<body>` non-zero `offsetHeight`. Viele Anti-Bot-Systeme nutzen Layout-basierte Checks als Browser-Fingerabdruck. ### Hypothese B: fetch() ans WAF-Backend scheitert (sehr wahrscheinlich) Nach dem Proof-of-Work macht challenge.js `fetch()` an: ``` POST https://1c5c1ecf7303.7a63328c.eu-central-1.token.awswaf.com/... ``` Wenn dieser Request fehlschlägt (falsche Headers, fehlende CORS-Credentials, falscher Body), hängt der async generator im Retry-Loop. ### Hypothese C: Promise-Microtask-Timing (möglich) Unsere `with(_win)` + `eval()`-Realm könnte Promise-Microtask-Queue anders behandeln als ein Browser. Wenn Generator-Yields aufgelöst werden müssen aber Microtasks nicht korrekt flushen, bleibt der Generator stehen. ### Hypothese D: window.setTimeout / setInterval (möglich) Die Challenge hat 7 `setTimeout` und 1 `setInterval` Aufrufe. Wenn unsere Timer-Implementierung (VirtualFrameClock) nicht korrekt mit der Challenge interagiert, können Timeout-basierte Retry-Loops niemals feuern. ## Lösungsansätze ### Option A: Minimal-CSS/Layout-Engine + WAF-Adaption (empfohlen) **Konzept:** Wir müssen nicht das volle CSS-Engine (Layout-Baum, Box-Modell, Painting) implementieren. Aber wir brauchen **plausible Default-Werte** für die APIs, die Anti-Bot-Systeme checken. #### Phase 1: Browser-Fingerprint verbessern (~2h) Implementiere realistische Defaults für CSS/Layout-APIs: ```typescript // Neue Fakes: browser-environment.ts patchLayoutAPIs(win: Window, doc: Document): void { // 1. offsetWidth/Height: Simuliere realistische Elementgrößen // body = viewport, divs = normales Inline-Verhalten HTMLHtmlElement.prototype.offsetWidth = 1366; // oder viewport HTMLHtmlElement.prototype.offsetHeight = 768; HTMLBodyElement.prototype.offsetWidth = 1366; HTMLBodyElement.prototype.offsetHeight = 768; // 2. getBoundingClientRect: Non-zero für root-Elemente // body.getBoundingClientRect() = {x:0, y:0, w:1366, h:768, ...} // 3. matchMedia: Implementiere basic Media-Query-Auswertung // window.matchMedia("(max-width: 768px)") → matches: false bei 1366px // 4. scrollTop / scrollY: = 0 (initial state, kein Scrolling) // 5. innerWidth / innerHeight: viewport (schon gesetzt: 1024x768) // 6. screen: width/height/colorDepth/availWidth/availHeight } ``` **Details zu matchMedia:** ```typescript interface MediaQueryList { readonly matches: boolean; readonly media: string; addListener(callback: (e: MediaQueryListEvent) => void): void; removeListener(callback: (e: MediaQueryListEvent) => void): void; addEventListener(type: string, callback: EventListener): void; removeEventListener(type: string, callback: EventListener): void; } function evaluateMediaQuery(media: string, viewport: {width: number, height: number}): boolean { // Parse simple media queries: // (max-width: 768px) → viewport.width <= 768 // (min-width: 769px) → viewport.width >= 769 // (prefers-color-scheme: dark) → false (oder konfigurierbar) // (pointer: coarse) → false (Desktop) // @media print → false // not all → false // Behandle auch complex queries mit and/or/not } ``` #### Phase 2: Hybrid Fetch mit korrekten WAF-Headers (~2h) Der challenge.js `fetch()` ans WAF-Backend muss als "same-origin" behandelt werden (es ist eine CloudFront-Eigenschaft der gleichen Site): ```typescript // In RequestManager: WAF-Domain erkennen und korrekte CORS/Cookie-Headers setzen wafDomainPattern = /\.token\.awswaf\.com$/; if (wafDomainPattern.test(url.hostname)) { credentials: 'include', // Cookie-Mitgabe mode: 'same-origin', // Simuliere same-origin // Wichtig: Kein CORS-Preflight } ``` **Alternative:** AWS WAF Challenge-Request direkt ohne CORS-Prüfung erlauben. #### Phase 3: Async-Generator-Drain (~1h) Nachdem challenge.js per `executeRaw()` geladen wurde, müssen wir den async-Teil abwarten: ```typescript // In parser.ts oder page.ts, nach executeRaw für blocking scripts: after executeRaw(challengeJS) { // 1. Warte auf flushende Microtasks (Promise-Ticks) await new Promise(resolve => setTimeout(resolve, 100)); // 2. Checke regelmäßig ob AwsWafIntegration gesetzt wurde const maxWait = 10000; // 10s timeout const start = Date.now(); while (!win.AwsWafIntegration && Date.now() - start < maxWait) { await new Promise(resolve => setTimeout(resolve, 50)); // Force microtask flush await Promise.resolve(); } // 3. Wenn Token vorhanden: Cookie setzen + Reload if (win.AwsWafIntegration?.getToken) { const token = await win.AwsWafIntegration.getToken(); if (token) { document.cookie = `aws-waf-token=${token}; path=/; domain=.amazon.de`; // Page-Reload mit Token-Cookie → echter Content } } } ``` #### Phase 4: Verifikation und Tests (~1h) ```typescript it("amazon.de passes WAF challenge and gets >50KB DOM", async () => { const result = await crawl("https://amazon.de"); expect(result.domSize).toBeGreaterThan(50 * 1024); // >50KB expect(result.status).toBe("pass"); expect(result.pageErrors).toHaveLength(0); }); ``` --- ### Option B: Reines fetch()-Intercept + Token-Injection Statt die ganze Challenge-JS auszuführen, intercepte den fetch()-Call ans WAF-Backend und antworte mit einem synthetischen Token: ```typescript // In RequestManager oder ServiceWorker-artigem Interceptor interceptWAFRequest(request: Request): Response | null { if (request.url.includes('token.awswaf.com') && request.method === 'POST') { // Token direkt generieren (geht nicht — crypto-proof-of-work) // ODER: Token aus vorherigem Browser-Session wiederverwenden return new Response(tokenResponse, { headers: { 'content-type': 'application/json' } }); } return null; } ``` **Nachteil:** Crypto-Proof-of-Work kann nicht simuliert werden — signierter Token nicht synthetisierbar. Der WAF-Backend verifiziert die Signatur. Ohne echten Proof-of-Work wird der Request abgewiesen. **👉 Option B scheitert, weil wir den Crypto-Teil nicht falschen können.** --- ### Option C: Hybrider Ansatz — Playwright für initiale WAF-Seite ```mermaid flowchart TD A[Request amazon.de] --> B{HTTP 202 + \nwaf-action: challenge?} B -- Nein --> C[Normaler Engine-Workflow] B -- Ja --> D[Playwright öffnen + Challenge lösen] D --> E[Cookies exportieren] E --> F[Cookie in Engine injizieren] F --> G[Reload amazon.de mit Cookie] G --> H{Erfolg?} H -- Ja --> I[Normal weiter] ``` **Nachteil:** Playwright-Abhängigkeit, Performance (braucht echten Browser), Komplexität. --- ### Option D: Systematische Browser-API-Kompatibilität (Ultimativ) Erstelle eine Browser-API-Gap-Analyse und implementiere alle fehlenden APIs systematisch (nicht nur für WAF): ```typescript // roadmap-apis.ts export const missingAPIs: APIGap[] = [ { api: 'matchMedia', status: 'exists', quality: 'minimal', // existiert, aber evaluiert keine media-queries priority: 'high', }, { api: 'getComputedStyle', status: 'exists', quality: 'minimal', // gibt keine CSS-Cascade zurück priority: 'medium', }, { api: 'offsetWidth/Height', status: 'exists', quality: 'always-0', // immer 0 ohne Layout priority: 'high', }, { api: 'getBoundingClientRect', status: 'exists', quality: 'always-0', priority: 'high', }, // ... plus 100+ weitere ]; ``` **Aufwand:** ~2-3 Wochen für vollständige Abdeckung. Zu viel für Issue #86. --- ## Empfohlener Ansatz: Option A (Phasen 1+2+3) **Warum Option A:** 1. Minimaler Aufwand (~5h) für maximalen Effekt 2. CSS/Layout-Checks sind der #1-Fingerabdruck für Anti-Bot-Systeme (siehe Blog-Artikel) 3. Async-Generator-Drain ist notwendig für JEDE generator-basierte WAF/Challenge 4. Phasen bauen aufeinander auf — jede Phase alleine bringt Verbesserung 5. Nichts an der Core-Engine ändern (alles über Fakes/Patches) **Phasen-Zeitplan:** | Phase | Beschreibung | Aufwand | Gegen | |-------|-------------|:-------:|:-----:| | 1 | Browser-Fingerprint (CSS/Layout-Defaults) | ~2h | 20% | | 2 | Hybrid Fetch für WAF-Requests | ~2h | 40% | | 3 | Async-Generator-Drain + Reload | ~1h | 70% | | 4 | Verifikation + Tests | ~1h | 90% | | | **Restrisiko** (WAF ändert challenge-Struktur) | — | 10% | ## Akzeptanzkriterien - [ ] `AwsWafIntegration` wird innerhalb von 10s nach `executeRaw()` gesetzt - [ ] Token wird via `getToken()` erfolgreich abgerufen - [ ] Cookie `aws-waf-token` wird korrekt gesetzt - [ ] Reload mit Token-Cookie liefert >50KB DOM - [ ] `matchMedia("(max-width: 768px)")` evaluiert korrekt - [ ] `element.getBoundingClientRect()` liefert non-zero für body/html - [ ] Keine Regression bei anderen Sites (1519+ Tests weiterhin grün) - [ ] Keine neuen Console-Errors durch die Fakes ## Betroffene Dateien | Datei | Änderung | Phase | |-------|----------|:-----:| | `src/fakes/browser-environment.ts` | **NEU** — CSS/Layout-Fakes + matchMedia | 1 | | `src/fakes/navigator.ts` | Erweitern um screen/device-APIs | 1 | | `src/pages/request-manager.ts` | WAF-Domain erkennen + Credentials | 2 | | `src/dom/parser.ts` | Async-Drain nach executeRaw(blockingJS) | 3 | | `src/pages/page.ts` | WAF-Token erkennen + Reload-Trigger | 3 | | `tests/integration/amazon-waf.test.ts` | **NEU** — Integrationstest | 4 | ## Technische Risiken | Risiko | Wahrscheinlichkeit | Mitigation | |--------|:------------------:|------------| | Amazon ändert WAF-Struktur | Mittel | Phase 1+2 sind generisch (nicht WAF-spezifisch) | | Crypto-Proof-of-Work erfordert Web Crypto API (subtle) | Gering | `crypto.subtle` existiert in Happy DOM bereits | | Reload-Mechanismus in Page.ts nicht korrekt | Mittel | Reload = neuen Page-Lauf starten (existiert bereits) | | Async-Drain blockt gesamte Page-Load | Niedrig | Timeout von 10s, danach Graceful Fallback | ## Dependencies - Issue #85 (Scripts im DOM) ✅ gelöst — Grundlage für WAF-Seite - Issue #84 (NameTooLong) ✅ gelöst — 1.35MB challenge.js wird korrekt geladen ## Querverweise - [AWS WAF JavaScript Challenge Dokumentation](https://docs.aws.amazon.com/waf/latest/developerguide/waf-js-challenge.html) - Blog-Artikel: "The real problem isn't JS — it's CSS" (User-geteilt) - Issue #37 (Sprint 10): Browser-Identitäts-Fakes

Artur added the

bug

label

2026-06-19 05:25:55 +00:00

Artur referenced this issue from a commit

2026-06-19 06:23:42 +00:00

Sprint 22 — Issue #90: Amazon WAF Spec-Gaps geschlossen (8 Fixes)

Artur referenced this issue from a commit

2026-06-19 07:05:08 +00:00

Sprint 22 — Issue #90: Canvas Recording + Known-Answer-Table + 100% Spec Canvas2D

Artur referenced this issue from a commit

2026-06-19 07:21:21 +00:00

Sprint 22 — Issue #90: AudioContext Recording+KAT + Canvas2D KAT + addRequestInterceptor

Artur referenced this issue from a commit

2026-06-19 10:17:30 +00:00

fix #90: Microtask-Drain nach blocking Scripts — generischer Async-Generator-Support

Artur closed this issue

2026-06-19 10:17:30 +00:00

Artur commented

2026-06-19 10:17:40 +00:00

Author

Owner

Generischer Fix in Commit cc42ee2 ✅

Problem: Async generator runners (WAF Challenge-JS, Cloudflare Turnstile) hingen nach executeRaw() im Microtask-Queue. Der Parser ging direkt zum nächsten Script — der Generator bekam nie einen Tick.

Lösung (generisch — nicht WAF-spezifisch):

drainMicrotasks() nach jedem blocking Script executeRaw()
5 Runden Promise.resolve().then(...) flushen Microtask-Queues
Genug für: async generator.next(), Promise-Ketten, crypto.subtle, setTimeout
Hilft ALLEN generator-basierten Scripts

Bereits vorhanden (Sprint 23b):

location.reload() patched → funktioniert nach Token-Erhalt
FakeLayout mit offsetWidth/Height/getBoundingClientRect/matchMedia
SubtleCrypto Chrome-kompatibel
fetch() mit CookieJar + Chrome-Headern

Nächster Schritt: Amazon.de-Crawl testen ob >50KB DOM erreicht wird.

**Generischer Fix in Commit cc42ee2** ✅ **Problem:** Async generator runners (WAF Challenge-JS, Cloudflare Turnstile) hingen nach `executeRaw()` im Microtask-Queue. Der Parser ging direkt zum nächsten Script — der Generator bekam nie einen Tick. **Lösung (generisch — nicht WAF-spezifisch):** - `drainMicrotasks()` nach jedem blocking Script executeRaw() - 5 Runden `Promise.resolve().then(...)` flushen Microtask-Queues - Genug für: async generator.next(), Promise-Ketten, crypto.subtle, setTimeout - Hilft ALLEN generator-basierten Scripts **Bereits vorhanden (Sprint 23b):** - `location.reload()` patched → funktioniert nach Token-Erhalt - `FakeLayout` mit offsetWidth/Height/getBoundingClientRect/matchMedia - `SubtleCrypto` Chrome-kompatibel - `fetch()` mit CookieJar + Chrome-Headern **Nächster Schritt:** Amazon.de-Crawl testen ob >50KB DOM erreicht wird.

Artur referenced this issue from a commit

2026-06-19 10:50:04 +00:00

fix #90: Fundamentales fix — Execution Realm + Proxy has-Trap