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.”
A service worker is a JavaScript file that runs separately from a webpage in the background of the browser. It helps in managing events fired either by the browser or by the web page. It does not need a web page to be opened and it does not show any markup, where it excels is listening to system events. What’s exciting is that it can fetch events intercepting and responding to network requests. Because the service worker can listen for events when the page isn’t open, it is virtually between the network and the browser, giving permission to the service worker to provide content even when offline. It can respond to push messages sent from the server to the browser. Imagine a chat web client that lets you know you’ve got a new unread message. This simply wasn’t possible before.
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.
In spite of myriad functionalities from service workers, there is a negative side to them that needs attention. Service workers let JavaScript code run on a specific domain/origin; then they register a handler for a part of the URL space of that domain/origin. Now, the subsequent requests made by the browser are passed through the handler.
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.)
Clear-Site-Data
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.
Example:
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.
References:
https://developers.google.com/web/fundamentals/primers/service-workers/
https://love2dev.com/pwa/marionet-attack/
https://www.ghacks.net/2019/02/26/marionet-attack-lets-hackers-control-your-browser-even-after-you-leave-the-attack-page/ – (MarioNET Attack)
