Web Browsers have evolved exponentially since 2015. The race to add more functionality to modern web browsers has already started between Chrome, Firefox, and Edge. These new functions range from Progressive Web Apps to Web-based Push Messaging. We can even run client-side caching techniques to serve websites faster without increasing overhead to a webserver. All this is possible because of the functionality of “Service-Workers.”
In the future, service workers will support many other unimaginable things like periodic sync, geofencing, and more. You could have tried using app cache to attempt to make an app work offline, but there were too many “gotchas” and it didn’t have the power or flexibility that service workers bring.
A domain with XSS (Cross-site scripting) is more vulnerable to attacks in comparison to sandbox domains.
How to exploit via service workers: Suppose a domain with XSS (Cross-site scripting) vulnerability or a loophole also has a JSONP endpoint. The hacker can use it for the following operations:
1) Bypass/override CSP (Content Security Policy).
2) Register a service worker.
3) Call “importScripts” to import a third-party script to persist.
In the future, to overcome issues like this there will be Clear-Site-Data. (This is the quick fix.)
Developers will ignore requests that have the service worker request header for URLs or paths that the webserver isn’t expected to deliver service worker scripts for; e.g., 400 Bad Request.
The fundamental conflict of web security is between a web application and the browser. The web application, which you’ve built, wants to store, preserve, and present user-data, whereas the web-browser processes everything it sees. This problem can be solved by sending unfiltered user generated traffic to a separate host that will not store cookies.
Suppose a user logs into a domain and serves the content from userrecords.net of that domain. In the meantime, if the browser wants to process user-files, then it can easily do so, but the code will be running in the userrecords.net, where there are no cookies to exploit.
The other famous attack via service workers is a “MarioNET” attack, which gives hackers the ability to control your browser, even after you leave the attack page or website.
What to do
Web application owners should look over the user-files with secret URLs from a shared domain in their application. If they are found, then the application owner should look out for the service worker: script HTTP header. Then, try to secure service worker requests that are running on that domain. If you are a browser vendor, you must figure out the potential vulnerability of exploited service workers.
Some of the major tech companies like Google have reported these types of errors. Google fixed the “%2F” issue in their system after being reported, whereas Dropbox secretly fixed the issue without even explaining what they did.
How to overcome this issue as an end-user of a website that uses Service Workers
First, you must only allow service workers from trusted websites. The question is, “What if we are browsing to a completely new website that we don’t know, but want to explore every functionality of that website, including service workers?”
You can always disable/deactivate service workers for a website, even if you have allowed them access. Do this by disabling storage in chrome://settings. Service workers are linked to cookie/local data storage settings. Clearing browser data (the “Clear browsing data…” button in Settings or go to chrome://settings/clearBrowserData in the URL bar) also deletes service workers.