Browserlaag scriptactiviteitsregistratie is het real-time vastleggen van wat JavaScript uitvoert in de browser van een gebruiker: elke DOM-lezing, toegang tot formuliervelden, netwerkverzoek, cookie-schrijfoperatie en dynamische scriptinjectie door eigen en derde-partij code tijdens een actieve sessie. Het is de registratielaag die SIEM-, EDR- en WAF-tools niet kunnen bereiken, en waar Magecart-skimming, supply chain-compromitteringen en sessiekaping-scripts worden uitgevoerd.
De meeste beveiligingsteams hebben goede registratie op server-, netwerk- en endpointlagen. De browser-runtime, waar scripts van derden worden uitgevoerd met dezelfde rechten als eigen code, is bijna altijd niet gemonitord. Deze gids behandelt wat een browserscriptactiviteitslogboek vastlegt, waarom de kloof er toe doet en hoe effectieve incidentrespons eruitziet wanneer een script op uw site is gecompromitteerd.
De registratiekloof die de meeste stacks openlaten
Een typische enterprise-beveiligingsstack registreert de volgende lagen:
| Laag | Wat wordt geregistreerd | Typische tools |
|---|---|---|
| Netwerk | HTTP/S-verkeer, DNS, firewall-events | WAF, NGFW, NDR |
| Endpoint | OS-aanroepen, procesuitvoering, bestandsschrijfoperaties | EDR, XDR |
| Server | Applicatielogs, authenticatie-events, API-aanroepen | SIEM (via agents/connectoren) |
| Browser-runtime | JavaScript-uitvoering, DOM-lezingen, scriptgedrag | Ontbreekt in de meeste stacks |
De browser-runtime is waar client-side aanvallen plaatsvinden. Een Magecart-script leest de waarde van een betalingskaartenveld en stuurt dit naar een externe server. Die lezing vindt volledig plaats binnen de browser. De netwerklaag ziet een HTTPS-POST nadat de gegevens al zijn vertrokken. De EDR detecteert geen afwijkend proces. De SIEM heeft geen vermelding. De aanval wordt voltooid met schone logs overal, en daarom instrumenteren teams die Magecart in real-time willen detecteren de browser zelf.
Bij één GET /pricing vanaf één IP komen de twee lagen tot tegengestelde oordelen:
| Wat de netwerk-/serverlaag ziet | Wat de browsersessielaag ziet |
|---|---|
| IP: residentieel proxy | Aanwijzer: 0 px bewogen |
| TLS: Chrome 124-fingerprint | Verblijftijd: 0,2 s per pagina |
| Cookie: geldige sessie | Navigatie: strikt sequentieel |
| User-Agent: Chrome 124 | Scrollen: geen |
| Oordeel: geen afwijking, schone load | Oordeel: geclassificeerd als geautomatiseerd, sessie met rate-limiting |
De headers ogen menselijk, dus WAF, CDN en IP-inspectie laten de aanvraag door. Dezelfde sessie, gelezen op de browserlaag, beweegt nooit een aanwijzer, blijft 0,2 seconde per pagina en doorloopt pagina's in strikte volgorde zonder te scrollen: de netwerk-blinde vlek is precies waar cside hem betrapt.
De Polyfill[.]io supply chain-compromittering in juni 2024 toonde dit op grote schaal aan. Een veel gebruikt CDN-gehoste script werd aangepast om kwaadaardige payloads te serveren aan meer dan 490.000 websites. De WAF, SIEM en EDR van elk getroffen site hadden schone logs. De enige tools die de anomalie konden detecteren, waren die welke werkten op de browseruitvoeringslaag.
Wat een volledig browserscriptactiviteitslogboek vastlegt
Een nuttig browserlaag-activiteitslogboek registreert zes categorieën scriptgedrag:
1. DOM-toegang en mutaties
Welke elementen een script leest of schrijft, met speciale aandacht voor invoervelden, formulierelementen en wachtwoordvelden. Een script op een betaalpagina dat nog nooit eerder het kaartnummerveld had gelezen maar dit doet bij een nieuwe implementatie, is een gedragsafwijking die onmiddellijk moet worden gemarkeerd.
2. Netwerkverzoeken
Elke fetch(), XMLHttpRequest, navigator.sendBeacon(), afbeeldingspixel en WebSocket-verbinding geïnitieerd door een script, inclusief het doeldomein, de verzoekmethode en of de bestemming nieuw of eerder gezien is. Nieuwe uitgaande bestemmingen zijn de primaire indicator van gegevensexfiltratie.
3. Cookie- en opslagtoegang
Welke scripts cookies, localStorage en sessionStorage lezen of schrijven. Legitieme analysescripts hebben zelden sessietokens nodig. Als er een begint met het lezen ervan, moet het gedrag worden gemarkeerd.
4. Dynamische scriptinjectie
Scripts die nieuwe <script>-elementen maken of eval(), Function() of document.write() gebruiken om nieuwe code tijdens runtime uit te voeren. Dit is hoe malware van de tweede fase wordt geladen bij supply chain-aanvallen: het eerste script is schoon en het haalt de daadwerkelijke payload dynamisch op en voert die uit.
5. Subresourceverzoeken en vierde-partij-afhankelijkheden
Scripts die aanvullende externe bronnen laden, waardoor een keten wordt gecreëerd van uw goedgekeurde derde partij naar een niet-goedgekeurd vierde-partijdomein. De Polyfill[.]io-aanval gebruikte dit patroon: het gecompromitteerde CDN-script laadde door de aanvaller gecontroleerde code van een afzonderlijk domein.
6. Gedragsbasislijn-afwijkingen
Het meest bruikbare signaal is niet één enkel event maar een afwijking van het vastgestelde gedrag. Een script dat zes maanden op uw betaalpagina heeft gedraaid en nog nooit toegang had tot formuliervelden, maar plotseling kaartinvoerwaarden begint te lezen in één op de duizend sessies: dat is het detectie-event.
Incidentrespons voor browserscriptaanvallen
Effectieve incidentrespons voor een browser-scriptcompromittering volgt een andere workflow dan incidenten aan de serverzijde. De tijdlijn is gecomprimeerd omdat gegevens in milliseconden kunnen worden geëxfiltreerd en het aanvalsoppervlak elke gebruikerssessie is die het gecompromitteerde script uitvoert.
Detecteren
Detectie berust op gedragsanomalie-waarschuwingen, niet op handtekeningovereenkomst. Handtekeninggebaseerde detectie faalt bij polymorfische en versleutelde payloads hier in detail beschreven. De trigger voor een browserlaag-incident moet zijn: een bekend script dat toegang heeft tot gegevenstypen die het nog nooit eerder had benaderd, of een script dat netwerkverzoeken doet naar een bestemming buiten het vastgestelde gedragsprofiel.
Een real-time waarschuwing, niet een volgende-dag SIEM-batch, is de minimumstandaard. Tegen de tijd dat een dagelijkse logreview een Magecart-script opmerkt, kunnen tienduizenden sessies al zijn blootgesteld.
Bevatten
Inperking op de browserlaag verloopt anders dan inperking op endpointniveau. Opties zijn onder andere:
- Het specifieke netwerkverzoek blokkeren: voorkomen dat de exfiltratie-aanroep wordt voltooid door het uitgaande verzoek van het kwaadaardige script te onderscheppen.
- Het script zelf blokkeren: voorkomen dat het gecompromitteerde script wordt geladen bij volgende paginaladingen, waardoor het aanvalsoppervlak onmiddellijk wordt verkleind.
- Waarschuwen zonder te blokkeren: gebruiken voor detecties met minder vertrouwen waarbij het risico op vals-positieven hoog is. Registreert het event en waarschuwt het team zonder zichtbare impact voor gebruikers.
De mogelijkheid om te blokkeren zonder een code-deployment, rechtstreeks vanuit een monitoringplatform zonder de broncode van de site aan te raken, is essentieel voor de snelheid van inperking. Code-deployments duren uren; blokkering op browserlaag kan vrijwel onmiddellijk zijn.
Onderzoeken
De onderzoeksstap vereist een logboek van wat er in getroffen sessies is gebeurd. Zonder een browseractiviteitslogboek is deze stap vrijwel onmogelijk. Met zo'n logboek kan het onderzoek beantwoorden:
- Welke sessies draaiden de gecompromitteerde scriptversie?
- Tijdens die sessies, tot welke gegevensvelden had het script toegang?
- Waarheen werden de netwerkverzoeken gestuurd?
- Was de exfiltratie voltooid (reageerde de bestemming) of werd deze onderbroken?
Dit logboek is ook het bewijsdossier voor beslissingen over melding van datalekken op grond van artikel 33 van de AVG (meldingsdrempel van 72 uur) en PCI DSS-vereisten. Zonder dit logboek is de standaardaanname onder de meeste frameworks dat alle blootgestelde sessies zijn gecompromitteerd.
Herstellen
Herstel na een browser-scriptcompromittering omvat: het verwijderen of terugzetten van de gecompromitteerde scriptversie, bevestigen dat het exfiltratie-eindpunt van de aanvaller is geblokkeerd op netwerkniveau, beoordelen welke gebruikerssessies een melding vereisen en de gedragsbasislijn van het script bijwerken zodat de volgende afwijking sneller wordt gedetecteerd.
De post-incident review moet beoordelen of het detectie-tot-inperkings-venster een aanvaardbare drempel heeft gehaald. Voor scripts op betaalpagina's onder PCI DSS-vereisten 6.4.3 en 11.6.1 is de verwachting real-time detectie van ongeautoriseerde scriptwijzigingen, niet uren of dagen later.
Hoe platforms voor browserscriptactiviteitsregistratie te evalueren
Niet alle monitoringtools die beweren browserlaag-zichtbaarheid te bieden, instrumenteren daadwerkelijk de browser-runtime. Vragen om te stellen tijdens productevaluatie:
| Evaluatiegebied | Waar op te letten | Rode vlag |
|---|---|---|
| Registratiemethode | Agent of SDK die in de browser draait en uitvoering observeert | Crawler die sessies extern simuleert |
| Dekking | Alle sessies, niet een steekproef | Steekproeven betekent dat de meeste aanvallen niet worden geregistreerd |
| Basislijnleren | Automatisch gedragsprofiel per script per pagina | Vereist handmatige drempelconfiguratie |
| Blokkeercapaciteit | Kan scriptnetzerkverzoeken blokkeren zonder code-deployment | Alleen detectie, geen handhavingspad |
| Logbewaring | Geïndexeerde sessieniveau-logs beschikbaar voor onderzoek | Alleen geaggregeerde statistieken, geen sessiereplay |
| Compliance-bewijs | Exporteerbare logs gekoppeld aan PCI DSS 6.4.3/11.6.1 en AVG artikel 32 | Geen gestructureerde compliance-uitvoer |
Het belangrijkste onderscheid is de instrumentatiemethode. Een externe scanner bezoekt uw pagina vanuit een headless browser en registreert wat het tijdens die kunstmatige sessie observeert. Een aanvaller die alleen activeert tegen echte gebruikers, een veelgebruikte ontwijkingstechniek, is onzichtbaar voor een scanner. Runtime-instrumentatie die in elke echte gebruikerssessie draait, legt vast wat scanners missen.
Waar cside past
cside is browser-native scriptactiviteitsregistratie en handhaving gebouwd specifiek voor het risico van JavaScript van derden. Het instrumenteert de browseruitvoeringslaag in elke echte gebruikerssessie en registreert de zes hierboven beschreven categorieën: DOM-toegang, netwerkverzoeken, cookie- en opslaglezingen, dynamische scriptinjectie, subresource-ketens en gedragsafwijkingen van vastgestelde basislijnen.
Wanneer een anomalie wordt gedetecteerd, kan cside de netwerkverzoeken van het script of het script zelf blokkeren zonder een code-deployment te vereisen. Het activiteitslogboek dat het produceert is gestructureerd voor zowel incidentonderzoek als compliance-bewijs op grond van PCI DSS 6.4.3, 11.6.1 en AVG artikel 32.
Voor teams die momenteel vertrouwen op SIEM-, EDR- en WAF-dekking en ervan uitgaan dat deze drie lagen het volledige aanvalsoppervlak bedekken: ze bedekken de browser-runtime niet. Dat is de laag waar Magecart, formjacking en digital skimming, supply chain-compromitteringen en sessiekaping-scripts opereren, en het is de laag waar scriptactiviteitsregistratie en incidentrespons de grootste kloof heeft in de meeste enterprise-stacks.
