Et kig på checkliste kunne have forhindret rejsekort-brøler

Det er en klassisk faldgrube at lade alle brugere se andre brugeres data, blot de kan gætte URL'en. Kun sikkert design fra starten kan sikre mod det.

En it-brøler hos Rejsekort, som har medført at personlige personlige oplysninger om rejsekortbrugere I halvanden måned været tilgængelige grundet en fejl, kunne have været undgået med en barriere for brugernes adgang til data.

Miseren hos Rejsekortet, som Version2 kunne offentliggøre i går, er velkendt - faktisk har det været kendt siden de første webapplikationer så dagens lys: Hvis man ændrede URL'en kunne man snyde applikationen til at ændre priser i systemet eller få adgang til en anden brugers data.

Læs også: It-brøler hos Rejsekort: Brugere kunne se hinandens personlige data

Men selvom problemet - og løsningen - har været kendt i årevis, så dukker det stadig op i mere eller mindre alvorlige tilfælde, hvor der eksempelvis bruges fortløbende fakturanumre, som er lette at gætte, og ingen adgangskontrol, når først brugeren er inde i systemet.

»Man burde aldrig kunne få adgang til en anden kundes faktura ved at ændre på URL'en. Det har i mange år været blandt top 10-anbefalingerne til websikkerhed, at man aldrig skal stole på input fra klienten, men skal validere, at brugersessionen har adgang til den pågældende faktura. Derfor er det i min optik best practice at lave sådan et tjek,« siger teknisk direktør Jacob Herbst fra sikkerhedsfirmaet Dubex til Version2.

Han henviser til Top 10-listen fra organisationen OWASP, der er en checkliste for udviklere over 10 sikkerhedsfejl, der går igen i applikationer. Også selvom de er velkendte for de fleste udviklere.

»Alle udviklere har på et tidspunkt lavet en applikation med fortløbende ID'er. Isoleret set er det ikke et problem, men kræver opmærksomhed ved validering af forespørgsler. Nu har udviklingen bevæget sig mod tokens, der er koblet til login, så det er bundet til den person, der er logget ind. Dermed er risikoen for at lave denne type fejl hvor der kan manipuleres med forespørgslerne væsentlig reduceret« siger systemudvikler Frederik Raabye fra Dubex.

Fakturaer skal som regel have fortløbende numre, men hvis de bruges i URL'en til at finde frem til hver enkelt faktura, så er det vigtigt, at man ikke blot benytter kendskabet til et fakturanummer som eneste adgangskontrol, men også ser på, om den pågældende bruger skal have adgang til en bestemt faktura.

»Adgangskontrol skal tænkes ind i designet fra starten, så der er styr på autentificering, så en bruger kun har adgang til de data, deres roller tillader,« siger Frederik Raabye.

Unik session for brugerne er løsningen

Den mest almindelige måde at løse problemet i webapplikationer er ved at etablere en session for hver bruger, som så får et unikt, stort tilfældigt tal, som det ikke er trivielt at gætte i modsætning til fortløbende numre.

»Først autentificerer man brugeren og etablerer en session. Dernæst sørger man for, at den session kun har adgang til de data, brugeren må få adgang til. Det kræver nogle check i backenden, men hvis man bare giver brugeren et link, så overlader man adgangskontrollen til klienten,« forklarer sikkerhedsekspert Peter Flintholm fra udviklingshuset Trifork til Version2.

Backenden skal altså checke og eventuelt afvise at vise data, hvis brugersessionen ikke stemmer overens med den nødvendige autorisation. Altså nægte at vise eksempelvis en faktura, hvis brugeren ikke har tilladelse til at se den. Det kræver et par ekstra kodelinjer, så længe det er tænkt ind i designet.

Princippet er nogenlunde det samme, når man skal give en bruger adgang til at se bestemte oplysninger via et link. Det kan eksempelvis være en reservation eller en kvittering fra en webshop, hvor brugeren ikke er logget ind, men modtager et link i en mail.

»Man kan sende en tilsvarende sikker token som en del af URL'en. Så får man sådan set samme sikkerhed, som med en autentificeret session, men det er kun så sikkert som den måde, hvorpå man distribuerer linket, da alle med linket kan se data,« forklarer Peter Flintholm.

Ligesom det unikke tal i browsersessionen, så vil sådan en token i URL'en være et tal med stor entropi på eksempelvis 128 bit, så det er nærmest umuligt at gætte, og det er god praksis samtidig at give linket begrænset levetid, så det ikke er aktivt længere, end det er nødvendigt.

Enkle guidelines glemmes ofte

Selvom disse enkle sikkerhedsforanstaltninger er velkendte og god praksis, så bliver de alligevel ofte glemt. Det kan blandt andet ske, hvis man hovedsageligt fokuserer på funktionalitet og brugeroplevelse.

»Det er ikke alle, der tænker på sikkerhed, men i stedet tænker, at når man ikke direkte kan klikke sig vej til data, man ikke skal have adgang til, så er det ikke et problem. Men der bør være nogen, som tænker sikkerhed i sådan en løsning. Og selv for garvede sikkerhedsfolk er det en god øvelse lige at gå igennem de relevante Top 10-lister og dokumenter fra OWASP,« siger Peter Flintholm.

Tips og korrekturforslag til denne historie sendes til tip@version2.dk
Følg forløbet
Kommentarer (3)
sortSortér kommentarer
  • Ældste først
  • Nyeste først
  • Bedste først
Peter Hansen

Men selvom problemet - og løsningen - har været kendt i årevis, så dukker det stadig op i mere eller mindre alvorlige tilfælde, hvor der eksempelvis bruges fortløbende fakturanumre, som er lette at gætte, og ingen adgangskontrol, når først brugeren er inde i systemet.

Der uddannes nye datamatikere hvert år ;-)

(krøller sammen og gør sig klar til at blive downvoted)

Andy Fischer

Det er forholdsmæssigt trivielt at kode tilstrækkelig sikkerhed i webapplikationer, men alligevel sker der ofte fejl som den nuværende. Det vil ikke ændre sig med anvendelse af tokens, selv om de i teorien er sikrere. Man kan sagtens implementere tokens uden tilstrækkelig bagvedliggende sikkerhed. Man kan også disable sikkerheden i forbindelse med test af ny kode (det gør ting så dejligt nemt), og så glemme at enable den bagefter, hvilket sandsynligvis er det der er sket for Rejsekortet.

Andy Fischer

Der uddannes nye datamatikere hvert år ;-)
(krøller sammen og gør sig klar til at blive downvoted)


Jeg kan huske da jeg selv lærte at programmere på de højere læreanstalter. Der blev vi sat til at bevise vores kode. Dødsygt, men gav en god fornemmelse for, hvad det var vi lavede, og ikke mindst noget at gøre mens vi ventede på computer-tid ;-)

Jeg frygter, at man ikke gør det i dag, og, at de moderne IDE'er ikke giver de studerende tid til at tænke over deres kode. Hvis jeg i dag skal lave noget kritisk kode, bliver det skrevet på et stykke papir, og først udsat for compileren når jeg er sikker på, at det virker efter hensigten. Det kan virke håbløst gammeldags, men giver rigtig god kode.

Log ind eller Opret konto for at kommentere
Pressemeddelelser

Welcome to the Cloud Integration Enablement Day (Bring your own laptop)

On this track, we will give you the chance to become a "Cloud First" data integration specialist.
15. nov 2017

Silicom i Søborg har fået stærk vind i sejlene…

Silicom Denmark arbejder med cutting-edge teknologier og er helt fremme hvad angår FPGA teknologien, som har eksisteret i over 20 år.
22. sep 2017

Conference: How AI and Machine Learning can accelerate your business growth

Can Artificial Intelligence (AI) and Machine Learning bring actual value to your business? Will it supercharge growth? How do other businesses leverage AI and Machine Learning?
13. sep 2017
Jobfinder Logo
Job fra Jobfinder