Kan du kode en webshop sikkert? Her er fire farlige begynderfejl
Det kræver ikke meget af udviklerne at forbedre sikkerheden i danske webshops. Som regel er det begynderfejl, der nemt kan undgås, som giver sikkerhedsproblemer.
Sådan lyder det fra webudvikler Mads Kierulff fra firmaet Kraftvaerk, efter at Version2 mandag skrev om, hvordan halvdelen af de danske netbutikker har alvorlige sikkerhedshuller.
»Hvis man ikke er så erfaren som webudvikler og mest koncentrerer sig om at få det til at virke, kan man godt glemme at kode sikkert. Men det kræver ikke mange kræfter eller tid, hvis man bare tænker over det,« siger Mads Kierulff.
Han peger på fire typiske begynderfejl, der kan have store konsekvenser for sikkerheden:
- Mulighed for SQL-injection, fordi forespørgslerne ikke bliver renset for farlige input.
»SQL-injection-huller er den fejl, man oftest ser, men det er samtidigt den farligste. Hvis man ved, hvad man gør som hacker, kan man få fuld adgang og aflure hele databasen,« forklarer han.
Kuren mod SQL-injections er nok velkendt hos mange udviklere, men bliver altså stadig glemt på mange professionelle websider: En kontrol af alle forespørgsler til databasen, så uvelkomne tegn kan blive sorteret fra.
»Problemet med SQL-injections har man mest på webshops og andre steder, hvor man skal logge ind. Så kan en hacker nemlig få adgang til brugernes passwords, og hvis det er virkelig dårligt lavet, deres kreditkort-oplysninger,« siger webkonsulenten.
- Manglende HTTPS på betalingssiderne. Når betalingskortet skal frem, skal kommunikationen selvfølgelig været sikret med HTTPS, som gør det svært for andre at kigge med.
»I dag køber de fleste en løsning udefra, fordi sikkerhedskravene fra DIBS og andre betalingsudbydere bliver højere. Men hvis man selv flikker en løsning sammen til betalingsflowet, skal man huske at sikre det med HTTPS,« siger Mads Kierulff.
- Minus-varer i indkøbskurven. I mange webbutikker kan man justere antallet af en vare med plus- og minus-knapper. Men hvis antallet af varer kan blive negativt, med flittig brug af minus-knappen, kan kunden give sig selv rabat.
»Køber man ti save og minus fem hamre, kan beløbet, man skal betale blive meget lavt. Det er en klassisk begynderfejl ikke at sikre, at tallet skal være positivt,« siger Mads Kierulff, som dog vurderer, at alle de store webbutikker nu har fået stoppet det trick.
- Javascript i kommentarfeltet. Hvis ikke kommentarfelter og diskussionsfora spærrer for Javascript, kan en hacker overtage andre kunders login.
»Kan hackeren lægge et stykke Javascript ind i for eksempel en kommentar, som andre brugere så læser, vil koden blive eksekveret, så hackeren kan overtage andres sessioner og så logge på den bruger,« forklarer Mads Kierulff.
Køber man en færdig løsning til at håndtere et forum eller kommentarer, vil Javascript være forbudt, men hvis folk selv får kodet en løsning, kan det gå galt, vurderer han.
Rådene til udviklere bliver fulgt op med generelle tips til alle webshop-kunder:
Brug ikke samme password på mange forskellige websider, og pas på webshops, der gemmer dine kreditkort-oplysninger.
»Det er ikke tilladt i Danmark at gemme kreditkort-data, men i udenlandske webshops kan det ske, uden at du får noget at vide. Så kan du handle næste gang uden at indtaste det hele igen, men dataene kan også blive stjålet af hackere,« siger udvikleren.
Store, anerkendte firmaer som Amazon tør han dog godt selv overlade sine betalingsoplysninger til.
Artiklen er en del af Version2's tema om it-sikkerhed, der kører i uge 7 og 8.
Kommentarer (9)
Sikkerhedsfirmaet HBGary fulgte ikke adskillige af de nævnte råd, men var sårbare bl.a. pga. SQL-injektion og genbrug af væsentlige passwords.
Desværre (for dem selv) prøvede de at infiltrere internetaktivisterne Anonymous, som kvitterede med et cyber-angreb, der nærmest har lagt HBGary i ruiner.
Der er en meget god gennemgang af HBGarys fejl her:
http://arstechnica.com/tech-policy/news/2011/02/how-one-security-firm-tr...
Så også et (selv-proklameret) sikkerhedsfirma har problemer med at holde deres web-sted sikkert.
-
0 -
0
Har det virkelig en nyhedsværdi, at webudviklere skal passe på SQL-injections (og inputvalidering generelt), kommunikationskryptering og XSS? Jeg synes kun det er punkt 3 der er interessant i denne artikel, da punktet forholder sig specifikt til webshops.
På den anden side kan man vel ikke sprede budskabet nok. ;)
-
0
-
0
Hvis der er nogle studerende på Aalborg Universitet der gerne vil lære at kode sikkert er der en fri studieaktivitet i Anvendt Sikkerhed her i foråret, der bl.a. omhandler webapplikations-sikkerhed.
For mere information se
http://www.sict.aau.dk/digitalAssets/15/15889_poster_dat.pdf
Disclaimer: Jeg er en af kursusholderne.
-
0
-
0
Selvom nøje test af input-variabler er uundværelig, er den største sikkerhed mod sql-injections dog "parameter binding" i sql-kald.
Kort sagt, har man en place-holder (fx. $1) i selve sql'en og overfører paramterne ved siden af (out-of-band).
Derved ved sql-serveren at parametre er parametre og kører ingen kode. Vupti, sql-injections kan ikke lade sig gøre mere (men det kan fx. cross-site-scripting stadigvæk, så parameter binding er ikke en beskyttelse mod alt!)
Dette kræver naturligvis også at din sql-server (og dit client-library) begge understøtter det... I php med pgsql kan man f.eks. kalde pg_query_params()
-
0
-
0
»Det er ikke tilladt i Danmark at gemme kreditkort-data, men i udenlandske webshops kan det ske, uden at du får noget at vide. Så kan du handle næste gang uden at indtaste det hele igen, men dataene kan også blive stjålet af hackere,« siger udvikleren.
Så vidt jeg husker, så tilbyder Just-eat en løsning, hvor de netop gemmer kreditkortoplysninger.
Gør Just-eat så noget ulovligt eller er det fordi det slet ikke (længere) er en dansk virksomhed eller hvordan hænger det sammen?
-
0
-
0
Så vidt jeg husker kræver det en PCI certificering til pænt mange penge, hvis man selv skal håndtere kreditkortoplysningerne. De færreste webshops i DK benytter dette, da det simpelthen er for dyrt ifm. gevinsten ved det.
Så vidt jeg ved benytter DIBS et almindeligt FlexWindow fra DIBS i deres betalingsflow, dvs. hosted på DIBS' servere, og hvor Justeat ikke har adgang til kortinformationerne.
Hvis man kigger på danske webshops, må problemet med adgang til kreditkortoplysningerne hvis man udnytter et SQL injection hul, være ganske små. Eftersom de færreste webshops har disse oplysninger liggende. ´
Ligeledes burde problemet med manglende HTTPS på betalingssiden heller ikke være et stort problem hos danske webshops. Og i så fald problemet eksisterer burde det rapporteres til Nets ASAP.
-
0
-
0
Husk også at der jævnligt er møder i OWASP regi i det danske "chapter", se mere på www.owasp.dk
og ja, det er desværre også relevant at gentage disse råd .... alt for mange steder i DK er det meget nemt at hacke sig ind med bare en browser (og måske Tamper Data add-on til Firefox).
PCI certificering koster godt nok en del, men der er nogle stykker i Danmark der har valgt at gøre dette.
-
0
-
0
Må ærligt indrømme, at jeg bestemt heller ikke ser "Manglende HTTPS på betalingssiden" som en "typisk begynderfejl". Faktisk er det over 5 år siden jeg har set en shop, der ikke har styr på det.
For det første kører de fleste shops igennem et vindue/en adresse hos en betalingsgateway.
Kun en håndfuld shops er store nok til at have det integreret, og betale regningen for det (på f.eks. PCI-godkendelse). Og her vil manglende HTTPS blive fanget dels af PBS, når de skal godkende løsningen, og dels når de skal have PCI-godkendelsen.
Hvis du vil have et typisk sikkerhedsproblem på webshops, så er det nærmere at de kan "snydes" via modificerede parametre på ordrekvitteringssiden. Eller ved ikke at kontrollere krypteringen på den såkaldte callback-side (eller slet ikke benytte callback-siden).
Desuden er det sjældent at webshops har debatforum og kommentarfelter. Og endnu mere sjældent at man kan lægge javascript i dem.
Desuden kan man spørge sig selv: Hvad sker der egentligt, hvis det lykkedes nogen at hijacke en session? Hvad kan man rent faktisk bruge det til? For du skal jo stadig indtaste navn, adresse og kreditkort-informationer for at gennemføre en ordre.
-
0
-
0
Tilføj kommentar
