Hver anden danske webshop har alvorlige sikkerhedsfejl
Det står sløjt til med sikkerheden hos de danske webbutikker. Sådan lyder konklusionen på en analyse, som det danske Århus-firma Hackavoid står bag.
Efter at have kørt websider for 1.133 netbutikker igennem en scanning, viste det sig, at 49 procent havde fejl i kategorien 'alvorlig' eller 'meget alvorlig'.
Det overraskede datalog Anders Skovsgaard, der står bag Hackavoid.
»Jeg troede for eksempel, at der var ved at være ryddet ud i antallet af SQL-injections. Men dem var der stadig mange, der havde,« siger han til Version2.
De 1.133 netbutikker blev delt ind i fire kategorier: Ingen sikkerhedshuller, mindre alvorlige fejl, alvorlige fejl og meget alvorlige fejl.
Netop SQL-injection-sårbarheder placerede Anders Skovsgaard i kategorien 'meget alvorlige fejl', og hele otte procent af de undersøgte butikker havde dette sikkerhedsproblem.
I scanningen blev sårbarheden kun registreret, hvis der faktisk var hul igennem til databasen.
»Scanneren sikrer sig, at det faktisk er databasen, den taler med. Der bliver ikke trukket data fra tabeller ? det ville nok også være ulovligt ? men for en hacker er det nemt at trække brugernavne og passwords ud,« forklarer han.
'Alvorlige fejl' dækker over cross-site-scripting (XSS) på sider med login-felt. 41 procent af butikkerne havnede i denne kategori.
Når du har registreret en cross-site-scripting-sårbarhed på en login-side, kan alle disse huller så udnyttes i praksis, eller er det på et mere teoretisk plan?
»Ja, de kan udnyttes i praksis. Man kan for eksempel sende en e-mail til administrator for siden med et link, der udnytter sårbarheden. Hvis man beder ham om at rette en stavefejl på en af siderne, så ved man, han er logget ind, og klikker han så på linket, kan man få hans session-cookie og agere som ham,« siger Anders Skovsgaard.
I bunken af mindre alvorlige fejl, som udgjorde 15 procent, kom cross-site-scripting på sider uden login-felt, DNS rebinding og andre knap så kritiske problemer.
Endelig havde 36 procent af webbutikkerne 'nul huller'.
Små webbutikker værst
De 1.133 webbutikker blev valgt tilfældigt via forskellige offentlige lister over danske netbutikker. Der indgik både ganske små og helt store firmaer, og her kunne Anders Skovsgaard se et mønster.
De alvorligste sårbarheder blev typisk fundet på de små, hjemmekodede butikker, men mange af de store, som brugte software indkøbt til lejligheden, havde masser af de lidt mindre kritiske huller.
Generelt anbefaler Anders Skovsgaard derfor, at firmaer med en hjemmelavet løsning får kigget koden igennem.
»Det er svært at kode sikkert, hvis du sidder og arbejder op imod en deadline. Så laver folk banale fejl, som de godt selv ved, man ikke skal lave. Så få kigget kildekoden igennem systematisk og se på de requests, der bliver lavet,« siger han.
Firmaet Hackavoid blev grundlagt mens Anders Skovsgaard læste datalogi i Aalborg. Siden han blev færdig på universitetet i 2009 har han først haft et almindeligt lønarbejde, men sprang i efteråret 2010 ud som selvstændig med Hackavoid.
Kommentarer (11)
Det er nogle noget vidtgående konklusioner der bliver draget her:
”(..) ’men for en hacker er det nemt at trække brugernavne og passwords ud’ forklarer han.”
- det kræver så at passwords gemmes i klar tekst, frem for en hash.
” ’Ja, de kan udnyttes i praksis. Man kan for eksempel sende en e-mail til administrator for siden med et link, der udnytter sårbarheden. Hvis man beder ham om at rette en stavefejl på en af siderne, så ved man, han er logget ind, og klikker han så på linket, kan man få hans session-cookie og agere som ham’ siger Anders Skovsgaard. ”
- igen er der gjort nogle antagelser om hvordan tingene er indrettet, og for hvordan administratoren reagerer.
Anders Skovsgaard skal jo leve af det her, og man må sige at han får fin, gratis reklame, uden at man journalistisk forholder sig til indholdet. Jeg er ikke journalist, men er det ikke en grundlæggende journalistisk disciplin at inddrage flere kilder, og helst nogen uden direkte økonomisk interesse?
Man skulle næsten tro at sikkerhedsapostlene havde hacket sig ind i de danske mediers CMS systemer, så de selv kan plante historierne.
-
0 -
0
Selvom det måske kun er et passhash du trækker ud, er det da alligevel ikke særligt heldigt, da mange sider blot gemmer disse passhashs i cookies og derved er man logget ind.
Eller som da newz.dk blev hacket, hvor kodeordene ikke var hashet ordentligt, og de blev dekrypteret (eller hvad det nu hedder når det er hashs) [1]
[1] http://www.version2.dk/artikel/5710-endnu-et-hack-5000-danske-brugernavn...
Og syntes da heller ikke Anders Skovsgaard siger noget om det er generelt man kan udnytte det sådan, men kommer med eksempler på udnyttelse.
Så syntes da det er godt der kommer fokus på problemet.
-
0
-
0
Hej Henrik.
Tak for din kommentar. Der er desværre begrænset spalteplads, så både journalisten og jeg er nødt til at begrænse os med forklaringerne.
Mht. SQL Injection er det korrekt at password's ofte hashes. Dog ses det ofte at man f.eks. kan anmode om nulstilling af password - Wordpress har f.eks. denne feature. Derefter kan "user_activation_key" udtrækkes og dermed kan en angriber nulstille adgangskoden og logge ind. Husk også at information som ordrer, nyhedsbrevsabonnenter, kunder m.m. kan udtrækkes.
Mht. Session-cookies er det korrekt at det ikke altid er muligt at udtrække eller benytte disse. Dog kan andre alvorlige angreb udføres i stedet, hvor al administrator-indhold videresendes til en angriber (f.eks. kundelister) eller request's foretages ind i administratorens session.
-
0
-
0
Som jeg tolker denne artikel, så har Hackavoid scannet 1133 webbutikker uden at indhente tilladelse fra de enkelte webbutikker - er dette korrekt?
-
0
-
0
Hej Kenni.
Det er korrekt. Det er dog harmløse requests der bliver udført mon web-shoppen og der udtrækkes aldrig data fra databaser.
Google gennemgår f.eks. dagligt hjemmesider for nogle af de samme ting - f.eks. om der er malware på siden eller om CMS'et er up-to-date.
Vi laver dog nogle flere requests hvor URL'en ændres en smule for at undersøge om der f.eks. er SQL Injection eller XSS - igen uden at udtrække eller ændre noget på siderne.
Vi offentliggør naturligvis ikke nogen af de web-shops vi har gennemgået.
-
0
-
0
Ærgeligt at det er nødvendigt, men jeg kan godt se hvorfor.
Jeg har haft flere af mine sider hacket. I nogle tilfælde har det bare været en afmaskering - fordi der sidder en eller anden idiot der ude, som synes det kunne være sjovt. Men jeg har også oplevet det på min webshop, hvor der blev lagt spyware ind, og her nåede Google at straffe min side, som om det var et usikkert sted på nettet at gå ind.
-
0
-
0
det er da den dårligste forklaring jeg nognensinde har hørt! der er da alt den plads du kunne drømme om her på siden! jeg tror jeg går igang med at lede efter sikkerhedshuller hos version2 og hackavid nu! det må man jo gerne!!!
-
0
-
0
Hej Peter.
Så først dit indlæg nu. Måske du misforstod mit svar til Henrik. Naturligvis er der masser af plads her i debatten. Det jeg hentydede til i svaret er at man i artiklen er nødt til at skære forklaringerne et sted. Netop derfor uddyber jeg meget gerne her på siden og svarer gerne på spørgsmål.
-
0
-
0
Det er nu ikke nogen nyhed at nettet er fyldt med huller, heller ej at det generelt er utroligt svært at fortælle ejeren af et sikkerhedshul om problemet uden at blive gjort til ondsindet blackhat hacker i gang med pengeafpresning eller det der er værre.
@Anders Skovsgaard, du tjekkede vel ikke for klassikeren, webformen hvor man selv kan bestemme prisen?
-
0
-
0
Ingen grund til at lede længe, V2 har haft og kendt til deres CSRF hul i årevis. Husk at spille fair og sætte evil til 1 så de har en chance.
-
0
-
0
@Anders Skovsgaard, du tjekkede vel ikke for klassikeren, webformen hvor man selv kan bestemme prisen?
For at teste denne type sårbarhed er man ofte nødt til at registrere en ordre i web-shoppen. Vi lavede denne undersøgelse med et mindst muligt fodaftryk i loggen. Derfor blev der ikke gjort noget for aktivt at afslutte et bestillingsforløb.
Men det er bestemt en sårbarhed vi har fokus på. Rigtig mange får f.eks. ikke implementeret checksums når der stilles videre til betalingsmodulet - hvormed valuta, beløb m.m. kan ændres.
-
0
-
0
