Service Workers zijn scripts die op de achtergrond draaien, los van webpagina's, en functies zoals offline-functionaliteit en push-notificaties mogelijk maken. Hoewel krachtig, vereisen ze zorgvuldige beveiligingsoverweging aangezien ze netwerkverzoeken kunnen onderscheppen en wijzigen. Ze moeten via HTTPS worden geserveerd en same-origin restricties volgen.
Een service worker is een JavaScript-bestand dat de browser registreert om op de achtergrond te draaien, losgekoppeld van elke afzonderlijke pagina en zelfs wanneer er geen tabblad open is. Hij fungeert als een programmeerbare netwerkproxy tussen de site en het netwerk: via het fetch-event kan hij uitgaande verzoeken onderscheppen, ze vanuit een cache beantwoorden, ze herschrijven of ze doorsturen. Dat is wat offline-ervaringen, achtergrondsynchronisatie en pushmeldingen in progressive web apps aandrijft. Service workers zijn event-gestuurd en hebben geen DOM-toegang; ze communiceren met pagina's via berichten. Registratie is streng ingekaderd: ze moeten via HTTPS worden geserveerd, gehoorzamen aan de same-origin policy, en hun bereik is beperkt tot het pad vanwaar ze worden geserveerd.
Omdat een service worker elk verzoek binnen zijn bereik kan onderscheppen en herschrijven en over sessies heen blijft bestaan, is het een ongewoon krachtige en duurzame positie op de client. Als een aanvaller erin slaagt een kwaadaardige worker te registreren, bijvoorbeeld via een upload-endpoint dat door de aanvaller beheerde JavaScript op een breed bereik serveert, of door een bestaand script-injectielek te misbruiken, verkrijgt hij een blijvende man-in-the-browser-voet aan de grond die pagina-herlaadbeurten overleeft en stilletjes verkeer kan manipuleren, nepcontent kan serveren of gegevens kan oogsten lang nadat het oorspronkelijke toegangspunt is gesloten. De HTTPS- en same-origin-vereisten bestaan juist omdat deze mogelijkheid catastrofaal zou zijn als een netwerkaanvaller of een vreemde origin er een zou kunnen planten.
Vergrendel waar scripts vandaan geserveerd kunnen worden, zodat een aanvaller geen worker op een bruikbaar bereik kan hosten: saneer en stel het content-type in van gebruikersuploads, vermijd het serveren van door gebruikers beheerde JavaScript vanaf je origin, en beperk het registratiebereik met de Service-Worker-Allowed-header. Een Content Security Policy met worker-src beperkt welke scripts worker kunnen worden, en Subresource Integrity plus review van build-pipelines beschermt het legitieme worker-bestand zelf. cside vult dit aan door de third-party-scripts die een pagina laadt te proxyen en te analyseren en kwaadaardig gedrag in realtime te blokkeren; het resulterende forensische verslag van uitgevoerde code helpt onderzoekers te reconstrueren hoe een malafide worker of geïnjecteerd script de browser bereikte.
Een service worker heeft geen directe DOM-toegang en kan document.cookie niet aanraken, omdat hij buiten de hoofdthread draait. Hij kan echter wel netwerkverzoeken binnen zijn bereik onderscheppen en hun headers en bodies inspecteren of aanpassen, wat hem aanzienlijke invloed geeft op de gegevens die van en naar de pagina stromen.
Een service worker kan al het netwerkverkeer binnen zijn bereik onderscheppen en herschrijven, dus toestaan dat er een via platte HTTP wordt geïnstalleerd zou een man-in-the-middle op het netwerk in staat stellen een blijvende proxy in de browser van het slachtoffer te planten. Het vereisen van HTTPS zorgt ervoor dat het worker-script geauthenticeerd en ongemanipuleerd is voordat de browser het die macht verleent.
We answer client-side security questions every day. Bring yours.