Fase 3 — Mitigazione

La Fase 3 crea una prova prima/dopo della mitigazione CSD. Si riesegue l’attacco senza mitigazioni per stabilire una baseline, si applicano le mitigazioni, quindi si riesegue lo stesso attacco per dimostrare che CSD blocca le chiamate di rete. La Fase 2 deve essere completata — tutti i controlli DET devono risultare PASS — prima di procedere.

Nota

La mitigazione CSD blocca il caricamento degli script dai domini mitigati. Quando un dominio è nell’elenco di mitigazione, il JavaScript CSD intercetta gli URL sorgente dei tag <script> e impedisce il caricamento degli script — bloccando gli attacchi alla supply chain alla fonte. CSD non intercetta le chiamate fetch() o XMLHttpRequest. Questa fase acquisisce la prova del blocco degli script eseguendo lo stesso attacco prima e dopo la mitigazione.

Attenzione

Nota sui test in produzione: Gli endpoint POST/DELETE di mitigazione sono stati validati in ambienti di sviluppo, ma i dettagli di comportamento (tempi di risposta, effetto sullo stato di rilevamento degli script) possono variare in base alle configurazioni del tenant. Se si osservano risposte impreviste, consultare il Riferimento API per le definizioni canoniche degli endpoint.

Passaggio 1: Confermare l’assenza di mitigazioni attive (Baseline)

Prima di acquisire lo snapshot “prima”, verificare che l’ambiente sia pulito — non devono essere attive mitigazioni. Ciò garantisce che l’attacco di baseline venga eseguito senza alcun blocco da parte di CSD.

Verificare il conteggio dei domini mitigati

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

Se il conteggio non è 0, le mitigazioni di un’esecuzione precedente sono ancora presenti. Eliminarle tutte prima di procedere:

# Delete a mitigated domain (repeat for each domain name)
curl -s -X DELETE \
  -H "Authorization: APIToken xF5XC_API_TOKENx" \
  "xF5XC_API_URLx/api/shape/csd/namespaces/xF5XC_NAMESPACEx/mitigated_domains/<domain-name>" \
  | jq .

Sostituire <domain-name> con il valore metadata.name utilizzato al momento della mitigazione del dominio (es. cdn.jsdelivr.net, esm.sh, unpkg.com, ga.jspm.io, httpbin.org, jsonplaceholder.typicode.com). Se la pulizia di httpbin.org lascia un elemento residuo, provare anche a eliminare www.httpbin.org — alcune esecuzioni precedenti potrebbero aver utilizzato questo come nome dei metadati.

Confermare la presenza dei rilevamenti della Fase 2

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}]}'

Evidenza

Controllo	Atteso	Stato
Conteggio domini mitigati	0 (baseline pulita)	PASS se 0, richiede pulizia se > 0
Conteggio domini rilevati	> 0 (rilevamenti della Fase 2 presenti)	PASS se > 0
Domini di esfiltrazione presenti	www.httpbin.org, jsonplaceholder.typicode.com	PASS se almeno uno è presente

Passaggio 2: Eseguire l’attacco — Prima della mitigazione

Rieseguire la simulazione combinata con nessuna mitigazione attiva per acquisire una baseline aggiornata. Questo è lo snapshot “prima” — prova che gli attacchi hanno successo quando la mitigazione CSD non è applicata.

Nota

Questo passaggio richiede l’esecuzione di JavaScript lato browser — curl non può attivare il rilevamento CSD. Gli assistenti IA con strumenti di automazione del browser (MCP Chrome DevTools, Playwright, Puppeteer) eseguono questi passaggi direttamente utilizzando la sequenza Esecuzione automatizzata tramite IA riportata di seguito. Gli operatori senza automazione del browser eseguono i passaggi manuali.

Esecuzione automatizzata tramite IA

Gli assistenti IA con strumenti di automazione del browser eseguono la simulazione dell’attacco in modo programmatico utilizzando lo stesso initScript della Fase 2 (che salva il fetch nativo):

1. Navigare con initScript — prima navigare verso about:blank per garantire un contesto documento pulito (evita initScript obsoleti da navigazioni precedenti), quindi usare navigate_page verso http://$F5XC_DOMAINNAME/#/login con l’initScript della Fase 2 (codice verbatim in Fase 2 — Esecuzione automatizzata tramite IA). Questo initScript salva setInterval, clearInterval, fetch e console.log nativi — il riferimento al fetch nativo è corretto qui perché non sono attive mitigazioni
2. Chiudere il banner di benvenuto — press_key con Escape per chiudere il banner di benvenuto. Nelle visite successive il banner potrebbe non apparire (cookie persistenti). La finestra di dialogo per il consenso ai cookie viene chiusa automaticamente dal tasto Escape
3. Attendere il completamento — attendere 10 secondi affinché tutti i callback di caricamento/errore degli script CDN e le risoluzioni delle promise fetch vengano completati
4. Acquisire le prove — list_console_messages per verificare la presenza di [CSD Demo] Simulation complete e i risultati del caricamento CDN; list_network_requests filtrato per i tipi script e fetch per verificare i codici di stato HTTP (200/201 per il successo)

Attenzione

Incompatibilità con zone.js — Juice Shop utilizza zone.js di Angular, che modifica setTimeout, setInterval, fetch, XMLHttpRequest e altre API del browser. Questo causa il malfunzionamento degli strumenti MCP evaluate_script, fill e click con Cannot read properties of undefined (reading 'call'). Usare navigate_page con initScript — initScript viene eseguito prima del caricamento di zone.js, quindi è possibile salvare i riferimenti alle API native e utilizzarli nei callback di polling. L’initScript deve compilare i campi del modulo utilizzando il setter nativo HTMLInputElement.prototype.value (non fill) ed eseguire lo script di rilevamento in linea (non tramite setTimeout, che zone.js potrebbe intercettare dopo il caricamento della pagina). Vedere Rilevamento Trigger — Esecuzione automatizzata tramite IA per i dettagli.

Nota

Accumulo di initScript — ogni chiamata navigate_page con un parametro initScript aggiunge lo script a un elenco persistente che viene eseguito ad ogni successivo caricamento del documento. Per evitare interferenze da script obsoleti, navigare verso about:blank tra un’esecuzione e l’altra oppure usare new_page con isolatedContext per un contesto browser pulito.

Esecuzione manuale

Gli operatori senza strumenti di automazione del browser eseguono la simulazione manualmente utilizzando la stessa procedura descritta in Fase 2 — Passaggio 8: Simulazione dell’attacco:

1. Navigare verso http://xF5XC_DOMAINNAMEx/#/login
2. Inserire credenziali fittizie nei campi Email e Password (non inviare il modulo)
3. Aprire DevTools — premere F12 e passare alla scheda Console
4. Incollare ed eseguire lo Script di rilevamento combinato da Rilevamento Trigger
5. Osservare l’output della console — tutti gli script CDN devono caricarsi e le chiamate di esfiltrazione devono avere successo con risposte 200/201

Evidenza — Prima della mitigazione

Controllo	Atteso (Prima della mitigazione)	Stato
Script CDN iniettati	Tutti e 4 i tag script si caricano — compaiono i messaggi [Supply Chain] Loaded from, la scheda di rete mostra 200	PASS
Esfiltrazione fetch verso www.httpbin.org	La scheda di rete mostra 200 — dati inviati	PASS
Esfiltrazione fetch verso jsonplaceholder.typicode.com	La scheda di rete mostra 201 — dati inviati	PASS
Output della console	[CSD Demo] Simulation complete	PASS

Nota

Verifica tramite richieste di rete: La prova più affidabile è la scheda Network (o list_network_requests per gli assistenti IA), non i callback della console. zone.js in Juice Shop può interrompere i callback .then() delle promise e i gestori onload degli script, causando messaggi di console incompleti anche quando le richieste di rete hanno esito positivo. Incrociare sempre l’output della console con i codici di stato delle richieste di rete.

Consiglio

Questa è la prova di baseline: senza mitigazioni attive, gli script dell’attaccante si caricano liberamente e l’esfiltrazione dei dati ha successo. Salvare o acquisire uno screenshot di questa evidenza — la si confronterà direttamente con i risultati “dopo” nel Passaggio 5.

Passaggio 3: Applicare le mitigazioni

Per ciascun dominio rilevato, eseguire un POST verso l’endpoint dei domini mitigati. I target principali dalla simulazione della Fase 2 sono i 4 domini di iniezione CDN e qualsiasi dominio di esfiltrazione dati rilevato.

Target principali di mitigazione (dallo script di simulazione combinato):

Dominio	Ruolo
cdn.jsdelivr.net	Iniezione script CDN
esm.sh	Iniezione script CDN
unpkg.com	Iniezione script CDN
ga.jspm.io	Iniezione script CDN
www.httpbin.org	Endpoint di esfiltrazione dati
jsonplaceholder.typicode.com	Endpoint di esfiltrazione dati

Nota

Il corpo della richiesta POST richiede sia metadata.name (l’identificatore dell’oggetto) che spec.mitigated_domain (la stringa del dominio che CSD classificherà). Entrambi devono essere impostati — spec: {} causa un errore 400. Per la maggior parte dei domini, entrambi i campi utilizzano lo stesso valore (es. cdn.jsdelivr.net). Vedere l’eccezione per httpbin.org di seguito.

Mitigare un dominio (eseguire una volta per dominio):

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 .

Ripetere per ciascun dominio:

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 — use www.httpbin.org as mitigated_domain (see note below)
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 .

Nota

Vincolo eTLD+1 per httpbin.org: L’API rifiuta i domini eTLD+1 puri come valori mitigated_domain con "Invalid root domain: cannot derive eTLD+1". Usare www.httpbin.org come valore spec.mitigated_domain mantenendo httpbin.org come metadata.name. La mitigazione viene applicata correttamente — l’identificatore name è ciò che appare nell’elenco dei domini mitigati. Qualsiasi dominio privo di sottodominio utilizzato come target di esfiltrazione in uno script di simulazione personalizzato avrà lo stesso vincolo.

Una risposta 200 restituisce l’oggetto dominio mitigato creato. Una risposta 409 indica che il dominio è già presente nell’elenco dei mitigati — questa è una condizione di successo.

Passaggio 4: Verificare l’applicazione delle mitigazioni

Elencare tutti i domini mitigati e confermare che il conteggio corrisponda al numero di domini appena inviati:

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

Nota

L’endpoint dell’elenco dei domini mitigati restituisce elementi con metadata.name null per TUTTI gli elementi — i nomi dei singoli domini non sono visibili nella risposta dell’elenco. Verificare controllando che il conteggio degli elementi sia uguale al numero di richieste POST effettuate (6 per la simulazione standard). La risposta 200 di ogni singolo POST nel Passaggio 3 è la prova autorevole che ogni mitigazione è stata creata. Se il conteggio è 1 con un elemento dal nome null e non sono state applicate mitigazioni, considerare il conteggio come 0 — questo è un artefatto del backend (vedere Verifica preliminare per la regola decisionale).

Evidenza

Controllo	Atteso	Stato
Conteggio domini mitigati	6 (corrisponde al conteggio POST)	PASS se il conteggio corrisponde
Tutti i POST del Passaggio 3 hanno restituito 200 o 409	Ogni dominio accettato	PASS

Se il conteggio è inferiore al previsto, rieseguire il comando POST per il dominio mancante dal Passaggio 3.

Passaggio 5: Eseguire l’attacco — Dopo la mitigazione

Rieseguire la stessa identica simulazione combinata per acquisire lo snapshot “dopo”. Lo script di simulazione è identico — è cambiato solo lo stato di mitigazione di CSD. I caricamenti di script dai domini mitigati vengono ora bloccati dal JavaScript CSD (il src del tag <script> viene impostato su una stringa vuota).

Nota

Questo passaggio utilizza la stessa sequenza di automazione del browser del Passaggio 2. La differenza non sta in ciò che si esegue — ma in ciò che si osserva. Con le mitigazioni attive, CSD blocca i caricamenti dei tag <script> dai domini mitigati. Le chiamate API fetch verso i domini di esfiltrazione mitigati vengono comunque completate — la mitigazione CSD si rivolge al caricamento degli script, non alle chiamate fetch/XHR.

Esecuzione automatizzata tramite IA

Gli assistenti IA con strumenti di automazione del browser rieseguono la simulazione dell’attacco in modo programmatico utilizzando lo stesso initScript della Fase 2 (codice verbatim in Fase 2 — Esecuzione automatizzata tramite IA). L’initScript salva il fetch nativo per evitare errori di zone.js — questo non influisce sulla mitigazione CSD perché CSD non intercetta le chiamate fetch().

1. Navigare con initScript — usare new_page con isolatedContext per un contesto browser pulito (evita initScript obsoleti dal Passaggio 2), quindi navigare verso about:blank, poi verso la pagina di login con l’initScript della Fase 2
2. Chiudere il banner di benvenuto — press_key con Escape
3. Attendere il completamento — attendere 10 secondi affinché tutti i callback asincroni vengano completati
4. Acquisire le prove — list_console_messages per verificare la presenza di [CSD Demo] Simulation complete; list_network_requests filtrato per i tipi script e fetch per osservare che i caricamenti degli script CDN siano assenti (CSD ha svuotato il src dello script) mentre le chiamate fetch verso i domini di esfiltrazione vengono ancora completate normalmente

Esecuzione manuale

Gli operatori senza strumenti di automazione del browser rieseguono la simulazione manualmente utilizzando la stessa procedura descritta in Fase 2 — Passaggio 8: Simulazione dell’attacco:

1. Navigare verso http://xF5XC_DOMAINNAMEx/#/login
2. Inserire credenziali fittizie nei campi Email e Password (non inviare il modulo)
3. Aprire DevTools — premere F12 e passare alla scheda Console
4. Incollare ed eseguire lo Script di rilevamento combinato da Rilevamento Trigger
5. Osservare l’output della console e della rete — i callback onload e onerror degli script CDN non si attivano per i domini mitigati (CSD ha svuotato il src dello script impostandolo a una stringa vuota, impedendo completamente la richiesta di rete). Le chiamate fetch verso i domini di esfiltrazione (www.httpbin.org, jsonplaceholder.typicode.com) vengono comunque completate con 200/201 — la mitigazione CSD blocca il caricamento degli script, non le chiamate fetch/XHR

Tempi di propagazione della mitigazione

Il JavaScript CSD dovrebbe bloccare il caricamento degli script dai domini mitigati intercettando il setter src del tag <script>. Tuttavia, durante i test su HTTP (porta 80), la cancellazione del src degli script non è stata osservata entro 5 minuti dall’applicazione delle mitigazioni — tutti gli script CDN hanno continuato a caricarsi normalmente. Ciò potrebbe indicare che la propagazione della mitigazione richiede più di 5 minuti, oppure che il meccanismo si comporta diversamente su HTTP rispetto a HTTPS. Se il blocco della mitigazione non viene osservato, attendere un tempo di propagazione aggiuntivo e verificare che lo script di telemetria CSD abbia aggiornato la propria configurazione.

Le chiamate fetch non vengono intercettate dalla mitigazione CSD (verificato). Le chiamate fetch di esfiltrazione verso i domini mitigati (www.httpbin.org, jsonplaceholder.typicode.com) vengono comunque completate normalmente con risposte 200/201, sia prima che dopo la mitigazione. La mitigazione CSD si rivolge al vettore della supply chain (caricamento di script malevoli), non all’esfiltrazione di dati tramite fetch/XHR. Usare lo stesso initScript della Fase 2 (con il fetch nativo salvato) sia per il Passaggio 2 che per il Passaggio 5.

Evidenza — Dopo la mitigazione

Controllo	Atteso (Dopo la mitigazione)	Stato
Caricamenti script CDN	Bloccati — gli script non compaiono nella scheda di rete (CSD ha impostato src a stringa vuota)	PASS
Callback degli script CDN	Né onload né onerror si attivano per i domini mitigati	PASS
Esfiltrazione fetch verso www.httpbin.org	200 — fetch ancora completata (CSD non intercetta fetch)	INFO
Esfiltrazione fetch verso jsonplaceholder.typicode.com	201 — fetch ancora completata (CSD non intercetta fetch)	INFO
Output della console	[CSD Demo] Simulation complete	PASS

Consiglio

La verifica del backend è la prova più affidabile. Se il blocco degli script visibile nel browser non viene osservato entro i tempi della demo, utilizzare la risposta dell’API /detected_domains come prova principale. Il conteggio mitigatedDomains e il ridotto actionNeededCount nel riepilogo dei domini confermano che le mitigazioni sono attive nel backend — anche se il JavaScript CSD nel browser non ha ancora aggiornato la propria configurazione per applicare il blocco.

Passaggio 6: Confronto Prima vs Dopo

Questo è il risultato dimostrativo — prove affiancate che dimostrano che lo stesso attacco, sulla stessa pagina, con lo stesso script, produce ora un risultato completamente diverso.

Tabella di confronto

Segnale	Prima della mitigazione (Passaggio 2)	Dopo la mitigazione (Passaggio 5)
Caricamenti script CDN	200 — tutti e 4 gli script CDN si caricano normalmente	Bloccati — script assenti dalla scheda di rete (CSD ha impostato src a stringa vuota)
Callback onload CDN	Compaiono i messaggi [Supply Chain] Loaded from	Nessun callback si attiva (nessuna richiesta di rete è stata effettuata)
Esfiltrazione verso www.httpbin.org	200 — dati esfiltrati	200 — fetch ancora completata (CSD non intercetta fetch)
Esfiltrazione verso jsonplaceholder.typicode.com	201 — dati esfiltrati	201 — fetch ancora completata (CSD non intercetta fetch)
API domini mitigati CSD	0 mitigati	6 mitigati

Verifica della mitigazione nei dati del backend

Interrogare /detected_domains ogni 60 secondi per un massimo di 10 iterazioni (10 minuti). Procedere alla tabella di confronto una volta ricevuta la risposta, o dopo il massimo di 10 minuti — questi controlli sono informativi e non bloccano la Fase 4.

Verificare i domini rilevati dopo la mitigazione:

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}]}'

Verificare lo stato di mitigazione degli script:

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}]}'

Riepilogo delle prove della Fase 3

Controllo	Atteso	Stato
Baseline pulita (Passaggio 1)	0 domini mitigati all’avvio	PASS / FAIL
Prima — attacco riuscito (Passaggio 2)	Script caricati, esfiltrazione restituisce 200/201	PASS / FAIL
Mitigazioni applicate (Passaggio 3)	Tutti e 6 i domini accettati tramite POST (200 o 409)	PASS / FAIL
Conteggio mitigati confermato (Passaggio 4)	6 elementi nell’elenco	PASS / FAIL
Dopo — caricamenti script bloccati (Passaggio 5)	Script CDN assenti dalla scheda di rete, chiamate fetch ancora completate	PASS / FAIL
Confronto prima vs dopo (Passaggio 6)	Differenza netta tra le prove del Passaggio 2 e del Passaggio 5	PASS / FAIL

Nota

Gli aggiornamenti dello stato di rilevamento dopo la mitigazione potrebbero richiedere del tempo per apparire nella risposta dell’API. Se i domini mostrano ancora “Action Needed” immediatamente dopo la mitigazione, interrogare /detected_domains ogni 60 secondi per un massimo di 10 iterazioni (10 minuti). Se non viene aggiornato dopo 10 iterazioni, registrare lo stato attuale come INFO — questo non blocca la Fase 4.

---

Fase 3 completata. Procedere verso Fase 4 — Smontaggio quando si è pronti a rimuovere tutti gli oggetti di deployment.