De mest udbredte sårbarheder og de vaner, der lukker dem
Enhver webapplikation, der er åben mod internettet, bliver afprøvet af automatiske værktøjer og nysgerrige mennesker hele døgnet. Sikkerhed er derfor ikke noget, man tænker på, når siden er færdig — det er en måde at skrive kode på fra første linje. En god rettesnor er OWASP (Open Worldwide Application Security Project), en non-profit, der udgiver en bredt anerkendt liste, OWASP Top 10, over de mest kritiske sikkerhedsrisici i webapplikationer. Den er ikke en lov, men det fælles udgangspunkt, branchen taler ud fra.
Den røde tråd gennem næsten alle web-sårbarheder er tillid til data, der kommer udefra. Alt, hvad der kommer fra browseren — formularfelter, adresselinjen, parametre, cookies, headers — kan være manipuleret. En angriber bruger ikke nødvendigvis din pæne brugerflade; de sender data direkte til serveren. Derfor skal alt input valideres og renses på serveren, før det bruges, gemmes eller vises igen. Validering i frontend er en hjælp til den ærlige bruger, ikke et forsvar mod den uærlige.
Den mest udbredte alvorlige fejl er, at adgangskontrollen kan omgås: en bruger kan se eller ændre noget, vedkommende ikke burde. Et klassisk eksempel er, at man kan skifte et id i adresselinjen og se en andens data, fordi serveren ikke tjekker, om den indloggede bruger faktisk ejer det. Reglen er, at hver eneste handling skal kontrollere på serveren, at den aktuelle bruger har lov — det er ikke nok at skjule en knap i brugerfladen. Gå ud fra, at alt, der ikke udtrykkeligt er tjekket, er åbent.
Injection opstår, når data fra brugeren bliver tolket som en del af en kommando i stedet for som ren data. Det klassiske tilfælde er en database-forespørgsel, hvor brugerens tekst sættes direkte ind i forespørgslen, så en angriber kan ændre, hvad forespørgslen gør. Forsvaret er at adskille kode fra data: brug parametriserede forespørgsler (også kaldet prepared statements), hvor brugerens input altid behandles som en værdi, aldrig som kommando. Den samme tankegang gælder alle steder, hvor input ender i en kommando — det er princippet, ikke det enkelte system, du skal forstå.
XSS opstår, når en angribers tekst bliver vist på siden og kørt som kode i en anden brugers browser — fx via en kommentar, der indeholder et script. Resultatet kan være, at angriberen stjæler sessioner eller handler i offerets navn. Forsvaret er at behandle alt brugerindhold som tekst, når det vises: undslip det korrekt, så tegn vises som tegn og ikke udføres. Brug de mekanismer, dit framework tilbyder til sikker udskrivning, frem for at sætte rå tekst direkte ind på siden.
Listen samler de tilbagevendende risici i kategorier. Du behøver ikke kunne dem udenad, men de er et godt tjekgrundlag, når du gennemgår en applikation.
| Category | Kort sagt |
|---|---|
| Brudt adgangskontrol | Brugere kan nå mere, end de må |
| Kryptografiske svigt | Følsomme data er ikke beskyttet godt nok i hvile og under transport |
| Injection | Input tolkes som kommando — fx i en database-forespørgsel |
| Usikkert design | Sikkerheden er ikke tænkt ind, før der blev bygget |
| Fejlkonfiguration | Standardindstillinger, åbne tjenester, for detaljerede fejlbeskeder |
| Sårbare komponenter | Forældede biblioteker med kendte huller |
| Fejl i identitet og login | Svag håndtering af adgangskoder, sessioner og login |
| Brud på integritet | Kode eller data hentes og bruges uden at verificere kilden |
| Mangelfuld logning | Angreb opdages ikke, fordi intet logges eller overvåges |
| Forfalskede serverforespørgsler | Serveren narres til at hente noget på angriberens vegne |
Gem aldrig adgangskoder i klartekst. De skal hashes med en algoritme, der er bygget til formålet og er bevidst langsom, og med salt, så ens kodeord ikke giver ens hash. Sessioner skal beskyttes, så de ikke kan stjæles eller gættes, og en session skal kunne udløbe og afsluttes ved log ud. Adgangsnøgler, API-nøgler og andre hemmeligheder hører aldrig hjemme i frontend-koden eller i versionsstyringen — de hører til på serveren, uden for det, brugeren kan se.
Ingen enkelt vane gør en applikation sikker. Det er summen: valider på serveren, kontrollér adgang på hver handling, adskil kode fra data, vis brugerindhold som tekst, hold afhængigheder opdaterede, beskyt login og hemmeligheder, og log nok til at kunne opdage et angreb. Gør du dem til rygmarvsreaktioner, lukker du de fleste af de huller, OWASP's liste advarer om — længe før en angriber finder dem.
“Sikre webapplikationer bygges ikke ved at tilføje sikkerhed til sidst, men ved at mistro alt input fra første linje kode.”
— Almindelig læreregel i web-sikkerhed