Sikker udvikling 1 : Verden er fuld af huller...

Illustration: Privatfoto

Jeg elsker at hacke websites. Mange websites har åbentlyse sikkerhedshuller, og oftest finder jeg sårbarheder indenfor 10 minutter.
Det er sårbarheder, der skyldes rent og skær ubetænksomhed og som kan opdages og løses ved et minimum af omhu og viden.

Alligevel får jeg altid et kick ud af et hack?

Den største umiddelbare risiko er, når man i websitet ikke har implementeret tilstrækkelig input-validering, og det er muligt at udføre SQL injections. Pludseligt er det muligt at bruge websitet som en angrebsvektor til resten af virksomhedens netværk. På virksomhedens website kan man finde e-mail-adresser på alle ansatte, hvilket er
en nem og bekvem måde at sende mails med en trojansk hest til alle ansatte. Dybest set er der kun én ansat, der skal falde i, før hackeren har adgang til virksomhedens netværk igennem VPN-forbindelsen.

Når jeg tester et website taler odds for at der er fejl. Mit gæt er, at omkring 9 ud af 10 websites indeholder sårbarheder der kan findes uden alt for stor anstrengelse.

En fejl jeg ofte finder, er, at en mailformular på websitet kan bruges til at spamme med. Pludseligt er din mailserver blacklisted, og du kan ikke sende mails til halvdelen af dine kunder. Hvis din virksomhed lever af at sælge sine ydelser på internet, kan det have alvorlige økonomiske konsekvenser.

Hvorfor er der så meget dårligt udviklet kode? Jeg tror, der er flere grunde. En grund er, at udviklingen i IT-branchen er for mange gået for hurtigt. Nogle virksomheder er vokset så hurtigt, at modenheden ikke har kunnet vokse med, og det resulterer i mangelfulde procedurer. Der er meget stor forskel på at være én programmør og på at være 10 på det samme projekt. Som programmør i en hektisk hverdag sker det, at man vælger den nemmeste vej, hvis der ikke sættes krav til sikkerheden i applikationen.

Én ting er, hvad jeg tror, og hvordan min opfattelse af verden er. En anden ting er, hvordan det rent faktisk opleves af dem derude, som sidder og programmerer hver dag, og det er her, du kommer ind i billedet, kære læser.

At finde fejl og pege fingre er i virkeligheden nemt, men at rette fejlene og udgive et godt og sikkert produkt hver gang - dét er svært.

Og det vil jeg gerne høre din mening om. Hvordan gør I i din virksomhed' Har ledelsen fokus på sikkerhed'

Kommentarer (15)
sortSortér kommentarer
  • Ældste først
  • Nyeste først
  • Bedste først
#1 Patrick Timm

Jeg arbejdede en periode i en virksomhed, der sælger standard webløsninger tilpasset det enkelte projekt. Her var alle programmører enige om at den gamle kodebase man sad med burde omskrives til noget mere nutidigt - herunder også "nye" sikkerhedsproblemer. Dette er jo et meget godt udgangspunkt for forandring, men der var ganske enkelt ikke penge/tid til at sætte sig ned og gøre det. Dette tror jeg ikke er et unormalt problem, da mange ikke-teknikere har en tendens til at tro, at programmering kun drejer sig om at skrive kendte tegn i mærkelige sekvenser :o)

I denne situation ville der sandsynligvis ikke ske noget før man en dag fik en kunde, der ville bruge tid og ressourcer på at indgå i udviklingen af selve grundsystemet.

  • 0
  • 0
#2 Klaus Agnoletti

Er der jo andet fokus i virkeligheden. Funktionalitet vil altid være i fokus hvis det ikke gøres klart at sikkerhed er noget der skal testes for. Men hvordan gør man det? Kan det overhovedet gøres mindre abstrakt for de kunder der ikke er kompetente nok til at forstå problemstillingen?

  • 0
  • 0
#4 Klaus Agnoletti

Jeg har skam masser af idéer :-)

Næste gang vil jeg fokusere på udviklingsmetoder og de krav der sættes til udviklere, og så håber jeg at flere udviklere vil give deres besyv med og give mig idéer til hvad jeg konkret kan anbefale af brugbare løsninger..

/k

  • 0
  • 0
#5 Henrik Kramselund Jereminsen Blogger

tsk tsk, Klaus du burde altså lige linke til http://www.owasp.org når du skriver sådan et indlæg :-)

Nå men jeg har i min virksomhed forsøgt at lave en vurdering når jeg tager et nyt webprodukt ind, om det er fornuftigt lavet osv. Men det primære er at jeg afvikler det på J2EE platformen, fremfor eksempelvis PHP.

Typisk er J2EE applikationer indlejret i hinanden i flere lag og derfor er det min erfaring at sessionshåndtering osv. er der mere styr på.

Samtidig er det sværere at lave command execution. Husk dog også at andre problemer som SQL injection stadig findes.

Vi ses

  • 0
  • 0
#6 Klaus Agnoletti

Jeg ved det - det kommer i del to. Del et er ikke ment som andet end at ridse problemet op :)

Der kommer også et lille 'øf' om at valg af sprog er ret vigtigt - især er det vigtigt at fravælge sprog, alene fordi det er svært at programmere sikkert i - her er PHP som du nævner, jo ret oplagt at fravælge sammen med c..

Men patience, young skywalker.. der kommer masser af løsningsforslag i næste del af den spiske saga om sikker udvikling her på bloggen.

Til alle : Tak fordi i gider læse det jeg skriver og gør min start her på bloggen rigtig fed !

/k

  • 0
  • 0
#9 Mads N. Vestergaard

Nu siger du at man bør fravælge PHP fordi det er svært at kode sikkert i.

Jeg er på ingen måde enig i at man skal fravælge det af denne grund.

Hvis man ikke gider sætte sig ordentligt ind i tingene, før man programmerer, bør man slet ikke programmere.

Og hvis man ikke gider sætte sig ind i det sikkerheds mæssige i PHP, er det vel en lige så stor risiko at programmere i et andet sporg da man ikke har forstået de grundlæggende sikkerheds principper.

  • 0
  • 0
#11 Klaus Agnoletti

Du har ret i at det er muligt at kode sikkert i PHP, men historien viser desværre at det er meget nemt at gøre usikkert. Jeg vil komme med nogle argumenter for og imod valg af programmeringssprog i næste indlæg. Jeg vil helst ikke ind en diskussion om hvilket sprog der er godt eller skidt - de to eksempler jeg nævnte er som sagt eksempler for eksemplificeringens skyld, og det betyder ikke - i min verden ihvertfald - at man ikke kan kode sikkert i de nævnte sprog.

/k

  • 0
  • 0
#12 Klaus Agnoletti

enig - jeg ville egentligt også have gjort det, men det er lidt besværligt med Version2's artikel system hvis man ikke kender det så godt.. og det gør jeg ikke - endnu :)

Tak for det.

/k

  • 0
  • 0
#14 Daniel Møller

En af de største udfordringer er at holde styr på de mange faldgruber man kan hoppe i. Dette både værende fælder man måske slet ikke er opmærksom på (eksempelvis er XSS huller og SQL Injections noget mange lærer på den hårde måde), men også fælder man reelt har kendskab til kan smutte hvis man glemmer at håndtere dem på den rigtige måde (ingen er jo perfekte).

I et team bliver dette endnu mere afgørende, for det kan godt være de fleste har styr på fleste huller, men hver især kan have områder de ikke har arbejdet så meget med og derfor måske ikke får lavet korrekt input-validering.

Derfor er det reelt et problem hvis hver enkelt udvikler selv skal sidde og holde styr på de forskellige forsvarsteknikker og huske at anvende dem de rette steder. Man kan selvfølgelig fange en del problemer i tests, men er det ens tilgang til det så har man også et problem, for så vil der med stor sandsynlighed slippe huller igennem før eller siden.

Den måde vi bl.a. griber det an på er at understøtte problematikkerne via arkitektur, frameworks og flere sikkerhedslag. Så vidt muligt forsøger vi altså at løse en problematik en gang for alle, så folk ikke skal sidde og tænke over eksempelvis XSS huller og SQL injections. Ligeledes arbejder vi med en lagdelt arkitektur hvor al input-validering sker ved udførelse af use cases. Det er OK at implementere yderligere validering højere oppe i systemet også, men som minimum skal der ske en afskærmning på Business Logic niveau. Vi betragter altså vores Business Logic lag lidt som en SOA-applikation, hvor alt der vil tilgå denne reelt betragtes som værende usikkert og pre-conditions er grundlæggende set banlyst. Man kan altså lidt sige at vores website fra Business Logicens synspunkt betragtes som en usikker klient. På mange måder handler det om at forsøge at løse problemerne ved hjælp af tekniske løsninger og på den måde mindske den menneskelige fejlmargin.

Et basalt eksempel på hvordan man kan understøtte sikkerheden teknisk er jo eksempelvis i forhold til SQL injections som man langt hen ad vejen kan undgå ved at sørge for altid at benytte parameteriserede queries - ønsker man yderligere at understøtte dette sørger man for at sikre sit dataaccess lag så det slet ikke kan lade sig gøre at indsætte data på anden vis (til særtilfælde kan man så lave en attribute eller lign. der specificerer at man ved hvad man laver og ønsker adgang til at udføre "unsafe" queries).

Well, det var sådan lidt overordnet om emnet set fra min vinkel - synes det er et ganske relevant emne at tage op og håber at der er flere der til dele lidt ud om hvordan de i deres udviklingsafdelinger håndterer disse udfordringer :-)

  • 0
  • 0
#15 Klaus Agnoletti

Lige præcis. En af de ting jeg vil skrive om senere er brugen af metodikker og kodestandarder som f.eks. OWASP - netop for at hver programmør ikke skal sidde og kode den dybe tallerken hver gang..

Tak for dit input - jeg glæder mig til at høre mere fra dig i de senere indlæg..

/k

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