Kodefejl sendte Mit.dk til tælling i to døgn: Leverandør insisterer på, at løsningen var gennemtestet

4. april kl. 15:0020
Mit.dk
Illustration: Netcompany.
Selvom vinduet for en giftig kodefejl på Mit.dk blev lukket i efter godt en time, kan mange borgere have nået at snage i andres digitale post med dybt følsomme oplysninger. Det viser dokumenter fra Datatilsynet, hvor leverandøren Netcompany garanterer, at systemet var gennemtestet før opstart. 
Artiklen er ældre end 30 dage

Man skal næppe bladre længe i sin egen digitale postkasses mange dokumenter fra skatteforvaltningen, kommunen og ens arbejdsgiver, før man kan konkludere, at det meste nok ikke vedkommer andre – og da slet ikke fuldstændigt fremmede. 

Alligevel var resultatet af en kodefejl i den stort opslåede Mit.dk-løsning fra Netcompany netop det. Ved lanceringen fik et endnu ukendt antal borgere adgang til andres postkasse, og de har dermed potentielt kunnet læse med i dybt fortrolige korrespondancer mellem borger, virksomheder og det offentlige. 

Få fuld adgang til DigiTech

DigiTech er til professionelle, der arbejder med offentlig digitalisering og it-projekter.

Få 3 uger gratis prøve abonnement til DigiTech. Betalingskort er ikke påkrævet, og du vil ikke blive flyttet til et betalt abonnement efterfølgende.

Du kan også få tilsendt et tilbud til dig.

Abonnementsfordele
vpn_key
Fuld adgang til DigiTech
Alt indhold på DigiTech er åbent for dig, så du kan nyde det fra din computer, tablet eller mobil.
drafts
Kuraterede nyhedsbreve
Nyheder, interviews, tendenshistorier og meget mere, leveret til din indbakke.
Adgang til andre medier
Hver måned får du 6 klip, som kan bruges til permanent at låse op for indhold på vores andre medier.
thumb_up
Adgang til debatten
Deltag i debatten med andre professionelle.
20 kommentarer.  Hop til debatten
Debatten
Log ind eller opret en bruger for at deltage i debatten.
settingsDebatindstillinger
31
28. april kl. 09:33

Ja, så kom der en ny version (1.1.1) af appen mit.dk til Android, men det hjalp ikke (den "gamle" afinstalleret før nyinstallation) Jeg kan stadig ikke komme forbi "Fortsæt" uden at få en "Bad Request" på gateway.digital.post.dk.

22
5. april kl. 07:42

Hvis man skal lære noget af det, må det være, at ordentlige tests af hele systemet er vigtigt. Man kan ikke nøjes med små hurtige unittests.

25
5. april kl. 07:48

Fuldstændig enig. Og inden man starter testen kunne man passende få nogle erfarne systemarkitekter til at gå de koncpetuelle designkriterier for Mit.dk igennem. I lyset af den omtalte fejl kunne man passende få dem til at sætte fokus på bl.a. alt hvad der kan ske, når man skifter sessionsnøgle mellem frontend og backend, med specielt fokus på sessionens kobling til MitID. Det er noget af en opgave, bl.a. fordi forskellige browsere har kedelige tendenser til at behandle sessionsbegrebet forskelligt.

21
5. april kl. 07:40

Diagnosen er forkert - der er ikke tale om en kodningsfejl! Det der beskrives i artiklen er en konceptuel og arkitekturmæssig designfelj - ikke en kodefejl. En kodefejl beskriver en fejl, hvor et stykke software gør noget andet end tiltænkt. Beskrivelsen her afdækker, at softwaren gør nøjagtigt som tiltænkt, men at tankerne bag funktionen er forkert.

En strid om ord? Nej, bestemt ikke. Kodefejl opstår når en systemkoncept omsættes til kode. Den beskrevne fejl er sket på konceptniveau - hvor det åbenbart er besluttet at bruge en forkert sessionsidentifikation i systemet - formodentlig fordi den sessionsidentifikator som frontenden vedligeholder, åbenbart ikke er god nok, eller ikke kan overføres til backend systemerne. At skifte sessionsnøgler under vejs er der intet odiøst i, men her er konceptet udviklet uden hensyn til eller forståelse for løsningens realtidsegenskaber.

Den slags fejl skal fanges på designtedspunktet - ikke i kodetest, og da slet ikke i "slutbrugertest" med live data.

Er det ikke lige meget - når nu fejlen er fundet og rettet? Absolut ikke. Når der opstår konceputelle fejl på dette niveau, er det alvorligt. Risikoen for, at lignende fejl ligger andre steder i løsningen er overhængende, netop fordi den aktuelle fejl afslører mangel på systemforståelse. Blot for at nævne nogle få problemområder: Tilgangen til og låsningen af records i backend systemets databaser; Håndtering af sessionsudløb eller afslutning i frontenden, med låste records i backenden; Spærring eller udløb af brugerens MitID under en kørende session; Samtidig tilgang fra samme bruger via forskellige apps (web, mobilapps osv.), med samme MitID, men med forskellige sessioner; Samtidig tilgang fra to forskellige brugere til samme persons data (muligt via værgemåls tilgang).

30
9. april kl. 11:12

Jeg synes nu det lyder ganske plausibelt.

Mit gæt på hvad der er sket, er at nøglen er blevet gemt i et felt i en service som er tilgængelig for flere tråde og at der på den måde er sket en forurening på tværs. Jeg har set andre udviklere lave netop denne fejl og med fuldstændig de beskrevne konsekvenser.

Services er som regel lavet som singletons og hvis man kommer til at opbevare en værdi i et for stort scope, så kan det være ganske svært at fange i en test.

Det er noget som skal fanges af en udvikler i et kode review. Dog vil jeg mene det er en ret simpel fejl, det er sgu ret pinligt.

Årsagen til det måske ikke kan fanges ved en automatiseret test er som de beskriver, at lige præcis login delen op til Nemlog-in kan være utrolig svært at automatisere på grund af to faktor elementet.

27
5. april kl. 11:59

Absolut korrekt. Denne type fejl løses ikke ved hverken unit-test, integrations-test, performance-test etc. Det er et design review af løsningen med deltagelse af erfarne folk med 'sikkerheds briller' på, og ikke nødvendigvis den billigste.

29
6. april kl. 09:03

Jeg er meget uenig. Den helt konkrete fejl vile blive fanget af en integrationstest af 75 minutters simulering af normal drift. Det er faktisk en utrolig ussel lille test.

Hvis nogen påstår, at sådan en test er for ressourcekrævende til at kunne gennemføres, må jeg spørge om følgende: Hvordan kan man så finde ressourcer til at drifte det 24/7/365 bag efter?

Men du har ret i, at typen af fejl kan være så sporadisk, at den ikke kan findes via tests. Men det gælder ikke for den konkrete fejl i artiklen.

28
5. april kl. 12:47

Denne type fejl løses ikke ved hverken unit-test, integrations-test, performance-test etc. Det er et design review af løsningen med deltagelse af erfarne folk med 'sikkerheds briller' på, og ikke nødvendigvis den billigste.

Enig - og typisk løses den type af konceptuelle designfejl heller ikke på to døgn. Risikoen for fejl i uigennemtænkte og utestede lappeløsninger er alt for stor.

Og ja, prisen for erfarne systemarkitekter med 'sikkerheds briller' er høj - men det er prisen for at undgå de monumentale fejl der opstår i kølvandet på dårligt design og forkerte koncepter.

Som man siger: Hvis du synes det er dyrt at bruge dyre konsulent, så vent og se hvad det kommer til at koster at bruge billige. QED.

17
4. april kl. 17:50

Netcompany forklarer, at det ville kræve ‘hundredvis af loginforsøg inden for samme sekund/millisekund for at fejlen kunne genskabes.’

Men kun 2182 borgere nåede at logge på Mit.dk mellem forpremieren kl. 8 og nedlukningen kl. 9.15. Selv hvis alle først loggede på efter det officielle åbningstidspunkt kl. 9, giver det kun ca. 150 pr. minut i snit. Har der virkelig siddet hundredvis parat for at logge ind præcis på sekundet?

16
4. april kl. 17:02

Hvornår lavet Version2 en artikel om deres eget kommentar system, og, hvordan man designer UX komponent state. ?

9
4. april kl. 16:53

Jeg kommer stadig ikke forbi "Fortsæt" på forsiden, dvs. jo, til et "Bad Request" på gateway.digital.post.dk. :-)

Supporten sendte den til 2. level support for 11 dage siden, og i dag efter at have gentaget oplysninger om version af app (1.0.0) (seneste på Google Play) og mærke/model på mobil samt OS-version og screendump af "Bad Request" på gateway.digital.post.dk givet første gang, blev den igen sendt til 2. level support.

Jeg har ingen problemer med MitID, NemID, e-Boks, MinSP, Sundhedkort, kørekort osv.

18
4. april kl. 18:58

Jeg kommer stadig ikke forbi "Fortsæt" på forsiden, dvs. jo, til et "Bad Request" på gateway.digital.post.dk. :-)

Jeg oplevede samme fejl med e-Boks. Har du prøvet at nulstille app'en? Jeg mistænker at en gammel fejl fra Digital Post/NemLog-in kan 'gemmes' i en cookie, men det er noget besværligt at slette cookies i en app. I browseren skulle jeg slette samtlige cookies fra e-Boks, NemLog-in, mitid.dk og Digital Post og så kunne jeg komme ind.

19
4. april kl. 23:45

Jeg har afinstalleret mit.dk og geninstalleret appen. På PC i browser er der ingen problemer, og jeg har aldrig tilgået e-Boks, NemLog-in, mitid.dk og Digital Post i en browser på mobilen, og har aldrig installeret appen Digital Post.

Jeg prøvede lige at slette "Brugerdata" og "Cache", men det hjalp ikke.

Så hvordan er det lige man sletter cookies i en app?

6
4. april kl. 16:45

Så så drenge - husk at netcompany kun ansætter unge & højtudannede.

Det er jo lidt svært at udvikle asynkrone applikationer, såsom at hindre at "nodes" forveksles. Enhver der har progget fx. et interrupt-drevet system, ved at man skal cleare alle andre for at undgå dette. Absolut amatøragtigt....

Men måske røg opgaven til Indien ad bagdøren ! Hvem ved ?

Men I Danmark hænger man ordener på idioter (citat: Heiberg i eksil om DK). Vi skal stadig leve med logning etc..

2
4. april kl. 16:31

Mit.dk

Lader til at være oppe (mandag 4/4, kl 16:00) - og finder de samme dokumenter som fx e-boks.dk.

Så vidt, så godt - i hvert fald bedre end forleden. Hvad fejlen bestod i, vil man selvfølgelig ikke ud med:

Hos Netcompany fandt man, ifølge anmeldelsen ud af, at fejlen var en ‘kodefejl i komponenten der bruges til identifikation/autentificeringen af brugerne.’

Det kunne enhver amatør, sikkert også regne ud. Så påstod man ovenikøbet at "løsningen" var testet, inden den åbnede. Det må være den slags test man i branchen almindeligvis kalder "åben Alpha".

1
4. april kl. 16:14

Så den menneskelige fejl ( https://www.version2.dk/artikel/netcompany-mitdk-nedbrud-skyldtes-menneskelig-fejl ) var fordi et menneske havde lavet designet forkert eller implementeret det forkert. Og ingen havde opdaget at en loginsession blev identificeret af et tidsstempel og ikke noget med brugercertifikater eller andet hejs. Ikke en Netcompany fejl, men en individuel persons fejl.

Mange ting var også meget lettere hvis man kunne forvente seriel eksekvering, dumme brugere der prøver at logge på samtidigt!