Onze vergelijkingspagina toont een uitstekend overzicht van de verschillende benaderingen om client-side beveiliging te bereiken en te voldoen aan de PCI DSS-vereisten (6.4.3 en 11.6.1).
Onze oplossing (de hybride proxy) overtreft andere benaderingen in verschillende categorieën. Laten we het vergelijken met de crawler die veel concurrenten in deze ruimte gebruiken. De voordelen en de vele tekortkomingen die bij deze oplossing komen kijken.
In dit artikel richten we ons op PCI DSS 4.0.1 sectie 6.4.3 en 11.6.1. Bezoek onze vergelijkingspagina voor de volledige voordelen en nadelen in een complete beveiligingscontext.
"Een methode is geïmplementeerd om te bevestigen dat elk script geautoriseerd is"
6.4.3 Alle betalingspaginascripts die worden geladen en uitgevoerd in de browser van de consument worden als volgt beheerd:
Een methode is geïmplementeerd om te bevestigen dat elk script geautoriseerd is.
Een methode is geïmplementeerd om de integriteit van elk script te waarborgen.
Een inventaris van alle scripts wordt bijgehouden met schriftelijke zakelijke of technische rechtvaardiging waarom elk noodzakelijk is.
Vereiste PCI 6.4.3 vereist een mechanisme om te voorkomen dat ongeautoriseerde scripts worden geladen.
Om verwarring te voorkomen, stelt de PCI-specificatie ook:
Ongeautoriseerde code kan niet worden uitgevoerd op de betalingspagina zoals deze wordt weergegeven in de browser van de consument.
Voor veel GRC's is het een uitdaging om technische inspanningen toe te wijzen aan compliance-vereisten. Begrijpen hoe client-side beveiligings-PCI-vereisten zich vertalen naar praktische implementatie is vaak waar teams vastlopen. Sommige oplossingen kunnen u doen geloven dat u aan de vereisten kunt voldoen zonder code te implementeren of aanpassingen te maken. Dat is echter niet correct.
Aan deze vereiste kan op verschillende manieren worden voldaan. Een handelaar kan een Content Security Policy implementeren. CSP staat er echter om bekend moeilijk te beheren en te onderhouden, maar het is een geldige oplossing om aan deze vereiste te voldoen.
Een handelaar kan ervoor kiezen om een client-side agent te gebruiken die sommige JS-gedragingen blokkeert. Dat is echter geen wondermiddel. Er zijn verschillende voorbeelden van client-side aanvallen die in wezen de beveiligingsagent stopten met functioneren en de functionaliteit, inclusief blokkeermogelijkheid, volledig of gedeeltelijk uitschakelden. Test daarom altijd de oplossing die u aanschaft met een zelfgeschreven client-side script. Helaas zullen de meeste JavaScript-engineers van gemiddeld niveau dit geen grote uitdaging vinden.
Of u kunt een proxyservice zoals cside gebruiken om te voorkomen dat een kwaadaardig script überhaupt wordt geserveerd.
Deze specifieke regel van de PCI DSS-vereisten wordt gemakkelijk over het hoofd gezien, maar verwijst terug naar de aard van de vereiste: implementeer beveiligingsstandaarden voor betaalkaarten om te voorkomen dat creditcards bij invoer worden gestolen.
Crawlers 'zien' de werkelijke payload niet en zullen een serieuze aanval niet vastleggen
Crawlers werken door uw site te bezoeken en te indexeren welke scripts worden geladen. Belangrijk detail: ze gedragen zich als een gebruiker, maar zijn duidelijk geen echte menselijke gebruiker. Er zijn een aantal eenvoudige indicatoren, waarvan het afkomstig zijn van het IP-adres van een cloudprovider er één is. Dit is een fundamenteel ontwerpfout, omdat JavaScript-levering dynamisch van aard is. Het is gebouwd om verschillende versies van scripts te serveren op basis van tijd, user-agent, locatie, IP-bereiken...
Kwaadwillenden maken natuurlijk gebruik van die dynamiek om detectie te vermijden. Een crawler zal de werkelijke aanval waarschijnlijk niet uit de eerste hand opmerken. Daarom moet de threat intelligence uit andere bronnen komen. Dit is waar de meeste oplossingen threat feed intel kopen van providers. Deze providers zijn echter vaak laat ter plaatse. Toen de Polyfill-aanval plaatsvond, duurde het meer dan 30 uur voordat een threat-leverancier het markeerde, ook al had het brede persaandacht. Het domein werd pas gemarkeerd toen Namecheap het domein al had verwijderd. Threat feed-providers zijn ook niet specifiek op zoek naar client-side aanvallen, soms vangen ze ze op, maar evenzo weten kwaadwillenden hun onderzoekers te vermijden. Het meeste van hun client-side aanvalsinformatie komt van sociale media.
We hebben vastgesteld dat een crawler niet kan garanderen dat de payload die het ophaalt dezelfde is die de gebruiker heeft ontvangen, maar laten we even veronderstellen dat dit wel zo is. De meeste kwaadaardige scripts worden geladen als subaanvragen op basis van gebruikerstriggers: gebruiker klikt, scrolt, logt in of voegt iets toe aan een winkelwagen.
Als een kwaadaardig script zou worden geïnjecteerd vanwege een gebruikersinteractie, zal de crawler het kwaadaardige script niet zien tenzij het diezelfde gebruikersinteractie maakt. Dit is vrijwel onmogelijk om te doen, aangezien elke pagina eindeloze interactiemogelijkheden kan hebben. Voorbeeld: maak alleen de fetch naar het kwaadaardige script als een reeks knoppen 5 keer wordt ingedrukt, een volledig venster naar beneden wordt gescrold, de browser geen dev-tools open heeft... "Synthetisch crawlen" beweert dit aan te pakken, maar dat kan het echt niet om voor de hand liggende technische redenen.
Als u een statische beveiligingsanalysebenadering toepast op een dynamisch probleem, pakt u het beveiligingsprobleem niet aan.
Zijn alle crawlers dus nutteloos?
Nee. Het fundamentele concept van een crawler is gebrekkig, maar als een leverancier niet verwacht de kwaadaardige payload uit de eerste hand via de crawler te zien, maar in staat is om het bovenliggende script te markeren via andere actieve detectiemethoden buiten de crawler, kan het nog steeds beveiligingsproblemen op een voldoende hoog niveau aanpakken (voor sommigen). Bijvoorbeeld: de cside-crawler gebruikt de kwaadaardige script-intel die is ontvangen via de geproxyde websites van andere cside-klanten. Als gevolg hiervan worden kwaadaardige payloads gedetecteerd op andere sites en worden de bovenliggende objecten die die kwaadaardige scripts hebben geïnjecteerd gemarkeerd. Als de crawler de schone payload heeft ontvangen maar weet dat dat script is gecompromitteerd via andere sites, zal dat leiden tot een waarschuwing.
"Wacht, maar ik zie al deze interessante gegevens in hun dashboard?"
Dit is zeker een toegevoegde waarde. Crawlers kunnen u inzicht geven in enkele van de gedragingen van enkele van de scripts op uw site die het dashboard vullen en interessante inzichten bieden. Maar elk slecht script zal weten hoe het niet in die dashboards moet verschijnen. Over het algemeen hebben mensen een vooroordeel voor glimmende objecten. Een glimmend dashboard met veel interessante informatie erop, leidt mensen ertoe te denken dat dezelfde informatie beschikbaar zal zijn op een slechte dag. Dat is echter niet het geval.
Waarom überhaupt een crawler overwegen?
Beveiliging draait helemaal om gelaagdheid. Het toevoegen van meer oplossingen om dezelfde problemen te monitoren is meestal een goede zaak.
Ze zijn relatief lichtgewicht om te implementeren (meestal), en geven u een basiskaart van welke scripts op een bepaald moment op uw site aanwezig zijn. Voor een compliance-team dat periodieke controles of audits uitvoert die niet vatbaar zijn voor PCI DSS, is dat nuttig.
Ze bieden ook zichtbaarheid in statische wijzigingen. Stel dat er plotseling een nieuwe script-URL verschijnt of een bestaande verdwijnt. In dat opzicht is het een stap hoger dan CSP die geen enkele payload-zichtbaarheid biedt. Lees hier over de beperkingen van CSP's. Een crawler kan u helpen een inventaris van scripts bij te houden (onderdeel van 6.4.3) en beveiligingsheaders te bekijken wanneer het crawlt (PCI 11.6.1), maar het kan niet voorkomen dat ongeautoriseerde scripts worden geladen. U zou op zijn minst nog steeds CSP of een agent moeten toevoegen. Koop dus alleen een crawler als deze u ook een CSP-eindpunt of een agent geeft.
Een crawler alleen kan u geen PCI DSS-compliance bieden.
