XSSI (Cross-Site Script Inclusion)
Last updated
Last updated
Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
Cross-Site Script Inclusion (XSSI) è una vulnerabilità che deriva dalla natura del tag script
in HTML. A differenza della maggior parte delle risorse, che sono soggette alla Same-Origin Policy (SOP), gli script possono essere inclusi da domini diversi. Questo comportamento è inteso a facilitare l'uso di librerie e altre risorse ospitate su server diversi, ma introduce anche un potenziale rischio per la sicurezza.
Bypass of SOP: Gli script sono esenti dalla Same-Origin Policy, consentendo loro di essere inclusi tra domini.
Data Exposure: Un attaccante può sfruttare questo comportamento per leggere i dati caricati tramite il tag script
.
Impact on Dynamic JavaScript/JSONP: XSSI è particolarmente rilevante per JavaScript dinamico o JSON with Padding (JSONP). Queste tecnologie utilizzano spesso informazioni di "ambient-authority" (come i cookie) per l'autenticazione. Quando viene effettuata una richiesta di script a un host diverso, queste credenziali (ad es., cookie) vengono automaticamente incluse nella richiesta.
Authentication Token Leakage: Se un attaccante riesce a ingannare il browser di un utente a richiedere uno script da un server che controlla, potrebbe essere in grado di accedere a informazioni sensibili contenute in queste richieste.
Static JavaScript - Questo rappresenta la forma convenzionale di XSSI.
Static JavaScript with Authentication - Questo tipo è distinto perché richiede autenticazione per l'accesso.
Dynamic JavaScript - Coinvolge JavaScript che genera contenuti dinamicamente.
Non-JavaScript - Si riferisce a vulnerabilità che non coinvolgono direttamente JavaScript.
The following information is a sumary of https://www.scip.ch/en/?labs.20160414. Check it for further details.
In questo approccio, le informazioni private sono incorporate all'interno di un file JavaScript accessibile globalmente. Gli attaccanti possono identificare questi file utilizzando metodi come la lettura di file, ricerche per parole chiave o espressioni regolari. Una volta localizzato, lo script contenente informazioni private può essere incluso in contenuti malevoli, consentendo accesso non autorizzato a dati sensibili. Un esempio di tecnica di sfruttamento è mostrato di seguito:
Questi tipi di attacchi XSSI comportano l'aggiunta dinamica di informazioni riservate allo script in risposta a una richiesta dell'utente. La rilevazione può essere effettuata inviando richieste con e senza cookie e confrontando le risposte. Se le informazioni differiscono, potrebbe indicare la presenza di informazioni riservate. Questo processo può essere automatizzato utilizzando strumenti come l'estensione Burp DetectDynamicJS.
Se i dati riservati sono memorizzati in una variabile globale, possono essere sfruttati utilizzando metodi simili a quelli utilizzati nel Regular XSSI. Tuttavia, se i dati riservati sono inclusi in una risposta JSONP, gli attaccanti possono dirottare la funzione di callback per recuperare le informazioni. Questo può essere fatto manipolando oggetti globali o impostando una funzione da eseguire nella risposta JSONP, come dimostrato di seguito:
Per le variabili che non risiedono nello spazio dei nomi globale, prototype tampering può a volte essere sfruttato. Questa tecnica sfrutta il design di JavaScript, dove l'interpretazione del codice comporta l'attraversamento della catena del prototipo per localizzare la proprietà chiamata. Sovrascrivendo determinate funzioni, come Array
's slice
, gli attaccanti possono accedere e leakare variabili non globali:
Ulteriori dettagli sugli attacchi possono essere trovati nel lavoro del ricercatore di sicurezza Sebastian Lekies, che mantiene un elenco di vettori.
La ricerca di Takeshi Terada introduce un'altra forma di XSSI, in cui i file Non-Script, come CSV, vengono leakati cross-origin includendoli come sorgenti in un tag script
. I casi storici di XSSI, come l'attacco del 2006 di Jeremiah Grossman per leggere un intero rubrica di Google e il leak di dati JSON di Joe Walker nel 2007, evidenziano la gravità di queste minacce. Inoltre, Gareth Heyes descrive una variante di attacco che coinvolge JSON codificato in UTF-7 per sfuggire al formato JSON ed eseguire script, efficace in alcuni browser:
Impara e pratica AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Impara e pratica GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)