Advarsel: Forkert flueben i browseren giver andre adgang til din årsopgørelse

Illustration: REDPIXEL.PL/Bigstock
Har en bruger været logget ind på Skats selvbetjening før dig, risikerer du at få smækket en andens årsopgørelse op i browseren. Superbrugere kan slå funktionaliteten fra.

Har du tjekket din årsopgørelse på skat.dk fra en offentlig computer, risikerer dine personlige skatteoplysninger at havne hos den næste bruger af pc'en.

Det kan ske, hvis browseren er sat til at gemme krypterede data lokalt på disken.

Fejlen blev opdaget af en Version2-læser, der tjekkede årsopgørelsen for sin mor, hvorefter han ville tjekke datterens. Efter at have logget ud efter alle kunstens regler og lukket alle browservinduer - og genstartet computeren - fik han moderens årsopgørelse op på skærmen, selvom han var logget ind på Skat.dk med datterens NemID.

Læs også: Du er nummer 10.549 i køen - Skat parkerer danskerne i skyen for første gang

»Vi kender udmærket den problemstilling og har hørt om den flere gange. Vi oplever, at det primært handler om browserfunktionalitet og folks opfattelse af, hvordan man logger af,« siger kontorchef i Skat Søren Kjær Jensen til Version2.

Men brugeren her havde jo netop sikret sig, at log-af-proceduren var foretaget helt efter bogen?

»Hvis brugeren stadig oplever fejlen, så går vi til trin to: Så beder vi brugeren om at indstille browseren til ikke at gemme krypterede sider. Det er simpelthen browseren, der gemmer siden i cachen,« forklarer Søren Kjær Jensen til Version2.

Han understreger, at situationen typisk ikke har den store betydning, hvis computeren befinder sig inden for hjemmets fire vægge, men kan godt se problemet, hvis en pc på det lokale folkebibliotek ikke har slået funktionaliteten fra.

»Det er klart, at man bør være ekstra omhyggelig, når man bruger en offentlig pc til følsomme oplysninger, for det her er jo ikke kun et Skat-fænomen, men gælder også hvis man for eksempel er inde på sundhed.dk eller lignende sider. Så jeg håber, at administratorerne af de fleste offentlige pc'er efterhånden er klar over, hvordan browserens indstillinger bør være,« siger Søren Kjær Jensen til Version2.

Det er ikke første gang, at Skat har haft problemer med, at borgere får adgang til fremmedes skatteoplysninger. I november 2009 betød et dårligt design af login-løsningen, at to borgere kunne se hinandens forskudsopgørelse.

Læs også: Usandsynlig hændelse giver ny procedure: KMD dropper tidskoder i Skat-login

Sådan slår du funktionaliteten fra

Hvis du vil sikre dig mod, at andre ved en fejl kommer til at se dine skatteoplysninger, skal du i Internet Explorer gå ind under Internetindstillinger -> Avanceret -> Sikkerhed og her sætte flueben ved muligheden "Gem ikke krypterede sider på disk."

Tips og korrekturforslag til denne historie sendes til tip@version2.dk
Kommentarer (35)
sortSortér kommentarer
  • Ældste først
  • Nyeste først
  • Bedste først
#1 Simon Jonassen

man kan også opleve samme problem med bl.a netbanker.... Jeg har kunne finde alt mulig med kontonumre, bevægelser, adresse - you name it....

det er simpelthen ikke god nok ! - hvorfor placerer man problemet hos brugeren

"du kan bare sæt eller fjern ditten eller datten flueben"

man kunne fra udbyderens side slå caching fra med nogle få instruktioner i begyndelsen af .html, .asp, .aspx osv. filer.....

så er det fløjtende lige maget om brugeren har slået det til eller fra !

it isn't rocket science.....

/Simon :-)

  • 14
  • 1
#2 Michael Lykke

Så beder vi brugeren om at indstille browseren til ikke at gemme krypterede sider. Det er simpelthen browseren, der gemmer siden i cachen,« forklarer Søren Kjær Jensen til Version2.

Så må i sku lave jeres løsninger så den ikke cacher den slags på en måde så det bliver præsenteret igen og igen. Alle andre har formået at lave løsninger hvor den slags ikke sker, så bør Skat vel også kunne løse den lille "udfordring" med de adskillelige milliarder de bruger på IT systemer?!

  • 8
  • 1
#3 Simon Jonassen

her er lige en lille opskrift (asp/asp.net) - skal selvfølgelig tilpasses sprog og platform:

<% Response.CacheControl = "no-cache" %> <% Response.AddHeader "Pragma", "no-cache" %> <% Response.Expires = -1 %>

så skulle det problem være ud af verdenen.....

/Simon :-)

  • 10
  • 1
#4 Michael Lykke

Præcis! Det er et non-issue som enhver udvikler med mere end 4 timers erfaring burde kunne løse.

Det er svært ikke at blive godt gal i skralden med den lallende inkompetence der gennemsyrer det offentlige system i Danmark... Og det er på snart ALLE punkter lige fra Skat der bruger billiarder på IT løsninger som ikke kan forhindre caching til emails der bliver printet ud og transporteret via biler! Og den siddende regerings løsning på vores økonomiske problemer er at indføre den ene tåbelige skat og forringelse efter den anden... Måske man bare skulle finde nogle mennesker der er kompetente nok til at bruge IT - Så burde det være en smal sag at sparrer et stort milliard beløb hvert eneste år!

Føler mig virkelig hensat til "The Twillight Zone" som borger i Danmark!

  • 6
  • 2
#7 Anders Hessellund Jensen

Cache-Control headeren bør næremere være no-store. Som beskrevet i standarden:

The purpose of the no-store directive is to prevent the inadvertent release or retention of sensitive information (for example, on backup tapes). The no-store directive applies to the entire message, and MAY be sent either in a response or in a request. If sent in a request, a cache MUST NOT store any part of either this request or any response to it. If sent in a response, a cache MUST NOT store any part of either this response or the request that elicited it. This directive applies to both non- shared and shared caches. "MUST NOT store" in this context means that the cache MUST NOT intentionally store the information in non-volatile storage, and MUST make a best-effort attempt to remove the information from volatile storage as promptly as possible after forwarding it.

Men måske no-store ikke forstås af alle browsere? - Der er vist også nogen der angive begge, altså Cache-Control: no-cache,no-store

  • 5
  • 0
#8 Michael Lykke

@Anders - Uanset hvad den tekniske løsning skal være så bør det være en smal sag at løse. Det er decideret uansvarligt at man forleder sig på at alle folk i deres browsere skal sætte en indstilling på en bestemt måde for at undgå sikkerhedsproblemer med SKAT's løsning.

  • 9
  • 0
#10 Christian Schmidt Blogger

Så vidt jeg kan forstå, går den egentlige kritik på, at Internet Explorer kommer med en uhensigtsmæssig standardindstilling.

Dette problem kan (og bør) SKAT forsøge at afhjælpe - og at man uden at gøre noget særligt kan få en anden persons oplysninger frem på skærmen, når man beder om sine egne, er en decideret fejl hos SKAT uanset browserindstillinger (medmindre browseren ligefrem er konfigureret til ignorere de cacheheaders, som SKAT sender ud). Men det er Microsoft, der har besluttet, hvad standardindstillingen skal være, og dermed udgør problemets egentlige rod, så skytset skal også rettes mod dem.

  • 2
  • 11
#14 Anonym

Kan kun tilslutte mig, at der er tale om ren uansvarlighed.

Desværre, er det en rød tråd i stort set alt offentlig IT.

Man skal holde sig for øje, at selvom man ikke forstår loven eller at gebærde sig efter loven, er man ikke stillet uden for loven. Man må f.eks. heller ikke køre bil, bare fordi man ikke lige ved at man ikke må køre bil. Så når Skat, eller deres leverandør, ikke kan lave kode, holder det dem ikke ansvarsfri for loven. Jeg vil her henvise til f.eks. Persondataloven §41. Stk. 3.

  • 3
  • 0
#17 Christian Schmidt Blogger

Det kan godt være at MS har valgt en "forkert" default indstilling, men som udvikler burde man også tage højde for forskellige scenarier der kan optræde

Jeg fritog heller ikke SKAT for ansvar. Jeg undrede mig blot over, at journalisten ikke havde indhentet en kommentar fra Microsoft, hvis ellers der er tale om en usikker standardindstilling (jeg kan forstå af kommentarerne herover, at der er uenighed om, hvorvidt det er standardindstillingen eller ej).

  • 2
  • 0
#20 Simon Jonassen

Helt sikkert at man får bedre performance via caching og i visse tilfælde er det også forsvarlig nok, men IKKE de sider med personfølsomme oplysninger - her kunne man jo med fordele bruge den før omtalte http header til at forhindre det fænomen....

/Simon :-)

  • 5
  • 0
#22 Søren Lund

Udover ikke at have styr på basal brug af http headers, så har skat heller ikke sat autocomplete="off" på det input-felt hvor man skriver sit cpr-nr for at logge på.

Selv det ikke er en del af HTML-standarden, så virker autocomplete="off" så vidt jeg ved i alle browsere.

Med autocomplete="off" husker browseren ikke værdien af netop det felt (i dette tilfælde ens cpr-nr).

Det plejer at være "best practice" at sætte autocomplete="off" for felter til f.eks. kreditkort-nr. eller cpr-nr.

Jeg tror ikke ændringer af cache-indstillinger for ssl påvirker autocomplete.

  • 9
  • 0
#23 David Landwehr

Jeg har ikke set præcis hvad skat sender, men da årsopgørelsen er en PDF og forbindelsen er https, så vil cache-control: no-store muligvis medføre at man ikke kan se PDF filen direkte i browseren med fx adobe acrobat reader, fordi man har gjort det umuligt for IE at gemme filen til disk.

Se fx. http://support.microsoft.com/kb/2549423

Mange brugere vil muligvis ikke kunne forstå en besked om at filen ikke kan hentes...

  • 2
  • 0
#24 Tore Green

Man spørger sig selv om det er rimeligt at årsopgørelsen har samme URI for forskellige borgere. Hvis den enkelte opgørelse havde en unik URI ville de ikke blive forvekslet af cache-mekanismen.

(En korrekt cache-control header ville nu stadig være relevant, da man nok heller ikke er intersseret i at efterlade PDF'en i cache hvor andre kan finde den -- men det ville dog hjælpe hvis ikke den blev vist i tastselv!)

  • 4
  • 0
#26 Anders Johansen

@Christian Schmidt

Så omformulerer jeg mig selv... Ingen af mine 5 maskiner er sat til at cache HTTPS og jeg kan garantere dig for at jeg ikke selv har slået det fra... Så enten har det været i tidligere versioner af IE og der er kommet en rettelse til det, eller også vil mine maskiner af uransaglige årsager selv have slået dette fra...

  • 0
  • 0
#27 Lars Tørnes Hansen

Hej Søren Lund, tak for dine indlæg

Min Firefox cacher nu ikke længere https trafik, fordi de steder hvor jeg bruger https trafik normalt er i forbindelse med login, hvor caching netop ikke er alt for smart (til kodeord bruger jeg FFs password funktion, der kræver et master-password).

Jeg kom til at kigge på Chrome. Efter lidt gravet lidt rundt ude på nettet så fandt jeg disse 3 fra en gut der arbejder for Google. De giver adgang til flere indstillinger og informationer:

Det er:

  • chrome://net-internals/#httpCache kig også på #sockets, #events, og #timeline - ret interessant
  • chrome://appcache-internals/ for de 3 nye HTML5 caches (Application Cache, Indexed Database og Web Storage )
  • chrome://dns/ for DNS
  • 1
  • 0
#28 Elias Sørensen

Godt nok amatøragtigt af SKAT. Det kan SAGTENS slås fra server-side fra SKAT's side. Alternativt kunne der (for at være 110% sikker på den ikke bliver cachet) tilføje et timestamp til filnavnet.

At brugerne aktivt skulle ændre i dybe browserindstillinger er til grin.

  • 1
  • 0
#32 Simon Jonassen

@andreas Frithiof.........

rigtig god indgangsvinkel / pointe ! - undskyld sproget, men det med at pisse på den "lille" mand er altså allernemmeste...

desværre er der mange som ikke "forstår" sig på IT verdenen.... (hr. ofg fru jensen på 75 år på anden sal på nørrebro) - så tører man bare problemet af på dem..... du skal bare gøre sådan og sådan.....

makes me want to quote hamlet "something is rotten in the state of denmark"

/Simon :-)

  • 0
  • 0
#33 Mikkel Thielemann

"Han understreger, at situationen typisk ikke har den store betydning, hvis computeren befinder sig inden for hjemmets fire vægge, men kan godt se problemet, hvis en pc på det lokale folkebibliotek ikke har slået funktionaliteten fra."

Ikke fordi jeg vil forsvare SKAT, men blot for ikke at gøre folkebibliotekerne farligere, end de er. For det meste sådan, at folkebibliotekerne benytter et bookingsystem, der rebooter maskinen og læser et blankt image ind til den næste bruger. Dermed bliver alt der cashes jo slettet for good, eller hvad?

  • 0
  • 0
#34 Anonym

" Ikke fordi jeg vil forsvare SKAT, men blot for ikke at gøre folkebibliotekerne farligere, end de er. For det meste sådan, at folkebibliotekerne benytter et bookingsystem, der rebooter maskinen og læser et blankt image ind til den næste bruger. Dermed bliver alt der cashes jo slettet for good, eller hvad? "

Ikke nødvendigvis, det kommer an på hvad man gør.

Jeg vil gøre opmærksom på, at du bruger termen " For det meste ". Det hedder vist "på nogen".

Den største trussel mod den slags, er nok heller ikke folkebibliotekerne. Det er pt. alle virksomhederne. Både de private og de offentlige. Der indlæses ikke et nyt image, og hvis der skulle være indlæst et nyt image, er der intet der forhindrer, at virksomheden ikke allerede har snuppet data. Det er helt almindeligt, at virksomheder, både offentlige og private, overvåger medarbejdernes brug af IT. Det har de også hjemmel til i loven.

  • 0
  • 0
#35 John Øllgaard Jensen

Ja, netbanker! For mere end 2 år siden rejste jeg dette problem over for een af de DANSKE banker: Det startede med, at jeg havde slået caching af https-sider fra netop for ikke at skulle lagre personfølsomme data => Tilbage-funktioner virker ikke (man bliver smidt af systemet og skal logge på igen. F.eks. under visning af detaljer om en postering findes der en tilbageknap (tilbage til kontoudtoget, forstås). Bankens supportere "anbefaler" at kunden nulstiller browseren, men dette medfører at IE igen cacher https-data. Man har ikke villet forbedre/rette dette sikkerhedsproblem. I stedet sker der nu det, at efter at man har logget af på normal vis, er der en anvisning på hvordan man får IE til at slette de cachede data.

  • 2
  • 0
Log ind eller Opret konto for at kommentere