Cybersikkerhed & teknik: En rundtur i GatewayAPIs maskinrum

Cybersikkerhed er en essentiel del af GatewayAPIs fundament. Vi har implementeret en række omfattende sikkerhedstiltag for at beskytte data og forhindre misbrug af vores platform til eksempelvis smishing, AIT og lignende ondsindede aktiviteter.

I et tidligere blogindlæg, Cybersikkerhed i messaging-branchen og vores strategiske indsats mod nye trusler, gav vi et overblik over vores overordnede tilgang til sikkerhed. 

I dette blogindlæg ønsker vi at gå i dybden med de konkrete tekniske sikkerhedsforanstaltninger, vi for nylig har implementeret.

Målet er at inspirere andre til at undersøge potentielle blinde vinkler i deres tech stacks samt at øge bevidstheden om mulige angrebsvektorer. Vi vil også dele de værktøjer og metoder, der har vist sig særligt effektive for os.

Vi starter indlægget ud med at kigge på en af de mest pålidelige metoder til at forhindre eksekvering af skadelig kode, nemlig en Content Security Policy.

Content Security Policy

En Content Security Policy (CSP) fungerer som en ekstra browserbaseret firewall. Et websted, der implementerer CSP, kan specifikt whiteliste hvilke scripts, billeder, stylesheets, webtjenester osv. webstedet må bruge. Ved at implementere en streng CSP-politik bliver det således umuligt for ikke-autoriserede kilder at køre en kode på et websted, da browseren går ind og blokerer for forsøgene.

Som det ofte sker med nye standarder, så har det taget mange år for CSP at blive fuldt moden for alle teknologier og frameworks samt at blive bredt understøttet. Det blev derfor ikke overvejet til GatewayAPIs frontend tilbage i 2015. CSP niveau 3 blev introduceret i 2023 med bedre understøttelse af vores tech stack og framework. Det var derfor oplagt for os at implementere denne sikkerhedsforanstaltning.

Som nævnt er CSP den bedste garanti mod udførelse af ondsindet kode efter vores mening. Vi vil derfor også hævde, at alle webapplikationer bør implementere strenge CSP-regler for at gardere sig.

Sådan har vi implementeret det i GatewayAPI

Vi har implementeret CSP v3 med strenge regler, hvilket vil sige, at der ikke længere er unsafe-inline eller unsafe-eval for Javascript.

Det var en stor opgave at implementere CSP, da vi brugte forskellige frontend-biblioteker og vores egne tilgange, som i bund og grund ikke var designet med CSP i tankerne. Dvs. knapper, der blev gengivet fra dynamisk gengivne skabeloner, der indeholdt onclick=”-handlere eller Javascript-biblioteker, der manipulerede elementernes stilattributter direkte i stedet for gennem de rigtige Javascript-API’er.

Et andet problem var at understøtte tredjepartsværktøjer, der udfører dynamisk kode. Især Google Tag Manager, som har tilladelse til at injecte dynamisk kode, skulle håndteres. For at gøre dette implementerede vi nonce-generering i vores webserver, Nginx, som derefter blev sendt videre til Google Tag Manager.

Det er blevet meget nemmere at understøtte CSP med moderne biblioteker, der er bygget med det for øje, men da vores frontend-kode har ca. ni år på bagen, krævede det en vis indsats at opgradere den til streng CSP-overensstemmelse, herunder patching af ældre tredjepartsbiblioteker. Selvom det var en stor mundfuld, var det virkelig indsatsen værd, da det forbedrede sikkerheden drastisk.

De sikkerhedsmæssige risici ved Google Tag Manager

Google Tag Manager (GTM) er et kraftfuldt værktøj, der gør det nemt at administrere tags og scripts på din hjemmeside. Men sammen med de mange fordele følger betydelige sikkerhedsmæssige risici, som ofte bliver overset.

Et af de største problemer er, at GTM giver alle med tilstrækkelig adgang til kontoen mulighed for at indsætte vilkårlig JavaScript-kode på dit websted. Dette inkluderer også JavaScript fra et bredt udvalg af betroede tredjeparter, som ofte kan vælges fra GTMs bibliotek. Selvom Google har implementeret nogle sikkerhedsforanstaltninger, er der stadig potentielle svagheder, især når GTM bruges som et marketingværktøj.

Ofte får tredjeparter eller marketingmedarbejdere adgang til GTM med udvidede rettigheder for at lette deres arbejde. Men hvis en af disse personer eller organisationer bliver kompromitteret – eksempelvis gennem et phishing-angreb – kan GTM potentielt fungere som en bagdør for at indsætte ondsindet kode på dit websted.

Som standard giver GTM brugere med fuld adgang mulighed for at udgive enhver form for JavaScript-kode uden forsinkelse eller godkendelsesproces. Dette kan føre til alvorlige sikkerhedsproblemer, hvis adgangskontrollen ikke er stram, eller hvis der mangler løbende overvågning af de scripts, der implementeres gennem platformen

Sådan har vi implementeret det i GatewayAPI

Vi har begrænset, hvem der har adgang til at udgive ændringer i produktionen, til et meget snævert sæt af betroede medarbejdere. Vi har derudover oprettet notifikationer, som bliver sendt til en delt kanal i vores Slack, når nogen udgiver ændringer i Tag Manager.

Obfuskeret Javascript

Obfuskering og minificering ændrer ikke koden eller dens funktionalitet, men gør den vanskeligere at læse for tredjeparter. Det er også muligt at fjerne obfuskering, så man kan aldrig stole på obfuskering som sikkerhed alene. Men at gøre livet sværere for hackere er bestemt en god ide, da det kan afskrække nogle fra overhovedet at forsøge at hacke. Lidt ligesom at sikre, at du har det mindst attraktive hus på gaden, når det kommer til indbrudstyve.

Sådan har vi implementeret det i GatewayAPI

Vores Javascript-kode leveres nu kun i minificeret og obfuskeret form. På build-tidspunktet kombineres al Javascript-kode til en enkelt Javascript-fil, som derefter obfuskeres og minificeres. Til Javascript blev UglifyJS 3 brugt, og til CSS blev Minify brugt, som blandt andet bruger CleanCSS 5.

Sikkerhedsscanninger og penetrationstest

På trods af udførlig kodegennemgang, kan sikkerhedsbrister slippe igennem – selv for erfarne udviklere. På samme måde kan der opstå sårbarheder, som ingen var klar over på det daværende tidspunkt. Der kan også være sårbarheder i tredjepartsbiblioteker, som normalt ikke ville blive opdaget i en kodegennemgang.

For at få en bedre forståelse af, hvad der kunne forbedres, undersøgte vi forskellige automatiserede scannings- og penetrationstestværktøjer. Vi besluttede at bruge HostedScan til løbende at spore vores fremskridt med at styrke sikkerheden.

HostedScan foretog daglige scanninger og rapporterede resultaterne, som vi derefter brugte til at evaluere vores næste skridt. Med størrelsen på GatewayAPI.com tog det næsten 12 timer at gennemføre, hvilket også var forventet, da værktøjet er meget grundigt.

Ligesom ved penetrationstesten, så grupperer platformen de problemer, den finder, efter alvorlighedsgrad. Det hjalp os også med at fokusere på de mest kritiske problemer først.

Vi fk derudover udført en ekstern penetrationstest, som du kan læse mere om her.

Konklusion

Det er afgørende for alle organisationer løbende at vurdere og forbedre deres sikkerhedsforanstaltninger for at beskytte sig mod nye trusler. Den sikkerhedsscanning og penetrationstest, der blev udført på GatewayAPI, afslørede nogle svage punkter, som straks blev adresseret.

Vi bestræber os altid på at være gennemsigtige, og derfor vil vi gerne dele vores resultater i håb om, at dette blogindlæg kan inspirere andre virksomheder til også at give deres systemer et serviceeftersyn. At holde sig ajour med best practice og de nyeste sikkerhedsfunktioner er afgørende for at være et skridt foran hackerne.