Kort samengevat: geobfusceerde JavaScript en CSP-evasie
- Passeert via declaratie: Geobfusceerde JavaScript passeert CSP door alleen te declareren wat CSP toestaat. Het kwaadaardige gedrag begint nadat het script laadt.
- Domeinen, geen integriteit: CSP staat domeinen toe, geen code-integriteit. Een gecompromitteerd vertrouwd domein passeert nog steeds. Polyfill.io passeerde CSP op 490.000 sites.
- Compliance vraagt meer: 6.4.3 en 11.6.1 vereisen detectie voorbij CSP: scriptinventaris, integriteitsverificatie, tamperdetectie.
Weinig tijd? Bekijk cside's in-browser Magecart- en skimmerblokkering. Dit dekt alles hieronder in één deployment.
Drie routes die geobfusceerde code gebruikt om CSP te omzeilen
CSP controleert bronnen, niet payloads. Drie aanvalspatronen maken gebruik van dit gat:
Compromittering van een vertrouwde CDN of externe host. Het script wordt geladen van een domein dat al op de toestemmingslijst staat. Een gewijzigde payload activeert CSP niet omdat de bron-URL ongewijzigd is. Polyfill[.]io, Magecart-aanvallen via web skimming en recente compromitteringen van analytics-CDN's volgen deze route.
Injectie in eigen bestanden. Een aanvaller met servertoegang injecteert geobfusceerde code in een bestaand eigen JavaScript-bestand. Dat bestand wordt geladen vanaf het domein van de site, dat altijd is toegestaan.
Dynamische code-opbouw tijdens uitvoering. Een goedgekeurd script laadt en stelt een kwaadaardige functie samen uit stringfragmenten tijdens uitvoering, met behulp van eval(), Function() of indirecte equivalenten. De gevaarlijke payload bestaat nooit in een geladen resource; het wordt gebouwd in de browser na een schone paginaopbouw.
Geen van deze routes schendt een brontoestemmingslijst. CSP rapporteert schoon terwijl geobfusceerde malware wordt uitgevoerd.
Hoe geobfusceerde scripts ook geautomatiseerde scanners omzeilen
Obfuscatie verwijdert de leesbare signalen waar zowel menselijke revisoren als geautomatiseerde scanners naar zoeken:
| Techniek | Wat het doet | Waarom scanners het missen |
|---|---|---|
| String-splitsing en -samenvoeging | Verdeelt URL's en sleutelwoorden in fragmenten die tijdens uitvoering worden samengevoegd | Geen volledige string verschijnt in de statische bron |
| Base64-codering met dynamische decodering | Slaat de payload op als een blob die alleen bij uitvoering wordt gedecodeerd | Lijkt op data, niet op uitvoerbare code, voor een statische analyser |
| Hexadecimale of Unicode-escape-reeksen | Codeert tekens als \x61 of A | Statische tools moeten de code uitvoeren om de echte waarde te herleiden |
| Willekeurige variabelenamen | Vervangt leesbare identifiers door willekeurige korte namen | Verwijdert het sleutelwoordsignaal waarop patroondetectoren vertrouwen |
| Dynamisch laden op laat tijdstip | Haalt de echte payload van een C2-server nadat een goedgekeurd script wordt uitgevoerd | De geladen resource verschilt bij elke scan |
Subresource Integrity (SRI)-hashes beschermen tegen stille payload-vervangingen van bekende bronnen, maar alleen wanneer een hash voor elk bestand kan worden vastgelegd. Scripts van derden die frequent worden bijgewerkt maken SRI in productie onpraktisch, wat de kern vormt van de uitdaging rond scriptintegriteitsbeheer voor dynamische scripts. SRI kan ook niet beschermen tegen payloads die dynamisch worden opgehaald van een C2-endpoint, omdat die payload niet aanwezig was toen een hash werd berekend.
Waarom statische scanners een gekaapt CDN niet zien
Tools voor statische analyse en software composition analysis lezen code voordat die draait. Ze vinden pakketten met gepubliceerde CVE's, onveilige patronen zoals innerHTML-toewijzingen uit gebruikersinvoer, en verouderde afhankelijkheden. Wat ze niet kunnen, is waarnemen wat een CDN daadwerkelijk aan de browser van een bezoeker levert.
Het polyfill[.]io-incident is het duidelijkste voorbeeld. Toen Funnull het domein in februari 2024 overnam, bleef de broncode van elke site die het script insloot ongewijzigd. Het CDN begon kwaadaardige JavaScript te injecteren in de responses die het serveerde, maar alleen voor mobiele gebruikers, alleen met een vervalste referrer, en alleen wanneer de bezoeker geen cookiepatroon had dat samenhangt met Google Analytics en ontwikkelaarstools.
Een statische scanner zou <script src="https://cdn.polyfill[.]io/v3/polyfill.min.js"> in de HTML hebben gezien en geen CVE hebben gevonden. Er was ook geen stabiele hash om vast te pinnen: het endpoint genereerde per verzoek een response, precies het geval waarin SRI niet van toepassing is. De aanval was onzichtbaar voor elke tool die code in rust analyseert. Tegen de tijd dat onderzoekers de payload in juni 2024 identificeerden, serveerden naar schatting 490.000 websites die aan echte gebruikers.
Voorwaardelijke levering maakt deze klasse moeilijk te betrappen van buiten de sessie. Aanvallers koppelen payloads aan user agent, referrer, geografie en tijdstip juist om buiten synthetische monitoring en de browserprofielen van onderzoekers te blijven. Een payload die alleen afgaat voor mobiele gebruikers in een land op een middag verschijnt nooit in een statische scan en reproduceert niet in een crawler.
Benaderingen voor bescherming tegen geobfusceerde JavaScript
| Benadering | Broncontrole | Payload-inspectie | Handelt vertrouwde host-compromittering af | Detecteert runtime dynamische injectie |
|---|---|---|---|---|
| CSP | Ja | Nee | Nee | Nee |
| Subresource Integrity (SRI) | Gedeeltelijk | Alleen hash | Gedeeltelijk | Nee |
| WAF of netwerklaagfiltering | Gedeeltelijk | Nee | Nee | Nee |
| Statische JavaScript-analyse | Nee | Gedeeltelijk | Gedeeltelijk | Nee |
| Gedragsmonitoring op browserlaag | Optioneel per beleid | Ja | Ja | Ja |
Gedragsmonitoring op browserlaag is de enige controle in deze tabel die alle drie de omzeilingsroutes overleeft. Het werkt naast CSP en dekt de zichtbaarheidslacune voor payloads die CSP openlaat.
Wat te eisen van een CSP-ontwijkingsbestendig hulpmiddel
Vier vragen voordat een leverancier op de shortlist wordt gezet:
Runtime payload-observatie. Analyseert het hulpmiddel wat scripts uitvoeren in de browser, niet alleen de URL's waarvan ze worden geladen? Vraag de leverancier om detectie te demonstreren van een script dat wordt geladen van een vertrouwd domein en een ongeautoriseerd exfiltratie-endpoint aanroept. Als de demo een kwaadaardige bron-URL nodig heeft om te activeren, is het hulpmiddel bronafhankelijk.
Detectie van geobfusceerde codepatronen. Stel specifieke vragen over string-splitsing, eval()-equivalenten en dynamische Base64-decodering. Hulpmiddelen die alleen letterlijk eval() markeren, zullen de meeste echte obfuscatie missen.
Gedragsmonitoring na het laden. Veel aanvallen halen hun echte payload van een C2-server op na het initiële laden van de pagina. Het hulpmiddel moet blijven monitoren na DOMContentLoaded, niet alleen bij de initiële verwerking.
Verklaarbare meldingen. Een melding die alleen "verdacht script gedetecteerd" zegt, is niet bruikbaar. Elke bevinding moet het script identificeren, het gedrag dat detectie activeerde en de netwerkoproep die werd geprobeerd, zodat een analist kan triageren zonder te raden.
Hoe cside past in dit plaatje
cside instrumenteert de browser via een script dat in elke bezoekersessie wordt uitgevoerd. Het observeert wat elk script van derden en elk eigen script doet tijdens uitvoering: gedane netwerkoproepen, toegepaste DOM-wijzigingen, benaderde gevoelige datavelden en gedetecteerde geobfusceerde uitvoeringspatronen.
Wanneer een gecompromitteerde CDN een geobfusceerde payload serveert aan een pagina die door cside is geïnstrumenteerd, activeert detectie op wat de payload doet tijdens uitvoering (ongeautoriseerde netwerkoproep, geobfusceerde eval-keten, data-exfiltratiepatroon) in plaats van op waar het vandaan is geladen. Een mislukking van de brontoestemmingslijst kan geen vals negatief produceren in een op gedrag gebaseerd systeem.
PCI DSS v4.0.1-vereisten 6.4.3 en 11.6.1 (verplicht sinds maart 2025) vereisen dat handelaren alle scripts op betaalpagina's autoriseren en ongeautoriseerde wijzigingen in scriptinhoud of HTTP-headers detecteren. Gedragsmonitoring op browserlaag levert het uitvoeringsgerichte bewijs dat die controles verwachten van een monitoringlaag die tot in de browser reikt in plaats van te stoppen bij de netwerkrand.
Voor meer informatie over de praktische beperkingen van CSP, zie waarom CSP niet werkt. Voor een technische analyse van obfuscatiemethoden die in echte aanvallen worden gebruikt, zie de gids voor het deobfusceren van JavaScript van derden.
