Pudsig rejsekort-fejl rettet: Forskel på små og store bogstaver gav adgang til andre brugerkonti

Illustration: leowolfert/Bigstock
Selskabet bag rejsekortet har rettet en fejl i systemets back end-del, der i særlige tilfælde kunne misbruges til at komme ind på andre brugeres konto via online-selvbetjeningen.

En kvinde ved navn Tina Andersen fra Aalborg oplevede, hvordan hun fik adgang til en anden brugers konto via reejsekortets selvbetjening. Den anden bruger viste sig også at hedde Tina Andersen, hvilket startede spekulationer om, hvorvidt folk med samme navn kunne logge ind på hinandens konti.

Det beskrev DR Nordjylland tidligere i dag, men nu viser det sig, at fejlen er meget begrænset og skyldes, at rejsekort-systemet i nogle tilfælde ikke er case-sensitivt, altså skelner mellem små og store bogstaver til brugernavnene. Fejlen er nu blevet rettet.

Oplysninger om rejser og optankning på de andre personer har været tilgængelige på den personlige side på rejsekortet.dk, men der har hverken været adgang til CPR-nummer eller oplysninger om betalingskort ifølge selskabet bag rejsekortet.

»Vi beklager fejlen dybt. Det er alene rejsedata, der har været tilgængelige. Personfølsomme oplysninger såsom CPR-numre er registreret, som lovgivningen foreskriver, og betalingskortoplysninger er kun registreret hos Nets,« siger adm. direktør i Rejsekort A/S Bjørn Wahlsten i en pressemeddelelse.

Fejlen kan opstå, fordi selvbetjeningen på rejsekort.dk tillader, at brugerne opretter sig med enslydende brugernavne, hvis blot der er forskel på små og store bogstaver. Når en bruger imidlertid bestiller en ny adgangskode, skelnede systemet ikke mellem små og store bogstaver, og dermed kunne det ske, at brugeren i stedet nulstillede adgangskoden til kontoen med det enslydende brugernavn og efterfølgende kunne få adgang til denne brugers konto.

Problemet er dog ikke så omfattende ifølge rejsekort-selskabet, der kun har fundet syv tilfælde af identiske brugernavne, hvor der kun er forskel på de store og små bogstaver. Brugerne har nu fået tildelt nye brugernavne.

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

Bruger for og efternavn til at identificere unikke brugere???? Kors i r....

Som jeg læser artikeln så bruger rejsekortet selvvalgte brugernavne til at identificere brugerne. Det er der mange systemer der gør. Mange brugere vil forsøge at vælge et brugernavn der består af deres navn eller initialer.

Rejsekortet har tilsyneladende så forskellige delsystemer der hver især implementere egne regler for sammenligning og opslag af brugernavne. Det er desvære også noget jeg har set alt for ofte, dog aldrig i denne variation. Men jeg er tit stødt på systemer hvor de enkelte dele havde forskellige opfattelse af hvad et validt brugernavn var med det resultat at man kun kunne logge ind igennem nogle af delsystemerne.

Men det kunne være interessant at dykke ned i hvordan fejlen kan være opstået. Er det fordi det slet ikke er speccet om brugernavne er følsomme overfor store/små bogstaver og hver udvikler bare har gjort hvad vedkommende fandt mest naturligt eller har speccen ændret sig?

Jeg kan i hvert fald levende forestille mig en specification der antød at store og små bogstaver havde betydning og at der på et eller andet tidspunkt er nogen der er kommet til fornuft uden at det er blevet konskvensændret gennem hele systemet.

Så jeg betragter det absolut som en fejl der er tegn på dårlig kvalitetskontrol og testning, men jeg kan også godt forklare hvordan fejlen kan været opstået uden idioti.

Christian Nobel

Peters indlæg er tidsstemplet til 15.51, og dermed skudt ind før det indlæg han kommenterer.

Det lader til at V2 har visse problemer med tid, muligvis at (now) afhængig af situation opfattes som universal tid, andre gange som lokal tid.

Edit - og det har de, dette indlæg er tidsstemplet en time før det er skrevet.

Jonas Høgh

Hvis man anvender en case-insensitiv RDBMS, fx MS SQL Server i standard konfiguration, er det vel lige til højrebenet for en ikke helt vågen udvikler at implementere login som

"select top 1 * from users where username = @username and password = @password"

og glemt password som

"select email from users where username = @username"

Det giver den beskrevne opførsel, og er vel ikke specielt pudsigt.

Morten Rasmussen

....hvis de absolut skulle sende brugernavnet rundt mellem alle delsystemerne, så kunne de da i det mindste hashe det forinden.

Det kan muligvis pege på grundlæggende problemer i arkitekturen hos Rejsekort.

Kvalitetskontrol, tjeklister, flere personer på den enkelte opgave, og omfattende tests (undtaget RL test!) er nok heller ikke den værste vej at gå.

Poul Pedersen

Hvis TINAandersen ved en fejl kommer til at nulstille password for tinaANDERSEN, så bliver nulstillet password vel sendt til den e-mail der er registreret for tinaANDERSEN og ikke til TINAandersen's mail?


Det afhænger da helt af hvilke og hvordan systemerne er lavet case-insensitive, og nok også en del af hvilken entry der kommer først i databasen når den slår navnet op?
Det kan jo nemt være at den kombinerer mail-adresse og link til den resatte konto op på to forskellige måder, selvom de bliver sendt ud i en mail?

Casper Olsen

Så langt så godt, men forklare ikke hvordan "a" har nulstillet "A" password og fået tilsendt dette? Man nulstiller jo ikke password på 1 record for at sende det ud til record 2..

Kan det tænkes man har lavet en brøler, og lavet en "update users where usenamer='a' (som ikke er case Sensitiv) og derved nulstillet begge brugers password?

og at "a" derefter ved en fejl har skrevet "A" under sit login ?

Peter Makholm Blogger

Så langt så godt, men forklare ikke hvordan "a" har nulstillet "A" password og fået tilsendt dette? Man nulstiller jo ikke password på 1 record for at sende det ud til record 2.

Jeg kan godt forestille mig et systemdesign hvor man har et minimalt system til håndtering af autentificering som vedligeholder en relation mellem brugernavne og kodeord (auth) og så et større system der vedligeholder en større samling af metadata om brugeren (admin).

Det vil sige at processen med at nulstille et kodeord vil se nogenlunde således ud:

  • Brugeren tilgår admin systemet og beder om en reset

  • Adminsystemet beder authsystemet om en reset-token for brugernavnet

  • Adminsystemet sender en url til brugeren der indeholder den reset-token der kommer fra authsystemet

  • Brugeren trykker på urlen og adminsystemet sender reset-token til authsystemet og får et brugernavn retur

  • Adminsystemet viser information om det brugernavn den har fået fra authsystemet

Hvis disse to systemer fortolker brugernavne forskelligt, så kan jeg godt forestille mig en fejl som den artiklen beskriver. Det virker måske som et unødigt kompliceret systemdesign, men det giver en bedre isolation af kodeord hvilket kan være ønskeligt.

Jeg forsøger ikke at forsvare udviklerne bag rejsekortet, men forsøger at lære af deres fejl så vi alle sammen kan blive bedre til systemudvikling. Mine ideer er dog baseret på vildt gætteri, så det ville være fedt hvis nogle teknikere der vidste noget kunne give en tekniske forklaring der ikke var blevet forvasket af en kommunikationschef.

Markus Lund

Det er mig ubegribeligt at man som developer i 2014 kan slippe af sted med at kode et system, som plukker brugere ude af en database baseret på en relation mellem for- og efternavn i stedet for, f.eks., et incrementiælt user-ID, som er statisk gennem brugerens levetid i modsætning til de gængse navnetyper beskrevet i Navneloven. (Et familienavn kan jo ændre sig ved vielser, og fornavne kan ændres på sognekontoret og er i realiteten dynamiske values, som derfor bliver utroværdige som user inputs.)

Det er ligegyldigt om programmøren har glemt at drikke sin kaffe i sin morgenstressede kodningsproces - det er en fejl, der ikke må ske (fordi den kompromitterer brugeres finansielle sikkerhed og øger risikoen for målrettet identitetstyveri), og som nemt ville kunne afhjælpes ved at sløjfe den relationelle sammenligning og i stedet holde sig 100% til ét enkelt, variabelt user input, nemlig 'username' - og selvfølgelig case-insensitive.

Der er i hvert fald en, der skal have repeteret sit introkursus på W3Schools.com. Firstname og Lastname er ligegyldig info databasemæssigt. En etisk korrekt username-validering skal ikke bestå af en kontrol af flere sammenhængende kolonner i samme tabel. Det afgørende er, at der foregår en kobling mellem borgerens unikke CPR-nr., som systemet bruger i forvejen qua NEM-ID, og så det selvvalgte username.

Markus Lund

Men det er jo heller ikke det, der er sket.


Men hvis det kan lade sig gøre at logge på en andens brugerkonto ved hjælp af sine egne credentials, så ændrer det ikke på at der er sket et fuckup i de relationelle sammentræk af tabellerne, og det burde ikke kunne ske, hvis man i databasen bruger identiske IDs til at holde styr på tabelrækkernes individuelle sammenhæng med hinanden. Case-sensitive eller ej. Databasen er ikke designet korrekt.

Hvis Tina Andersen logger ind med TINAandersen med uid X, og databasen udtrækker tinaANDERSEN i stedet for med uid Y pga. ovennævnte fejl, så vil tilsvarende relationelle udtræk via password-tabellens puid give en forkert adgangskode at validere med, hvis koderen havde gjort sit arbejde ordentligt. Brugeren ville altså slet ikke være i stand til at komme ind i første omgang. Loginscriptet, hvis det virkede efter hensigten, ville blokere permanent for login for den ene af dem indtil fejlen ville blive opdaget og rettet.

Log ind eller Opret konto for at kommentere