Technologieën zoals WebAssembly (WASM), WebGPU en IndexedDB hebben getransformeerd wat browsers kunnen bereiken. Deze evolutie heeft de functionaliteit van browsers uitgebreid. Deze toegenomen complexiteit brengt echter ook een aanzienlijk cybersecurityprobleem met zich mee: een vergroot aanvalsoppervlak.
Om te begrijpen waar we vandaag staan, laten we een reis maken door de geschiedenis.
Weet je nog toen je Flash Player nodig had om rijke multimedia-inhoud op websites te bekijken? Adobe Flash was revolutionair voor zijn tijd en maakte animaties, games en interactieve applicaties mogelijk. Maar het stond ook berucht om zijn beveiligingskwetsbaarheden en frequente updates.
Zo onthulde in 2015 het lek van het controversiële bedrijf Hacking Team meerdere zero-day-kwetsbaarheden in Flash Player die werden gebruikt om gebruikers over de hele wereld te targeten. Deze exploits stelden aanvallers in staat om willekeurige code uit te voeren op de machines van gebruikers, wat kon leiden tot gegevensdiefstal, malware-installatie en meer. De komst van HTML5 en JavaScript markeerde het begin van het einde voor Flash, en bood veiligere en veelzijdigere manieren om interactieve webinhoud te creëren.
Java-applets werden ook geplaagd door beveiligingskwetsbaarheden. Een belangrijke inbreuk vond plaats in 2012, toen een zero-day-kwetsbaarheid in Java SE 7 werd ontdekt en snel actief werd misbruikt. Deze exploit stelde aanvallers in staat om beveiligingsbeperkingen te omzeilen en willekeurige code uit te voeren op de getroffen systemen, wat leidde tot wijdverspreide malware-infecties. Het omslachtige updateproces en de opkomst van veiligere en efficiëntere webtechnologieën zoals HTML5, CSS3 en moderne JavaScript-frameworks leidden tot de geleidelijke neergang van Java-applets.
Microsoft Silverlight is een ander voorbeeld, uit 2016. De kwetsbaarheid CVE-2016-0034 in Silverlight werd gevonden via gelekte Hacking Team-gegevens. Deze zero-day-exploit, verhandeld door een Russische hacker, kon beveiligingen in IE en Firefox omzeilen.
Een laatste voorbeeld komt van Adobe in 2012, waar een exploit werd ontdekt die de beveiliging van computers met Adobe X en XI (Adobe Reader 10 en 11) kon compromitteren. Deze kwetsbaarheid stelde aanvallers in staat om de sandbox-bescherming van Reader te omzeilen.
Dit is een verhaal zo oud als de tijd. Met nieuwe vooruitgang komen nieuwe problemen.
Nieuwe browserkwetsbaarheden:
WASM (WebAssembly)
WASM maakt het mogelijk dat high-performance applicaties in de browser draaien, waardoor taken zoals 3D-rendering en complexe berekeningen mogelijk worden. Dat is geweldig voor het creëren van meer interactieve en visueel aantrekkelijke webapplicaties.
In 2018 demonstreerden onderzoekers echter hoe WebAssembly kon worden gebruikt om zeer efficiënte cryptojacking-malware te creëren, die cryptocurrency mijnde met de CPU-bronnen van het slachtoffer.
Een voorbeeld is toen het CoinHive-script, dat cryptocurrency mijnt, werd ingevoegd in de BrowseAloud-service. Dit zorgde ervoor dat het script draaide op de computers van duizenden bezoekers zonder hun medeweten. Dankzij WebAssembly werkte het script soepel en heimelijk, en gebruikte het de apparaten van bezoekers om cryptocurrency te mijnen.
In 2021 werd nog een kwetsbaarheid in WASM gevonden. Deze maakte een stack overflow mogelijk door de stack size tracking in de Low-Level Interpreter (LLInt) te manipuleren. Door een WebAssembly-functie te maken die veel push-operaties uitvoerde, werd een integer overflow veroorzaakt, wat leidde tot remote code execution. Deze exploit, gedemonstreerd op Pwn2Own 2021, maakte gebruik van geheugenlekken en een Return-Oriented Programming (ROP)-chain om willekeurige code-uitvoering te bereiken. Het probleem werd gepatcht in Safari 14.1.1 (CVE-2021-30734).
WebGPU
WebGPU biedt high-level grafische functies. Het stelt ontwikkelaars in staat om rechtstreeks vanuit de browser gebruik te maken van GPU-kracht. Dat is geweldig voor het creëren van gedetailleerde grafische apps en games rechtstreeks in de browser.
Dit opende opnieuw een nieuw pad voor aanvallen. In 2022 deed zich een kwetsbaarheid voor toen een speciaal geprepareerde webpagina een use-after-free-conditie veroorzaakte, waardoor een aanvaller mogelijk willekeurige code kon uitvoeren. Cisco Talos coördineerde met Google om ervoor te zorgen dat het probleem werd gepatcht in Chrome-versies 102.0.4956.0 en 99.0.4844.82.
In april 2024 toonden wetenschappers van de Universiteit van Graz en de Universiteit van Rennes aan dat WebGPU kon worden aangevallen. Ze vulden de cache met eigen code via JavaScript en WebGPU, en observeerden vervolgens wanneer hun gegevens uit de cache werden verwijderd doordat er invoer plaatsvond. Met deze methode konden ze toetsaanslagen snel en nauwkeurig analyseren. Ze konden ook sleutels achterhalen die werden gebruikt voor GPU-gebaseerde AES-encryptie. Deze aanval kon zelfs heimelijk gegevens naar buiten sturen, met snelheden tot 10 Kb/s.
IndexedDB
IndexedDB is een low-level API voor het opslaan van grote hoeveelheden gestructureerde gegevens, waardoor complexe offline-applicaties mogelijk worden. Deze technologie ondersteunt geavanceerde webapplicaties die offline moeten functioneren, zoals progressive web apps (PWA's).
Maar opnieuw geldt: meer opslagcapaciteit betekent ook dat meer gevoelige gegevens risico lopen.
Zo stelde in 2022 een kwetsbaarheid in Safari 15's IndexedDB-implementatie elke website in staat om de internetactiviteit van een gebruiker te volgen en mogelijk hun identiteit te onthullen. Het probleem ontstond doordat een regel werd overtreden. Die regel schrijft voor dat databasenamen strikt gescheiden moeten blijven, maar ze werden gedeeld tussen verschillende websites, waardoor deze websites konden zien welke andere sites in dezelfde browsersessie waren bezocht.
Apple loste het probleem op binnen een week, in de updates macOS Monterey 12.2 en iOS 15.3.
Kan cside je in deze gevallen beschermen?
Bij cside beschermen we je sites tegen schadelijke of gecompromitteerde third-party scripts. Door ons script boven alle andere te plaatsen, proxyen we ze via onze detectie-engine en filteren we autonoom eventuele problemen eruit. Je krijgt volledig inzicht in wat de code doet, inclusief mogelijke bedreigingen. Ook optimaliseren we scripts vaak zodat ze sneller draaien.
Maar kunnen we ook helpen tegen de hierboven genoemde gevallen?
Detectiesystemen hebben continue updates nodig om volledig nieuwe varianten of methoden om informatie te verbergen te herkennen. Wij bewaren de opgevraagde code, zodat je over de gegevens beschikt die nodig zijn om te bepalen wat er misging, ongeacht of wij het probleem hebben gesignaleerd of niet.
Zo beschermen we je vandaag tegen de hierboven genoemde aanvallen:
WASM (WebAssembly): cside monitort en controleert de uitvoering van third-party scripts. WASM-specifieke monitoring staat op de roadmap om later te worden toegevoegd, en wordt een steeds gevaarlijker aanvalsoppervlak.
WebGPU: we kunnen scriptgedrag en resourcegebruik volgen en analyseren, inclusief GPU-toegangspatronen, om afwijkingen te detecteren die wijzen op side-channel-aanvallen. Door verdachte activiteit te identificeren vóórdat de browser het script rendert, kan cside potentieel kwaadaardige scripts blokkeren of markeren voordat ze misbruik kunnen maken, ook van GPU-bronnen.
IndexedDB: we monitoren de volledige code, inclusief alle aanroepen naar gevoelige API's zoals IndexedDB.
Overige best practices:
- Regelmatige updates: houd alle geïnstalleerde tools up-to-date, zodat je over de nieuwste beveiligingspatches beschikt. Verwijder ongebruikte scripts.
- Web Application Firewalls (WAF): implementeer WAF's om een extra beveiligingslaag toe te voegen die webapplicaties beschermt tegen diverse aanvallen.
- Educeer gebruikers: train, waar mogelijk, gebruikers over de risico's van phishing en social engineering, die kunnen leiden tot gecompromitteerde beveiliging.
- Verminder third-party scripts: houd alleen de scripts die je nodig hebt, en zorg voor een duidelijk plan van welke pagina's elk script mag benaderen.
- Gebruik Multi-Factor Authenticatie (MFA): gebruik MFA om een extra beveiligingslaag toe te voegen aan gebruikers- en beheerdersaccounts, waardoor ongeautoriseerde toegang moeilijker wordt.
- Content Security Policy (CSP): implementeer CSP om cross-site scripting (XSS)-aanvallen te voorkomen door te bepalen welke bronnen de browser mag laden. Onthoud dat CSP's op zichzelf enkele belangrijke beperkingen hebben, waarover we meer hebben geschreven [hier](https://cside.com/compare#:~:text=Detecting%20Scripts-,Content%20Security%20Policies%20(CSP%29,-JS%20Based).
Hoe ziet de toekomst van de browser eruit?
Browsers zullen blijven evolueren. Men zou half-schertsend kunnen beweren dat alles een browser wordt, gezien de trend waarbij mobiele apps transformeren naar Progressive Web Apps (een gedetailleerd artikel over dit onderwerp is momenteel in de maak). PWA's zullen naadlozer worden en op alle apparaten een native app-achtige ervaring bieden. Ook de verdere integratie van AI en verbeteringen op het gebied van privacy en online identiteit zullen onze browsers blijven veranderen.
We verbeteren onze diensten en detectie-engines voortdurend om een groter deel van de client-side-beveiligingsruimte te dekken.
Je kunt gratis aan de slag gaan en je site(s) beveiligen, en naar wens upgraden om toegang te krijgen tot meer functies. Je kunt onze changelog volgen om updates te zien en wat er nog komt.
Als je met ons supportteam wilt spreken over een specifiek probleem of zorg, kun je dat hier doen.
