JavaScript-injectie treedt op wanneer een aanvaller erin slaagt ongeautoriseerde JavaScript-code in te voegen en uit te voeren in een webapplicatie. Dit kan leiden tot gegevensdiefstal, sessie-kaping of andere kwaadaardige acties. Preventie vereist juiste inputvalidatie, output-encoding, implementatie van Content Security Policy en zorgvuldige omgang met dynamische code-evaluatie.
JavaScript-injectie is het invoegen en uitvoeren van ongeautoriseerde JavaScript binnen een webapplicatie. Het bereikt de browser via verschillende routes: cross-site scripting-fouten die onge-escapete invoer in een pagina weergeven, onveilige dynamische evaluatie van strings via eval, de Function-constructor of timer-callbacks, gecompromitteerde of kwaadaardige third-party scripts geladen vanaf een CDN, en door de aanvaller beheerste data die in een scriptcontext wordt geschreven. Zodra de code draait, behandelt de browser die als legitiem script dat bij de origin van de site hoort. Sommige definities omvatten ook self-XSS via de browserconsole en bookmarklets, waarbij een gebruiker wordt misleid om aanvallerscode te plakken. In elk geval is het bepalende kenmerk dat JavaScript die de ontwikkelaar nooit bedoeld heeft, uiteindelijk binnen de pagina uitvoert.
Geïnjecteerde JavaScript draait met het volledige gezag van de origin van de pagina, dus zijn bereik is breed. Het kan cookies, sessietokens en DOM-inhoud lezen en exfiltreren, sessies kapen, toetsaanslagen en formuliervelden loggen, stilletjes requests versturen, de interface herschrijven en verdere payloads laden. Op afrekenpagina's is dit het mechanisme achter digitale skimmers en Magecart: een paar regels toegevoegd aan een vertrouwd script kopiëren stilletjes kaart- en adresvelden naar het domein van een aanvaller, terwijl serverlogs en firewalls niets zien, omdat de diefstal volledig in de browser gebeurt. Aanvallers verhullen de code doorgaans en beperken die tot specifieke pagina's of voorwaarden om controle te ontwijken, waardoor één geïnjecteerd script maandenlang onopgemerkt bij veel gebruikers kan draaien.
Verklein het oppervlak door dynamische code-evaluatie te elimineren, output te encoderen, invoer te valideren en een strikte Content Security Policy met nonces of Subresource Integrity af te dwingen, zodat alleen gecontroleerde scripts draaien. Maar een CSP vertrouwt scripts op basis van hun brondomein, dus een gecompromitteerde toegestane vendor voert nog steeds uit. Hier past cside direct in: het routeert third-party scripts via een Script-methode en analyseert de daadwerkelijke JavaScript-payload voordat die draait, waarbij het kwaadaardig gedrag betrapt, zoals het lezen van kaartvelden of contact opnemen met een onbekend domein, op basis van wat de code doet in plaats van waar die vandaan geladen wordt. cside kan dat gedrag in real time blokkeren en houdt een forensisch verslag bij van de exacte code die draaide, wat is wat PCI DSS 6.4.3 en 11.6.1 vereisen.
XSS is de meest voorkomende manier waarop JavaScript-injectie plaatsvindt, door script te injecteren via onge-escapete invoer. Maar injectie kan ook optreden zonder een klassieke XSS-bug: via een gecompromitteerd third-party script, onveilige evaluatie van dynamische data, of een misleide gebruiker die code in de console plakt. XSS is één route naar JavaScript-injectie, niet de enige.
Een CSP beperkt welke domeinen en inline scripts mogen draaien, wat veel injecties blokkeert, maar het vertrouwt elk script dat vanaf een toegestane bron wordt geserveerd. Als een vendor die je al toestaat wordt gecompromitteerd, voert de geïnjecteerde code uit als legitiem. Dat stoppen vereist het inspecteren van wat elk script daadwerkelijk doet, niet alleen waar het vandaan komt.
We answer client-side security questions every day. Bring yours.