Sovende agenter i nettleseren: Slik utnytter pushvarsler deg uten at du merker det

Den usynlige trusselen i Web Push

Web Push har blitt en viktig del av mange moderne nettløsninger. Fra samarbeidsverktøy til varslingssystemer – teknologien er både kraftfull og praktisk. Men hva skjer når den samme mekanismen som skal holde brukerne informert, plutselig blir en usynlig angrepskanal?

Dette handler om Sleeping Agent – en sårbarhet som utnytter en svakhet i hvordan nettlesere håndhever sikkerhetskravene i Web Push API.

Hvordan angrepet fungerer

Web Push API har en innebygd beskyttelse: userVisibleOnly: true. Denne innstillingen skal sikre at alle push-meldinger resulterer i en synlig varsling for brukeren. Tanken er god, men gjennomføringen har et hull.

En ondsinnet Service Worker kan utnytte dette ved å kjøre to operasjoner rett etter hverandre:

• Vise en varsling med showNotification()
• Lukke den umiddelbart med notification.close()

Varslingen registreres i nettleserens interne database, men forsvinner før brukeren rekker å se den. Når nettleseren senere sjekker om kravet er oppfylt, ser den bare at noe ble registrert i databasen – ikke om det var fortsatt synlig på skjermen. Resultatet er at angrepskanalen forblir åpen uten at brukeren merker noe.

Hvorfor dette er bekymringsfullt

Sårbarheten rammer ikke bare en enkelt funksjon. Den svekker tilliten til hele Web Push-systemet:

• Usynlig tilkobling: Angripere kan opprette en permanent kanal uten brukernes kunnskap. Bare å besøke en kompromittert nettside er nok.
• Brudd på reguleringer: Mange rammeverk bygger på at varslinger skal være synlige. Dette angrepet eroderer den grunnlaget.
• Støtte i flere nettlesere: Chrome, Edge og eldre Safari-versjoner er alle berørt.
• Enkel å gjennomføre: Ingen avanserte utnyttelsesverktøy er needed. Angrepet kan reproduseres i fem minutter på vanlig versjoner.

Teknisk bakgrunn

Sikkerhetssjekken skjer etter at Service Worker har sluttet å kjøre. Når push-hendelsen når frem, er her prosessen:

1. Push-hendelse arriverer
2. Service Worker viser og deretter raskt lukker en varsling
3. Arbeideren slutter å kjøre
4. Nettleseren kontrollerer om en varsling ble vist
5. Databasen viser et resultat – selv om det ikke påsken på skjermen
6. Sjekken passerer
7. Angrepskanalen blir godkjent

Timing-vinduet er tight, men stabilt nok til å utnytte.

Konsekvenser for utviklere

De som jobber med Web Push må nå tenke om:

• Auditering av Service Workers: Hvis en tredje part skrivekode er kompromittert, blir dette også din problem.
• Spore varslingens livsløp: Med logging rundt showNotification() og close() kan du oppdage unaturlige mønstre.
• Verifisere kilden til push-meldinger: Cryptographic verification kan sikre at meldinger kommer fra din server, kun ikke en angriper.

Hva betyr dette for hele feltet

Sikkerhetskravene i W3C-specifikasjonen er godt skrevet, men de må også være praktisk håndhevet. Når sjekken tar fehl av at noe er registrert i en database, i stedet for å sjekke hva som er synlig på skjermen, er det et stort gap.

Hva skal du gjøre nå

Nettlesere er på vei med fixes. Hvis du kjører produksjonssystemer:

1. Monitorer Service Worker-aktivitet for unaturlige varslingspatterns
2. Verifiser sendere på servernivå
3. Hold nettlesere oppdatert
4. Vurder om Web Push er passende for dine sensitive data

Web Push er still en verdifull teknologi. Bare nå må vi være mer forsiktig med dens angrepsflate.