Phase 3 — Abwehr

Phase 3 erstellt einen Vorher-/Nachher-Nachweis der CSD-Abwehr. Sie wiederholen den Angriff ohne Abwehrmaßnahmen, um eine Basislinie zu erstellen, wenden Abwehrmaßnahmen an und wiederholen denselben Angriff, um zu beweisen, dass CSD die Netzwerkaufrufe blockiert. Phase 2 muss abgeschlossen sein — alle DET-Prüfungen müssen BESTANDEN sein — bevor Sie fortfahren.

Hinweis

CSD-Abwehr blockiert das Laden von Skripten aus abgewehrten Domains. Wenn sich eine Domain auf der Abwehrliste befindet, fängt das CSD-JavaScript <script>-Tag-Quell-URLs ab und verhindert das Laden von Skripten — so werden Supply-Chain-Angriffe an der Quelle gestoppt. CSD fängt keine fetch()- oder XMLHttpRequest-Aufrufe ab. Diese Phase erfasst den Nachweis der Skriptblockierung, indem derselbe Angriff vor und nach der Abwehr ausgeführt wird.

Achtung

Hinweis zum Live-Testing: Die POST/DELETE-Endpunkte für die Abwehr wurden in Entwicklungsumgebungen validiert, jedoch können Details zum Verhalten (Antwortzeitpunkt, Auswirkung auf den Skripterkennungsstatus) je nach Mandantenkonfiguration variieren. Wenn Sie unerwartete Antworten beobachten, lesen Sie die API-Referenz für die maßgeblichen Endpunktdefinitionen.

Schritt 1: Keine aktiven Abwehrmaßnahmen bestätigen (Basislinie)

Bevor Sie den „Vorher”-Schnappschuss erfassen, stellen Sie sicher, dass die Umgebung sauber ist — es sollten keine Abwehrmaßnahmen aktiv sein. Dadurch wird gewährleistet, dass der Basislinienangriff ohne CSD-Blockierung ausgeführt wird.

Anzahl abgewehrter Domains prüfen

curl -s \
  -H "Authorization: APIToken xF5XC_API_TOKENx" \
  "xF5XC_API_URLx/api/shape/csd/namespaces/xF5XC_NAMESPACEx/mitigated_domains" \
  | jq '{count: (.items | length)}'

Wenn die Anzahl nicht 0 ist, sind Abwehrmaßnahmen aus einem früheren Durchlauf vorhanden. Löschen Sie jede davon, bevor Sie fortfahren:

# Eine abgewehrte Domain löschen (für jeden Domainnamen wiederholen)
curl -s -X DELETE \
  -H "Authorization: APIToken xF5XC_API_TOKENx" \
  "xF5XC_API_URLx/api/shape/csd/namespaces/xF5XC_NAMESPACEx/mitigated_domains/<domain-name>" \
  | jq .

Ersetzen Sie <domain-name> durch den metadata.name, der bei der Abwehr der Domain verwendet wurde (z. B. cdn.jsdelivr.net, esm.sh, unpkg.com, ga.jspm.io, httpbin.org, jsonplaceholder.typicode.com). Falls die Bereinigung von httpbin.org einen verbleibenden Eintrag hinterlässt, versuchen Sie auch, www.httpbin.org zu löschen — einige frühere Durchläufe haben möglicherweise diesen Namen als Metadatenname verwendet.

Bestätigen, dass Phase-2-Erkennungen vorhanden sind

curl -s \
  -H "Authorization: APIToken xF5XC_API_TOKENx" \
  "xF5XC_API_URLx/api/shape/csd/namespaces/xF5XC_NAMESPACEx/detected_domains" \
  | jq '{total_domains: .domain_summary.totalDomains, domains: [.domains_list[]? | {domain: .domain, category: .category}]}'

Nachweis

Prüfung	Erwartet	Status
Anzahl abgewehrter Domains	0 (saubere Basislinie)	BESTANDEN wenn 0, Bereinigung erforderlich wenn > 0
Anzahl erkannter Domains	> 0 (Phase-2-Erkennungen vorhanden)	BESTANDEN wenn > 0
Exfil-Domains vorhanden	www.httpbin.org, jsonplaceholder.typicode.com	BESTANDEN wenn mindestens eine erscheint

Schritt 2: Angriff ausführen — Vor der Abwehr

Führen Sie die kombinierte Simulation ohne aktive Abwehrmaßnahmen erneut aus, um eine aktuelle Basislinie zu erfassen. Dies ist der „Vorher”-Schnappschuss — Nachweis, dass Angriffe erfolgreich sind, wenn keine CSD-Abwehr angewendet wird.

Hinweis

Dieser Schritt erfordert die Ausführung von JavaScript im Browser — curl kann keine CSD-Erkennung auslösen. KI-Assistenten mit Browser-Automatisierungswerkzeugen (MCP Chrome DevTools, Playwright, Puppeteer) führen diese Schritte direkt über die nachfolgende KI-automatisierte Ausführungssequenz aus. Operatoren ohne Browser-Automatisierung führen die manuellen Schritte durch.

KI-automatisierte Ausführung

KI-Assistenten mit Browser-Automatisierungswerkzeugen führen die Angriffssimulation programmgesteuert mit demselben Phase-2-initScript aus (das das native fetch speichert):

1. Mit initScript navigieren — navigieren Sie zunächst zu about:blank, um einen sauberen Dokumentenkontext zu gewährleisten (verhindert veraltete initScripts aus früheren Navigationen), dann navigate_page zu http://$F5XC_DOMAINNAME/#/login mit dem Phase-2-initScript (wortwörtlicher Code in Phase 2 — KI-automatisierte Ausführung). Dieses initScript speichert das native setInterval, clearInterval, fetch und console.log — die native fetch-Referenz ist hier korrekt, da keine Abwehrmaßnahmen aktiv sind
2. Willkommensbanner schließen — press_key mit Escape, um das Willkommensbanner zu schließen. Bei nachfolgenden Besuchen erscheint das Banner möglicherweise nicht (Cookies wurden gespeichert). Der Cookie-Zustimmungsdialog wird automatisch durch die Escape-Taste geschlossen
3. Auf Abschluss warten — 10 Sekunden warten, bis alle CDN-Skriptlade-/Fehler-Callbacks und Fetch-Promise-Auflösungen abgeschlossen sind
4. Nachweis erfassen — list_console_messages, um auf [CSD Demo] Simulation complete und CDN-Ladeergebnisse zu prüfen; list_network_requests gefiltert nach script- und fetch-Typen, um HTTP-Statuscodes zu überprüfen (200/201 für Erfolg)

Achtung

zone.js-Inkompatibilität — Juice Shop verwendet Angulars zone.js, das setTimeout, setInterval, fetch, XMLHttpRequest und andere Browser-APIs patcht. Dies unterbricht die MCP-Werkzeuge evaluate_script, fill und click mit Cannot read properties of undefined (reading 'call'). Verwenden Sie stattdessen navigate_page mit initScript — initScript wird vor dem Laden von zone.js ausgeführt, sodass Sie native API-Referenzen speichern und in Polling-Callbacks verwenden können. Das initScript muss Formularfelder mit dem nativen HTMLInputElement.prototype.value-Setter (nicht fill) ausfüllen und das Erkennungsskript inline ausführen (nicht über setTimeout, das zone.js nach dem Seitenladen abfangen kann). Weitere Details finden Sie unter Erkennung auslösen — KI-automatisierte Ausführung.

Hinweis

initScript-Akkumulierung — jeder navigate_page-Aufruf mit einem initScript-Parameter fügt das Skript einer persistenten Liste hinzu, die bei jedem nachfolgenden Dokumentladen ausgeführt wird. Um zu verhindern, dass veraltete Skripte Störungen verursachen, navigieren Sie entweder zwischen den Durchläufen zu about:blank oder verwenden Sie new_page mit isolatedContext für einen sauberen Browser-Kontext.

Manuelle Ausführung

Operatoren ohne Browser-Automatisierungswerkzeuge führen die Simulation manuell mit demselben Verfahren wie in Phase 2 — Schritt 8: Angriffssimulation durch:

1. Zu http://xF5XC_DOMAINNAMEx/#/login navigieren
2. Dummy-Anmeldeinformationen in die Felder E-Mail und Passwort eingeben (nicht absenden)
3. DevTools öffnen — F12 drücken und zur Registerkarte Konsole wechseln
4. Das kombinierte Erkennungsskript aus Erkennung auslösen einfügen und ausführen
5. Konsolenausgabe beobachten — alle CDN-Skripte sollten geladen werden und Exfil-Aufrufe sollten mit 200/201-Antworten erfolgreich sein

Nachweis — Vor der Abwehr

Prüfung	Erwartet (vor der Abwehr)	Status
CDN-Skripte injiziert	Alle 4 Script-Tags laden — [Supply Chain] Loaded from-Meldungen erscheinen, Netzwerk-Tab zeigt 200	BESTANDEN
Exfil-Fetch zu www.httpbin.org	Netzwerk-Tab zeigt 200 — Daten gesendet	BESTANDEN
Exfil-Fetch zu jsonplaceholder.typicode.com	Netzwerk-Tab zeigt 201 — Daten gesendet	BESTANDEN
Konsolenausgabe	[CSD Demo] Simulation complete	BESTANDEN

Hinweis

Überprüfung mit Netzwerkanfragen: Der zuverlässigste Nachweis ist der Netzwerk-Tab (oder list_network_requests für KI-Assistenten), nicht Konsolen-Callbacks. zone.js in Juice Shop kann Promise-.then()-Callbacks und Script-onload-Handler unterbrechen, was dazu führt, dass Konsolenmeldungen unvollständig sind, obwohl Netzwerkanfragen erfolgreich sind. Gleichen Sie die Konsolenausgabe immer mit den Statuscodes der Netzwerkanfragen ab.

Tipp

Dies ist der Basisliniennachweis: Ohne aktive Abwehrmaßnahmen werden die Skripte des Angreifers frei geladen und die Datenexfiltration ist erfolgreich. Speichern Sie diesen Nachweis oder erstellen Sie einen Screenshot — Sie werden ihn in Schritt 5 direkt mit den „Nachher”-Ergebnissen vergleichen.

Schritt 3: Abwehrmaßnahmen anwenden

Für jede erkannte Domain senden Sie eine POST-Anfrage an den Endpunkt für abgewehrte Domains. Die primären Ziele aus der Phase-2-Simulation sind die 4 CDN-Injektionsdomains und alle erkannten Datenexfiltrationsdomains.

Primäre Abwehrziele (aus dem kombinierten Simulationsskript):

Domain	Rolle
cdn.jsdelivr.net	CDN-Skriptinjektion
esm.sh	CDN-Skriptinjektion
unpkg.com	CDN-Skriptinjektion
ga.jspm.io	CDN-Skriptinjektion
www.httpbin.org	Datenexfiltrationsendpunkt
jsonplaceholder.typicode.com	Datenexfiltrationsendpunkt

Hinweis

Der POST-Body erfordert sowohl metadata.name (der Bezeichner für das Objekt) als auch spec.mitigated_domain (die Domain-Zeichenkette, die CSD klassifizieren wird). Beide müssen gesetzt sein — spec: {} verursacht einen 400-Fehler. Bei den meisten Domains verwenden beide Felder denselben Wert (z. B. cdn.jsdelivr.net). Siehe die Ausnahme für httpbin.org unten.

Eine Domain abwehren (einmal pro Domain ausführen):

curl -s -X POST \
  -H "Authorization: APIToken xF5XC_API_TOKENx" \
  -H "Content-Type: application/json" \
  -d '{
    "metadata": {
      "name": "cdn.jsdelivr.net",
      "namespace": "xF5XC_NAMESPACEx"
    },
    "spec": {
      "mitigated_domain": "cdn.jsdelivr.net"
    }
  }' \
  "xF5XC_API_URLx/api/shape/csd/namespaces/xF5XC_NAMESPACEx/mitigated_domains" \
  | jq .

Für jede Domain wiederholen:

esm.sh

curl -s -X POST \
  -H "Authorization: APIToken xF5XC_API_TOKENx" \
  -H "Content-Type: application/json" \
  -d '{"metadata":{"name":"esm.sh","namespace":"xF5XC_NAMESPACEx"},"spec":{"mitigated_domain":"esm.sh"}}' \
  "xF5XC_API_URLx/api/shape/csd/namespaces/xF5XC_NAMESPACEx/mitigated_domains" \
  | jq .

# unpkg.com
curl -s -X POST \
  -H "Authorization: APIToken xF5XC_API_TOKENx" \
  -H "Content-Type: application/json" \
  -d '{"metadata":{"name":"unpkg.com","namespace":"xF5XC_NAMESPACEx"},"spec":{"mitigated_domain":"unpkg.com"}}' \
  "xF5XC_API_URLx/api/shape/csd/namespaces/xF5XC_NAMESPACEx/mitigated_domains" \
  | jq .

# ga.jspm.io
curl -s -X POST \
  -H "Authorization: APIToken xF5XC_API_TOKENx" \
  -H "Content-Type: application/json" \
  -d '{"metadata":{"name":"ga.jspm.io","namespace":"xF5XC_NAMESPACEx"},"spec":{"mitigated_domain":"ga.jspm.io"}}' \
  "xF5XC_API_URLx/api/shape/csd/namespaces/xF5XC_NAMESPACEx/mitigated_domains" \
  | jq .

# httpbin.org — www.httpbin.org als mitigated_domain verwenden (siehe Hinweis unten)
curl -s -X POST \
  -H "Authorization: APIToken xF5XC_API_TOKENx" \
  -H "Content-Type: application/json" \
  -d '{"metadata":{"name":"httpbin.org","namespace":"xF5XC_NAMESPACEx"},"spec":{"mitigated_domain":"www.httpbin.org"}}' \
  "xF5XC_API_URLx/api/shape/csd/namespaces/xF5XC_NAMESPACEx/mitigated_domains" \
  | jq .

# jsonplaceholder.typicode.com
curl -s -X POST \
  -H "Authorization: APIToken xF5XC_API_TOKENx" \
  -H "Content-Type: application/json" \
  -d '{"metadata":{"name":"jsonplaceholder.typicode.com","namespace":"xF5XC_NAMESPACEx"},"spec":{"mitigated_domain":"jsonplaceholder.typicode.com"}}' \
  "xF5XC_API_URLx/api/shape/csd/namespaces/xF5XC_NAMESPACEx/mitigated_domains" \
  | jq .

Hinweis

httpbin.org eTLD+1-Einschränkung: Die API lehnt reine eTLD+1-Domains als mitigated_domain-Werte mit "Invalid root domain: cannot derive eTLD+1" ab. Verwenden Sie www.httpbin.org als spec.mitigated_domain-Wert, während Sie httpbin.org als metadata.name beibehalten. Die Abwehr wird korrekt angewendet — der name-Bezeichner ist das, was in der Liste der abgewehrten Domains erscheint. Jede reine Domain (ohne Subdomain), die als Exfil-Ziel in einem benutzerdefinierten Simulationsskript verwendet wird, hat dieselbe Einschränkung.

Eine 200-Antwort gibt das erstellte abgewehrte Domain-Objekt zurück. Eine 409-Antwort bedeutet, dass die Domain bereits in der Abwehrliste vorhanden ist — dies ist eine Erfolgsbedingung.

Schritt 4: Angewendete Abwehrmaßnahmen überprüfen

Listen Sie alle abgewehrten Domains auf und bestätigen Sie, dass die Anzahl der soeben übermittelten Domains entspricht:

curl -s \
  -H "Authorization: APIToken xF5XC_API_TOKENx" \
  "xF5XC_API_URLx/api/shape/csd/namespaces/xF5XC_NAMESPACEx/mitigated_domains" \
  | jq '{count: (.items | length)}'

Hinweis

Der Endpunkt für die Liste der abgewehrten Domains gibt Einträge mit null metadata.name für ALLE Einträge zurück — einzelne Domainnamen sind in der Listenantwort nicht sichtbar. Überprüfen Sie, ob die Anzahl der Einträge der Anzahl der durchgeführten POST-Anfragen entspricht (6 für die Standardsimulation). Die 200-Antwort jedes einzelnen POST in Schritt 3 ist der maßgebliche Nachweis, dass jede Abwehr erstellt wurde. Wenn die Anzahl 1 mit einem null-Namen-Eintrag beträgt und keine Abwehrmaßnahmen angewendet wurden, behandeln Sie die Anzahl als 0 — dies ist ein Backend-Artefakt (siehe Pre-flight-Prüfung für die Entscheidungsregel).

Nachweis

Prüfung	Erwartet	Status
Anzahl abgewehrter Domains	6 (entspricht POST-Anzahl)	BESTANDEN wenn Anzahl übereinstimmt
Alle POSTs aus Schritt 3 haben 200 oder 409 zurückgegeben	Jede Domain akzeptiert	BESTANDEN

Wenn die Anzahl geringer als erwartet ist, führen Sie den POST-Befehl für die fehlende Domain aus Schritt 3 erneut aus.

Schritt 5: Angriff ausführen — Nach der Abwehr

Führen Sie exakt dieselbe kombinierte Simulation erneut aus, um den „Nachher”-Schnappschuss zu erfassen. Das Simulationsskript ist identisch — nur der Abwehrstatus von CSD hat sich geändert. Skriptladevorgänge von abgewehrten Domains werden jetzt durch das CSD-JavaScript blockiert (das <script>-Tag src wird auf eine leere Zeichenkette geleert).

Hinweis

Dieser Schritt verwendet dieselbe Browser-Automatisierungssequenz wie Schritt 2. Der Unterschied liegt nicht darin, was Sie ausführen — sondern in dem, was Sie beobachten. Mit aktiven Abwehrmaßnahmen blockiert CSD <script>-Tag-Ladevorgänge von abgewehrten Domains. Fetch-API-Aufrufe an abgewehrte Exfil-Domains werden weiterhin abgeschlossen — die CSD-Abwehr zielt auf das Laden von Skripten ab, nicht auf fetch/XHR.

KI-automatisierte Ausführung

KI-Assistenten mit Browser-Automatisierungswerkzeugen führen die Angriffssimulation programmgesteuert mit demselben Phase-2-initScript erneut aus (wortwörtlicher Code in Phase 2 — KI-automatisierte Ausführung). Das initScript speichert das native fetch, um zone.js-Fehler zu vermeiden — dies hat keinen Einfluss auf die CSD-Abwehr, da CSD keine fetch()-Aufrufe abfängt.

1. Mit initScript navigieren — verwenden Sie new_page mit isolatedContext für einen sauberen Browser-Kontext (verhindert veraltete initScripts aus Schritt 2), navigieren Sie dann zu about:blank und anschließend zur Anmeldeseite mit dem Phase-2-initScript
2. Willkommensbanner schließen — press_key mit Escape
3. Auf Abschluss warten — 10 Sekunden warten, bis alle asynchronen Callbacks abgeschlossen sind
4. Nachweis erfassen — list_console_messages, um auf [CSD Demo] Simulation complete zu prüfen; list_network_requests gefiltert nach script- und fetch-Typen, um zu beobachten, dass CDN-Skriptladevorgänge fehlen (CSD hat das Skript-src geleert), während Fetch-Aufrufe an Exfil-Domains weiterhin normal abgeschlossen werden

Manuelle Ausführung

Operatoren ohne Browser-Automatisierungswerkzeuge führen die Simulation manuell mit demselben Verfahren wie in Phase 2 — Schritt 8: Angriffssimulation durch:

1. Zu http://xF5XC_DOMAINNAMEx/#/login navigieren
2. Dummy-Anmeldeinformationen in die Felder E-Mail und Passwort eingeben (nicht absenden)
3. DevTools öffnen — F12 drücken und zur Registerkarte Konsole wechseln
4. Das kombinierte Erkennungsskript aus Erkennung auslösen einfügen und ausführen
5. Konsolen- und Netzwerkausgabe beobachten — CDN-Skript-onload- und onerror-Callbacks werden für abgewehrte Domains nicht ausgelöst (CSD hat das Skript-src auf eine leere Zeichenkette geleert, wodurch die Netzwerkanfrage vollständig verhindert wird). Fetch-Aufrufe an Exfil-Domains (www.httpbin.org, jsonplaceholder.typicode.com) werden weiterhin abgeschlossen mit 200/201 — die CSD-Abwehr blockiert das Laden von Skripten, nicht Fetch/XHR-Aufrufe

Zeitpunkt der Abwehrweitergabe

Das CSD-JavaScript soll das Laden von Skripten von abgewehrten Domains blockieren, indem es den <script>-Tag-src-Setter abfängt. Beim Testen über HTTP (Port 80) wurde das Leeren des Skript-src jedoch innerhalb von 5 Minuten nach Anwendung der Abwehrmaßnahmen nicht beobachtet — alle CDN-Skripte wurden weiterhin normal geladen. Dies kann darauf hindeuten, dass die Abwehrweitergabe mehr als 5 Minuten erfordert, oder dass der Mechanismus sich über HTTP und HTTPS unterschiedlich verhält. Wenn keine Abwehrblockierung beobachtet wird, erlauben Sie zusätzliche Weitergabezeit und überprüfen Sie, ob das CSD-Telemetrieskript seine Konfiguration aktualisiert hat.

Fetch-Aufrufe werden von der CSD-Abwehr nicht abgefangen (verifiziert). Exfil-Fetch-Aufrufe an abgewehrte Domains (www.httpbin.org, jsonplaceholder.typicode.com) werden weiterhin normal mit 200/201-Antworten abgeschlossen, sowohl vor als auch nach der Abwehr. Die CSD-Abwehr zielt auf den Supply-Chain-Vektor (Laden bösartiger Skripte) ab, nicht auf Datenexfiltration über fetch/XHR. Verwenden Sie dasselbe Phase-2-initScript (mit gespeichertem nativem fetch) für Schritt 2 und Schritt 5.

Nachweis — Nach der Abwehr

Prüfung	Erwartet (nach der Abwehr)	Status
CDN-Skriptladevorgänge	Blockiert — Skripte erscheinen nicht im Netzwerk-Tab (CSD hat src auf leere Zeichenkette geleert)	BESTANDEN
CDN-Skript-Callbacks	Weder onload noch onerror werden für abgewehrte Domains ausgelöst	BESTANDEN
Exfil-Fetch zu www.httpbin.org	200 — Fetch wird weiterhin abgeschlossen (CSD fängt Fetch nicht ab)	INFO
Exfil-Fetch zu jsonplaceholder.typicode.com	201 — Fetch wird weiterhin abgeschlossen (CSD fängt Fetch nicht ab)	INFO
Konsolenausgabe	[CSD Demo] Simulation complete	BESTANDEN

Tipp

Die Backend-Überprüfung ist der zuverlässigste Nachweis. Wenn die im Browser sichtbare Skriptblockierung innerhalb des Demo-Zeitrahmens nicht beobachtet wird, verwenden Sie die /detected_domains-API-Antwort als primären Nachweis. Die Anzahl der mitigatedDomains und die reduzierte actionNeededCount in der Domain-Zusammenfassung bestätigen, dass Abwehrmaßnahmen im Backend aktiv sind — auch wenn das CSD-JavaScript im Browser seine Konfiguration zur Durchsetzung der Blockierung noch nicht aktualisiert hat.

Schritt 6: Vergleich Vorher vs. Nachher

Dies ist der Demo-Höhepunkt — Seite-an-Seite-Nachweis, der beweist, dass derselbe Angriff auf derselben Seite mit demselben Skript nun ein völlig anderes Ergebnis erzeugt.

Vergleichstabelle

Signal	Vor der Abwehr (Schritt 2)	Nach der Abwehr (Schritt 5)
CDN-Skriptladevorgänge	200 — alle 4 CDN-Skripte laden normal	Blockiert — Skripte fehlen im Netzwerk-Tab (CSD hat src auf leere Zeichenkette geleert)
CDN-onload-Callbacks	[Supply Chain] Loaded from-Meldungen erscheinen	Keine Callbacks werden ausgelöst (es wurde keine Netzwerkanfrage gestellt)
Exfil zu www.httpbin.org	200 — Daten exfiltriert	200 — Fetch wird weiterhin abgeschlossen (CSD fängt Fetch nicht ab)
Exfil zu jsonplaceholder.typicode.com	201 — Daten exfiltriert	201 — Fetch wird weiterhin abgeschlossen (CSD fängt Fetch nicht ab)
CSD-API für abgewehrte Domains	0 abgewehrt	6 abgewehrt

Abwehr in Backend-Daten überprüfen

Fragen Sie /detected_domains alle 60 Sekunden für bis zu 10 Iterationen (10 Minuten) ab. Fahren Sie mit der Vergleichstabelle fort, sobald die Abfrage zurückgibt, oder nach dem 10-Minuten-Maximum — diese Prüfungen sind informativ und sperren Phase 4 nicht.

Erkannte Domains nach der Abwehr prüfen:

curl -s \
  -H "Authorization: APIToken xF5XC_API_TOKENx" \
  "xF5XC_API_URLx/api/shape/csd/namespaces/xF5XC_NAMESPACEx/detected_domains" \
  | jq '{total_domains: .domain_summary.totalDomains, domains: [.domains_list[]? | {domain: .domain, category: .category}]}'

Skripte auf abgewehrten Status prüfen:

NOW=$(date +%s)
START=$(( NOW - 86400 ))
curl -s -X POST \
  -H "Authorization: APIToken xF5XC_API_TOKENx" \
  -H "Content-Type: application/json" \
  -d "{\"startTime\": \"$START\", \"endTime\": \"$NOW\"}" \
  "xF5XC_API_URLx/api/shape/csd/namespaces/xF5XC_NAMESPACEx/scripts" \
  | jq '{total: (.scripts | length), scripts: [.scripts[]? | {script_name: .script_name, risk_level: .risk_level}]}'

Nachweiszusammenfassung für Phase 3

Prüfung	Erwartet	Status
Basislinie sauber (Schritt 1)	0 abgewehrte Domains zu Beginn	BESTANDEN / NICHT BESTANDEN
Vorher — Angriff erfolgreich (Schritt 2)	Skripte laden, Exfil gibt 200/201 zurück	BESTANDEN / NICHT BESTANDEN
Abwehrmaßnahmen angewendet (Schritt 3)	Alle 6 Domains über POST akzeptiert (200 oder 409)	BESTANDEN / NICHT BESTANDEN
Abwehrzahl bestätigt (Schritt 4)	6 Einträge in der Liste	BESTANDEN / NICHT BESTANDEN
Nachher — Skriptladevorgänge blockiert (Schritt 5)	CDN-Skripte fehlen im Netzwerk-Tab, Fetch-Aufrufe werden weiterhin abgeschlossen	BESTANDEN / NICHT BESTANDEN
Vergleich Vorher vs. Nachher (Schritt 6)	Klarer Unterschied zwischen den Nachweisen aus Schritt 2 und Schritt 5	BESTANDEN / NICHT BESTANDEN

Hinweis

Aktualisierungen des Erkennungsstatus nach der Abwehr können einige Zeit benötigen, um in der API-Antwort zu erscheinen. Wenn die Domains unmittelbar nach der Abwehr noch „Handlungsbedarf” anzeigen, fragen Sie /detected_domains alle 60 Sekunden für bis zu 10 Iterationen (10 Minuten) ab. Wenn nach 10 Iterationen noch nicht aktualisiert, erfassen Sie den aktuellen Status als INFO — dies blockiert Phase 4 nicht.

---

Phase 3 abgeschlossen. Fahren Sie mit Phase 4 — Abbau fort, wenn Sie bereit sind, alle Bereitstellungsobjekte zu entfernen.