Abusing Service Workers
Basic Information
A service worker is a script run by your browser in the background, separate from any web page, enabling features that don't require a web page or user interaction, thus enhancing offline and background processing capabilities. Detailed information on service workers can be found here. By exploiting service workers within a vulnerable web domain, attackers can gain control over the victim's interactions with all pages within that domain.
Checking for Existing Service Workers
Existing service workers can be checked in the Service Workers section of the Application tab in Developer Tools. Another method is visiting chrome://serviceworker-internals for a more detailed view.
Push Notifications
Push notification permissions directly impact a service worker's ability to communicate with the server without direct user interaction. If permissions are denied, it limits the service worker's potential to pose a continuous threat. Conversely, granting permissions increases security risks by enabling the reception and execution of potential exploits.
Attack Creating a Service Worker
In order to exploit this vulnerability you need to find:
A way to upload arbitrary JS files to the server and a XSS to load the service worker of the uploaded JS file
A vulnerable JSONP request where you can manipulate the output (with arbitrary JS code) and a XSS to load the JSONP with a payload that will load a malicious service worker.
In the following example I'm going to present a code to register a new service worker that will listen to the fetch
event and will send to the attackers server each fetched URL (this is the code you would need to upload to the server or load via a vulnerable JSONP response):
And this is the code that will register the worker (the code you should be able to execute abusing a XSS). In this case a GET request will be sent to the attackers server notifying if the registration of the service worker was successful or not:
In case of abusing a vulnerable JSONP endpoint you should put the value inside var sw
. For example:
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
importScripts
in a SW via DOM ClobberingThe 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.
This even bypasses CSP protections.
Example vulnerable code:
index.html
sw.js
With DOM Clobbering
For more info about what DOM Clobbering is check:
Dom ClobberingIf the URL/domain where that the SW is using to call importScripts
is inside a HTML element, it's possible to modify it via DOM Clobbering to make the SW load a script from your own domain.
For an example of this check the reference link.
References
Last updated