Hoe scripts van derden op een website terechtkomen
Bij het ontwikkelen van een website neem je vaak bibliotheken op om het ontwikkelproces te versnellen en het wiel niet opnieuw uit te vinden. Echter, er zijn momenten waarop je een script van een externe bron moet laden. Door recente aanvallen zoals de Polyfill domeinovername, zijn er vragen gerezen: waarom heb je überhaupt 3rd party scripts nodig? Hoe komen ze op een website terecht?
Laten we eerst de context schetsen. 3rd party scripts zijn JavaScript-bestanden die worden geserveerd vanaf een andere server dan je eigen server. Stel bijvoorbeeld dat ik mijn website run, cside.com. Deze website is gemaakt door een team van ontwikkelaars, die een aantal bibliotheken hebben gebruikt om het samen te stellen. Dit wordt vervolgens gecompileerd / getransformeerd / opgedeeld in kleinere, minder JavaScript-bestanden dan de broncode oorspronkelijk was opgebouwd. Dit noemen we 1st party JavaScript – het wordt geserveerd als een resource binnen cside.com, bijvoorbeeld cside.com/_next/static/chunks/main-ab76c1828cff9b09.js.
Een week later vraagt een marketingteamlid de ontwikkelaars om een script toe te voegen aan de site voor hun analytics-product van keuze. Nu heeft de site zijn eerste 3rd-party JavaScript. Dit proces kan doorgaan met het juridische team dat vraagt om een cookiebanner, marketing die vraagt om nog een analytics-script, enzovoort.
De ontwikkelaars kennen de risico's van 3rd party JavaScript, dus ze zoeken online naar de tool, doen wat onderzoek en achten het betrouwbaar.
Deze cyclus herhaalt zich totdat er een dozijn scripts of meer op de pagina staan. Allemaal legitiem, allemaal belangrijk en allemaal 3rd party. In het slechtste geval wordt een van deze domeinen gekocht, wordt er slecht verkeer geserveerd en raakt je site geïnfecteerd.
Maar dit is vergezocht – en zo gebeuren aanvallen meestal niet. De top-level scripts op je site zijn meestal niet degenen die worden getarget, hoewel dat mogelijk is (zie onze Polyfill-analyse hier). Vaak laden scripts andere scripts. Sommige scripts kunnen zelfs iframes creëren en nog meer scripts laden. Net zoals je 1st party code een aantal dependencies gebruikt, hebben 3rd party scripts ook vereisten om zichzelf functioneel te maken en hebben ze hun eigen supply chain.
Soms kunnen zelfs first-party bibliotheken die je toevoegt een script laden tijdens runtime. Ze bieden misschien een handige React-component om in je pagina te plaatsen, maar achter de schermen voegen ze een paar scripts toe om zichzelf functioneel te maken. Of het nu gaat om het laden van lokalisatie, hun eigen analytics, thema's of meer - het voegt toe aan de 3rd party supply chain van je website.
Dus je zou kunnen denken: waarom download je deze scripts niet gewoon en host je ze zelf? Voor sommige basisscripts, zoals jQuery, is dit een voor de hand liggende keuze - en een die we aanbevelen. Als je te maken hebt met een statisch script in de supply chain van je site, breng het dan naar je origin indien mogelijk.
Echter, veel scripts serveren dynamische content op basis van de aanvrager. Ze kunnen bijvoorbeeld naar je User Agent in het verzoek kijken en besluiten dat je een andere versie met extra functies nodig hebt. Of ze kunnen naar je IP kijken en besluiten om je een andere lokalisatie van het script te sturen.
Deze zijn meestal nog steeds statisch per gebruiker, maar belangrijk is dat ze niet globaal statisch zijn. Dit betekent dat door het script zelf te serveren, je slechts één variatie zou serveren, niet de complete suite van scripts die nodig zijn om je gebruikers de beste ervaring te geven.
Sommige scripts kunnen zelfs hard-coded URL's hebben naar sub-scripts die ze zullen laden. Dit betekent dat zelfs als je het root-script naar je site kopieert, het nog steeds externe scripts zal laden vanaf een externe URL.
Zelfs bibliotheken die je misschien elke dag in je app gebruikt, volgen dit patroon. Laten we naar enkele voorbeelden kijken:
Het Intercom npm-pakket laadt een hele hoop scripts tijdens runtime:
https://developers.intercom.com/installing-intercom/web/installation#single-page-app
Zelfs bij het gebruik van social media tracking tools, die onvermijdelijk zijn voor de meeste bedrijven die social-media-marketing doen, is het eerste wat de scripts die ze je geven doen het laden van nog een 3rd party script:
Of je gebruikt een React-pakket zoals @monaco-editor/react, met meer dan 712.000 wekelijkse downloads, dat een 3rd party script laadt voor veel van zijn functionaliteit: https://www.npmjs.com/package/@monaco-editor/react
Dus waar gaan we vanaf hier naartoe? Daarom bestaat cside. We proxyen elk script dat in de pagina laadt - zelfs degenen die tijdens runtime worden geladen. We herschrijven script-URL's om via onze cside Proxy te gaan, die in staat is om een script te blokkeren voordat het zelfs maar aan de client wordt geserveerd.
Onze proxy geeft een uniek uitkijkpunt: het mogelijk maken van per-url, per-domein, per-hash, per-headers beleid dat in seconden wereldwijd kan worden ingezet. Als een script probeert een child-script te laden, zal cside ervan weten en het proxyen. En je vervolgens de controle geven om te beslissen wat er gebeurt: sta dit script toe, blokkeer dit script, en de analytics die erbij horen.
Voor elk script dat onze proxy ziet, geven we het door aan onze detectie-engine. Onze detectie-engine haalt het script uit elkaar - tot op AST-niveau - om erachter te komen wat het doet. En we doen dit voor elke kleine verandering in een script, zelfs als het een karakter is. We kunnen je informeren over wat een script doet, wanneer zijn toegang tot je site verandert, en een hele reeks vertrouwensinformatie rond de bron.
We hebben beveiligingsanalisten die de klok rond werken om opkomende bedreigingen te spotten en ze op onze proxy-laag te blokkeren voordat ze ooit een van je klanten beïnvloeden. Combineer dit met de eerder genoemde automatische detectie-engine, en je hebt nu totale controle over de 3rd party supply chain van je site.
Je kunt je aanmelden voor onze gratis tier hier.
Interesseert de browser supply chain je? Zo ja, kom dan bij ons op de missie om elke gebruiker van het World Wide Web te beschermen: https://cside.com/careers
