Skip to main content
Blog
Blog

Waarom browsers steeds gevaarlijker worden

Technologieën zoals WebAssembly (WASM), WebGPU en IndexedDB hebben getransformeerd wat browsers kunnen bereiken. Deze evolutie heeft de func

Aug 23, 2024 7 min read
why-browsers-image-cover

Technologieën zoals WebAssembly (WASM), WebGPU en IndexedDB hebben getransformeerd wat browsers kunnen bereiken. Deze evolutie heeft de functionaliteit van browsers uitgebreid en de gebruiksmogelijkheden en ervaringen enorm ontwikkeld. 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.

Browsermelding waarin gebruikers wordt gevraagd Adobe Flash Player in te schakelen

Bijvoorbeeld, in 2015 onthulde 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 leidde tot mogelijke 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 geteisterd door beveiligingskwetsbaarheden. Een belangrijke inbreuk vond plaats in 2012, toen een zero-day kwetsbaarheid in Java SE 7 werd ontdekt en snel 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 CVE-2016-0034 kwetsbaarheid in Silverlight, gevonden via gelekte Hacking Team-gegevens. Deze zero-day exploit, verhandeld door een Russische hacker, kon beveiligingen in IE en Firefox omzeilen.

Logo van Microsoft Silverlight, een uitgefaseerde browserplug-in

Een laatste voorbeeld komt van Adobe in 2012, waar een exploit werd ontdekt die in staat was om de beveiliging van computers met Adobe X en XI (Adobe Reader 10 en 11) te 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. Dit 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 behulp van 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, waarbij de apparaten van bezoekers werden gebruikt om cryptocurrency te mijnen.

In 2021 werd een andere kwetsbaarheid in WASM gevonden. Het 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 talrijke 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 direct vanuit de browser gebruik te maken van GPU-kracht. Dit 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 trad een kwetsbaarheid op toen een speciaal vervaardigde 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 hun eigen code met behulp van JavaScript en WebGPU en keken vervolgens wanneer hun gegevens uit de cache werden verwijderd door invoer. Deze methode stelde hen in staat om snel en nauwkeurig toetsaanslagen te analyseren. Ze konden ook sleutels verkrijgen die werden gebruikt voor GPU-gebaseerde AES-encryptie. Deze aanval kon zelfs heimelijk gegevens verzenden 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 betekent de toegenomen gegevensopslagcapaciteit ook dat meer gevoelige gegevens risico lopen.

Bijvoorbeeld, in 2022 stelde 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 door een regelovertreding. De regel zegt dat databasenamen gescheiden moeten worden gehouden, maar ze werden gedeeld tussen verschillende websites, waardoor deze websites konden zien welke andere sites werden bezocht in dezelfde browsersessie.

Apple loste het probleem op binnen een week in de macOS Monterey 12.2 en iOS 15.3 updates.

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 door onze detectie-engine en filteren we autonoom eventuele potentiële problemen eruit. Je krijgt volledige zichtbaarheid in wat de code doet, inclusief potentiële bedreigingen. Bovendien optimaliseren we de scripts vaak om sneller te draaien.

Maar kunnen we helpen tegen de hierboven genoemde gevallen?

Het spreekt voor zich dat detectiesystemen continue updates vereisen om volledig nieuwe variaties of methoden om informatie te verbergen te identificeren. Belangrijk om te weten is dat we de gevraagde code bewaren, waardoor we je de nodige gegevens kunnen verstrekken om te bepalen wat er mis ging, ongeacht of we het probleem hebben geïdentificeerd of niet.

Dat gezegd hebbende, hier is hoe we je vandaag kunnen beschermen tegen de bovengenoemde 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 anomalieën te detecteren die wijzen op side-channel aanvallen. Door verdachte activiteit te identificeren voordat de browser het script rendert, kan cside potentieel kwaadaardige scripts blokkeren of markeren voordat ze kunnen exploiteren, ook inclusief GPU-bronnen.

IndexedDB: we monitoren de volledige code, inclusief alle aanroepen naar gevoelige API's zoals IndexedDB.

Andere best practices:

  1. Regelmatige Updates: Houd alle geïnstalleerde tools up-to-date om ervoor te zorgen dat je de nieuwste beveiligingspatches hebt. Verwijder ongebruikte scripts.
  2. Web Application Firewalls (WAF): Implementeer WAF's om een extra beveiligingslaag toe te voegen, die webapplicaties beschermt tegen verschillende aanvallen.
  3. Educeer Gebruikers: Train indien mogelijk gebruikers over de risico's van phishing en social engineering-aanvallen, die kunnen leiden tot gecompromitteerde beveiliging.
  4. Verminder 3rd party scripts: importeer alleen die welke cruciaal zijn en heb een duidelijk plan op welke pagina's dergelijke scripts toegang moeten hebben.
  5. Gebruik Multi-Factor Authenticatie (MFA): Gebruik MFA om een extra beveiligingslaag toe te voegen aan gebruikers- en beheerdersaccounts, waardoor ongeautoriseerde toegang moeilijker wordt.
  6. Content Security Policy (CSP): Implementeer CSP om cross-site scripting (XSS) aanvallen te voorkomen door te controleren welke bronnen de browser mag laden. Onthoud dat CSP's op zichzelf enkele belangrijke beperkingen hebben, waar we meer over 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 van mobiele apps die transformeren naar Progressive Web Apps (Een gedetailleerd artikel over dit onderwerp is momenteel in ontwikkeling). PWA's zullen naadloozer worden en een native app-achtige ervaring bieden op alle apparaten. Ook de verdere integratie van AI en verbeteringen in privacy en online identiteit zullen onze browsers blijven vormgeven.

Wees gerust, we ontwikkelen voor de toekomst en verbeteren voortdurend onze diensten en detectie-engines om een groter gebied van de client-side beveiligingsruimte te dekken.

Je kunt gratis aan de slag gaan en je site(s) beveiligen, en upgraden om toegang te krijgen tot meer functies zoals je wilt. Je kunt ons change log volgen om updates en toekomstige potentiële ontwikkelingen te zien.

Als je met ons supportteam wilt spreken over een specifiek probleem of zorg, kun je dat hier doen.

Simon Wijckmans
Founder & CEO

Founder and CEO of cside. Previously a product manager on Cloudflare Page Shield (now Cloudflare Client-Side Security). Co-chair of the W3C Anti-Fraud Community Group and a Forbes 30 Under 30 honoree. Building accessible security against client-side attacks — web security is not an enterprise-only problem.

FAQ

Frequently Asked Questions

Browsers krijgen elk jaar meer mogelijkheden — service workers, WebGPU, WebRTC, native bestandsystem — en het grootste deel van de applicatielogica draait nu client-side. Daarmee is de browser de krachtigste runtime die een aanvaller kan bereiken zonder ooit je server aan te raken.

Ja. Flash en Silverlight leerden de industrie dat browser-resident code met brede permissies een waardevol doelwit wordt. Dezelfde les geldt voor moderne third-party scripts, alleen zonder installatiepop-up.

Monitor en Beveilig Je Third-Party Scripts

Gain full visibility and control over every script delivered to your users to enhance site security and performance.

Start gratis, of probeer Business met een proefperiode van 14 dagen.

cside dashboard interface met script monitoring en beveiligingsanalytics
Related Articles
Boek een demo