Mathias Gam-Pedersen
Sikkerhedskonsulent
Mathias er ansvarlig for ReTest Security web-application security services. Med disse services er han ansvarlig for rådgivningen af virksomheder, der udvikler software (DevSecOps) og black- samt whitebox pentest af applikationer.
#1 Benyt en Web Application Firewall
En basal Web Application Firewall (WAF) er en billig sikkerhedsløsning, som vi vil anbefale alle, der har en applikation, som er tilgængelig på internettet.
Dette er software, som analyserer alt trafik, der køres igennem det, med det formål at blokere ondsindet trafik. Nogle WAFer kan tilmed blokere bots og de fleste typer af DDoS forsøg.
Ved at have en WAF beskytter I jeres applikation mod mange af de vidt udbredte, automatiserede angreb. Selv for en angriber med høje tekniske færdigheder vil det blive mere besværligt at finde sårbarheder i din webapplikation, for en WAF vil betyde, at angriberen skal bruge mere tid på at omgå beskyttelsen. Samtidig vil de metoder angriberen bliver nødt til at benytte, med større sandsynlighed føre til, at I får kendskab til angrebet i jeres logs i realtid.
Der er mange forskellige former for WAF’er. Hvilken der passer bedst for jer afhænger af jeres applikation, hvor den bliver placeret, jeres budget, og jeres behov for support med løsningen.
#2 Udnyt Browser-sikkerheden; Benyt Sikkerheds-Headers
Moderne browsere har flere indbyggede sikkerhedsmekanismer, som I kan drage fordel af, når I bygger applikationer. De bliver slået til ved at sende data i nogle specielle headers. I kan blandt andet blokere clickjacking-angreb (hvor angriberen indlejres jeres side i en sin egen) ved at sende X-Frame-Options headeren med værdien deny. I kan også gøre så browseren kun må tilgå de krypterede HTTPS-sider på domænet, eller definerer, at der ikke må loades ressourcer fra tredjepartskilder som er uden for domænets politik. Det er generelt en rigtig god ide at konfigurere jeres applikation til at udnytte browsernes sikkerhedsmekanismer, ved at sende de forskellige sikkerheds-headers.
Yderligere, så skal I også være opmærksom på at headers kan lække information omkring en applikations underliggende teknologier. Mange frameworks og teknologier sender, som standard, en header med disse info samt deres fulde versionsnummer. Dette er brugbar viden for enhver, der har interesse i at angribe applikationen, specielt I ikke lige har fået opdateret i tide, og det lækkes, at applikationen benytter gammel og sårbare versioner.
OWASP har gode guides og ressourcer, der dækker de forskellige sikkerheds-headers:
#3 Reducer Jeres Angrebsflade
Jo mere der er eksponeret mod internettet, jo højere er chancen for, at der er mindst en kritisk sårbarhed, som er mulig at finde. Hvis en angriber har mulighed for at interagere direkte med et system, så får angriberen lettere en stor forståelse for, hvordan applikationen virker.
Dette gælder specielt, hvis det er muligt, at få fejlbeskeder tilbage fra back-end API’er. Informationen kan gøre processen med at finde sårbarheder mere effektiv.
Derfor anbefaler vi at reducere mængden af services, som I har eksponeret til internettet, så meget som muligt, eksempelvis ved at blokere adgang fra alt undtagen få IP-adresser. I kan også vælge at reducere muligheden for at interagere direkte med jeres back-end ved, for eksempel, at benytte en proxy eller benytte serverless-funktioner til at proxy og rense både input og output.
Mere information omkring angrebsflade i en IT-sikkerhedskontekst:
#4 Sørg for at alt Input Bliver Valideret
De fleste kritiske sårbarheder i webapplikationer er injection attacks. De opstår når udviklere lader bruger-definerbart data blive brugt direkte i ”farlige” funktioner. Dette kan føre til remote code execution (RCE), hvis bruger-definerbart data bliver benyttet i et systemkald uden at være renset og/eller blive valideret.
Det kan også føre til at bruger-defineret HTML kan blive tilføjet til front-end og blive kørt i brugernes browser (cross site scripting (XSS)), samt at angriberen kan tilføje mere til en SQL-forespørgsel, og få systemet til, at læse data fra en fil, som ellers ikke burde kunne tilgås gennem applikationen.
Vi anbefaler at alt bruger-definerbart input bliver valideret før det får lov til at blive brugt i applikationen. Hvis et input ikke er korrekt, så anbefaler vi at afvise forespørgslen, medmindre det er muligt at rense input på en måde, der ikke påvirker normal funktionalitet.
Unit tests for diverse scenarier med valid-, forkert-, og sårbart data er en god ide at foretage, for at sikre, at input valideringen fungerer som forventet.
Mere information omkring input validering kan læses her:
#5 Gør Kommunikation Mellem Bruger og Applikationen Fortrolig
Det er vigtigt alt information, der bliver sendt over internettet, er fortroligt. Dette opnås ved at benytte kryptografi, så sensitiv information og session-nøgler ikke bliver tilgængelig for tredjeparter. Derfor anbefaler vi at alle applikationer I har eksponeret til internettet, kun er tilgængelig over HTTPS.
I nogle af krypteringsmetoderne og protokollerne supporteret af HTTPS er der kendte sårbarheder, og der sker løbende en udvikling, hvor nogle af disse generelt ikke betragtet som sikre længere.
Derfor er det en god ide at få en løbende proces for at fjerne support for sårbare protokoller og krypteringsmetoder. Dette er såfremt alle enheder, der skal kunne benytte applikationen, har support for at bruge nyere sikre protokoller og metoder.
Er godt redskab til at hjælpe med konfigurering af HTTPS, og en guide til diverse krav til HTTPS findes her:
#6 Design jeres Rettighedssystem Efter ”Princippet om Færrest Privilegier”
Når I designer hvilke rettigheder de forskellige brugergrupper skal have, så vil vi anbefale jer at følge ”princippet om færrest privilegier”. I praksis betyder det at enhver bruger kun skal have adgang til de funktioner og data, som brugeren har behov for. Det kræver lidt ekstra tanker i design-fasen, men forbedre sikkerheden betydeligt.
Såfremt en bruger har rettighed til mere end nødvendigt, øges angrebsfladen, når angriberen opnår pågældende brugerstadie. Ved at tænkte dette princip ind, kan I mindske mulighederne for at nogen kan misbruge funktionalitet til at tilegne sig adgang til sensitive data, tilgå administrativ funktionalitet, eller finde og udnytte sårbarheder i funktionaliteten. Hvis adgangen minimeres, så er risikoen for at almindelige brugere har adgang til sårbar funktionalitet reduceret.
Det er også en god ide at overveje hvilken bruger der kører applikationen på serveren. Det er nemlig ofte denne bruger, som angriberen får adgang til, hvis han/hun finder og udnytter en remote code execution-sårbarhed. Hvis brugeren har adgang til hele systemet, så bliver konsekvenserne store hvis en angriber får adgang til brugeren.
Yderligere information kan findes her:
#7 Opsæt jeres cookies sikkert
De fleste applikationer opbevarer session-information i cookies. Hvis disse kompromitteres, kan det give en tredjepart adgang til applikationen på niveau med brugeren, session-informationen tilhører. Det er muligt at sætte parametre på cookies, der reducerer risikoen for en kompromittering af cookies. De vigtigste er Secure og HttpOnly. De gør at cookies kun må blive sendt krypteret over HTTPS og at det ikke er muligt, at tilgå dem via JavaScript. Dermed bliver det ikke muligt at tilgå cookies ved et cross site scripting (XSS)-angreb.
Mere information omkring de to parametre kan findes her:
#8 Følg en checkliste for sikker softwareudvikling
Hverdagen er travl i enhver udviklingsafdeling. Det kan være en rigtig god ide at følge en etableret checkliste/kontrolliste for sikker softwareudvikling, så I sikrer, at I afdækker de vigtigste områder af applikationssikkerhed.
Såfremt I ikke har krav om at skulle følge en specifik liste, så vil vi anbefale jer at følge OWASP Application Security Verification Standard (ASVS). Dette er en open-source-industristandard for at bygge sikre webapplikationer, der er bygget baseret på erfaringer fra mange forskellige organisationer.
Da det ikke er muligt at få en officiel certificering i at man følger ASVS, kan det være nemmere at få listen til at passe ind i jeres organisation – for I plukker bare de råd, som I synes er de vigtigste for jeres applikation.
Det kan blive en stor investering hvis at en applikation skal følger alle krav/kontroller i ASVS. Derfor anbefaler vi at begynde med at inkludere den, når I udvikler ny funktionalitet. Listen er struktureret efter emner, så det er muligt for udviklerne hurtigt at få et overblik over hvilke sikkerhedsrelevante overvejelser, der kan gøres ang. ny funktionalitet specifik til det område af applikationen, som I er ved at udbygge.
Når der er tid til at fokusere udelukkende på at sikre applikationen, så fungerer rammeværket som en god checkliste og til at prioritere hvilke sikkerhedsændringer skal laves først.
OWASP har inddelt kravene i tre niveauer: Den første er, hvad de definere som minimumskrav for alle applikationer, som sikres mod ”low hanging fruit” sårbarheder. Det andet niveau er, hvad de fleste applikationer skal forsøge at opnå over tid. Tredje niveau er for safety-critical applikationer, samt hvis applikationen behandler meget kritisk information.
Link til OWASP ASVS:
#9 Skan jeres kode for sårbarheder løbende
Der eksisterer mange redskaber, som kan benyttes til at skanne koden igennem for sårbarheder og generelle bad practice kode, der kan lede til fejl og sårbarheder. Såfremt I ikke allerede benytter sådan redskaber selv eller får det som en service, vil vi anbefale jer at inkludere det som en del af jeres CI/CD-pipeline. På den måde reducerer I antallet af potentielle sårbarheder, der får lov til at komme i produktionsmiljøet. Såfremt I ikke har en CI/CD-pipeline opsat, så vil vi anbefale at I regelmæssigt manuelt skanner koden med samme værktøjer for at løse eventuelle sårbarheder.
Flere af værktøjerne fremgår af denne liste:
#10 Hold jeres systemer opdaterede
Konsekvensen ved at køre med gammelt software kan i værste tilfælde være, at en angriber får total kontrol over applikationen.,
Vi ser mange webapplikationer, der benytter teknologier og frameworks, kørende på forældede versioner. Dette er til trods for at opdateringer/patches er tilgængelige.
Det anbefales, at I holder systemerne opdateret så hyppigt som jeres forretningsprocesser tillader det.
Såfremt muligt, vil det være idealt at holde systemet opdateret automatisk. Her kan et solidt testningsstadie i jeres CI/CD-pipeline benyttes til at validere, at opdateringerne ikke har ødelagt funktionalitet i jeres applikation.
Hvis dette ikke er muligt, så vil vi anbefale at regelmæssigt have en ansat til manuelt at opdatere applikationen, og derpå validere at den normale funktionalitet stadig fungerer som forventet. Den sidste løsning giver typisk bedst cost/benefit for mindre applikationer/organisationer.
Seneste kommentarer