Sikker og fejlfri software er billigst i længden
Skrevet af Grosen Friis | 30. april 2007 |Placeret i Personligt
Sikker og fejlfri software er billigst i længden
Jeg har netop siddet og læst de seneste indlæg på Mikkel deMib Svendsens blog om blandt andet en ny cross site scripting bug i PHP
Hvad er PHP og hvad betyder “Cross site scripting bug” ?
- PHP er et programmeringssprog og er det programmeringssprog som al software i min gamle virksomhed grosen.com var baseret på, og det samme gælder for OP. Derudover er en blog som denne baseret på WordPress platformen, som også er udviklet i PHP.
- En cross site scripting bug er en type fejl, hvor man via en hjemmeside adresse (URL) kan overføre skadelig kode til den hjemmeside som bliver kaldt.
Et tænkt eksempel kunne være:
http://www.gblog.dk/indlaeg-om-ivaerksaetteri.php&bloglink=her-kommer-den-skadelige-kode
Som programmør forventer man kun at brugeren kan finde på at kalde siden på denne måde:
http://www.gblog.dk/indlaeg-om-ivaerksaetteri.php
men har man ikke været opmærksom på, at man har en variabel i sit system, der læser en URL parameter, der hedder ‘bloglink’, og som kan medbringe skadelig kode (Det vil sige ‘her-kommer-den-skadelige-kode’) og hvis man ikke sørger for at få uskadeliggjort denne kode, så kan det misbruges på mange måder, som er mere eller mindre skadelige.
Spørgsmål om softwaresikkerhed får mig til at tænke på programmørens ansvar
Når jeg læser om manglende sikkerhed i software, og det har det jo med at dukke op indimellem, tag eksempelvis en af de i skrivende stund meget omtalte historier om Nordeas manglende sikkerhed i deres netbank. Så kommer jeg ofte til at tænke på det ansvar man har som programmør, for at gøre det software man udvikler så fejlfrit og så sikkert som overhovedet muligt, og det kommer jeg nærmere ind på nedenfor.
Sikkerhed og minimering af fejl er kedeligt arbejde i mange programmørers øjne
Jeg ønsker ikke med dette blog-indlæg at fremstille mig selv som en super programmør, der aldrig har eller aldrig vil lave fejl. Selvom man gøre sig umage, så vil man lave fejl, og det har jeg også gjort i min programmerings-karriere. Men jeg minimerer det ved at bruge meget tid på validerng af parametre, når jeg koder (Det gælder også i PHP). Smid for eksempel en streng variabel med et tal ind i en metod/funktion, der tilhører en klasse (PHP kode) jeg har skrevet, hvor metoden kræver en float variabel, så får du en fejlmeddelelse smidt tilbage i hovedet igen.
Det er blandt andet med til at afsløre fejl i software på et meget tidligt tidspunkt, hvor de er nemme at spotte og billige at få rettet. Fejl, der spottes sent i et softwareudviklingsforløb, har det med at have grimme sideeffekter, som det kan tage lang tid at få rettet, og efterfølgende at få testet. På sigt gør det derfor kode meget mere fejlfri og “robust”.
Jeg har dog igennem min tid som programmør i forskellige sammenhænge stødt på nogle ,som synes at forebyggelse af fejl og sikring af en høj sikkerhed i software er kedeligt at kode, og det har fået dem til at springe over hvor gærdet er lavest. Jeg har også oplevet at sikkerhed og forebyggelse af fejl har haft meget lav prioritering hos ledelsen af softwareprojekter, da det jo ikke er med til at man hurtigt får nogle færdige skærmbilleder, med nogle underliggende funktioner der virker. Sikkerhed og fejlsikring gør jo, at software projekter kommer til at tage mere tid, og de bliver dermed dyrere at udvikle.
Softwareudvikling kommer til at tage længere tid fremover
Softwareudvikling vil komme til at tage længere tid fremover, for af sikkerhedsmæssige årsager så skal vi til at kontrollerre alle URL overførste parametre:
- Kommmer de altid fra fx en PHP side på ens egen hjemmeside, der hvor hjemmesiden kører i drift?
- Er der nye parametre med i hjemmeside adressen, udover dem som man forventer?
- Sørger man for at få uskadeliggjort evt. skadelig kode i fx PHP, JavaScript eller SQL?
- Sørger man for at minimere brugen af URL overførste parametre, og i stigende grad bruge POST overførte parametre, også selvom det i mange situationer ikke er den letteste måde at overføre parametre på! (POST overførte parametre er fx når man indtaster sine kontaktoplysninger i en kontakt formular på en hjemmeside og klikker på en ‘Send’ knap).
Softwareudvikling kommer til at blive dyrere i anskaffelse, men…
Softwareudvikling kommer sikkert til at at blive endnu dyrere i fremtiden, hvis man vælger at fokusere på at gøre noget ved ovennævnte sikkerhedsspørgsmål. Men på lang sigt vil det altid være billigst at fokusere på sikkerhed og på at minimere antallet af fejl, for det kan koste dyrt i den anden ende at skulle bruge ekstra tid på at rette fejl og teste fejlrettelser og man kan risikere at miste kunder på det og at få alvorlige ridser i sit renomme, se fx sagen hvor Københavns kommune ender med at fyre Accenture pga. levering af et nyt lønsystem, som var fyldt med fejl og som Accenture ikke formådede at få rettet inden Københavns kommune mistede tålmodigheden.
Programmering er ligesom så meget andet her i livet, det er 80% rugbrøg og 20% lagkage
/Grosen Friis
