Resultaterne indikerer, at der er langt igen, før webapplikationer på internettet har den stabilitet og det sikkerhedsniveau, der er nødvendigt for at sikre virksomhederne mod misbrug fra ondsindede brugere på nettet og mod fejl, problemer og utilgængelighed af tjenesterne.

81 prosent af de webapplikationer, som vi har testet, har været sårbare overfor Cross Site Scripting (XSS) angreb. Dette er en svaghed, der giver ondsindede brugere mulighed for f.eks. at "plante" urigtige informationer, som tilsyneladende kommer fra et seriøst websted, "kapre" kommunikationssessioner og herigennem udgive sig for at være andre end de er, samt at få kørt ondsindede programkoder, som kan aflytte, ødelægge og/eller ændre data på tilfældige klientmaskiner. Tendensen for XSS sårbarhed er imidlertid aftagende.

38 prosent af webapplikationerne har været sårbare pga. for lavt opdateringsniveau på platformsoftwaren (versioner/patche-niveau) og dette er en stigende tendens. Dette problem opstår, fordi der stadig bliver fundet nye fejl i softwareprodukter. Antallet sårbarheder der publiceres pr. uge stiger stadig. Producenterne udsender så softwareændringer for at korrigere produkterne. Informationer om fejlene er offentlige, og hvis en virksomhed er for sent ude med at opdatere sine systemer, er det lettere for ondsindede brugere at opnå kontrol over virksomhedens systemer eller hente informationer ud fra disse. Manglende sikkerhedsopdateringer vedrørte sårbarheder som f.eks. "Buffer overflow" (Internet Information Server Webdav / Unicode / Internet Printing Protocol (IPP)) og ISAPI-filtre på Windows - svagheder der kan udnyttes til at give mennesker med uærlige hensigter administratorrettigheder til systemerne eller mulighed for at gennemføre denial-of-service-angreb (DoS). Udfordringerne med opdateringer er som regel størst i større organisationer med en kompleks it-infrastruktur på grund af afhængighederne mellem softwareprodukter og på grund af mere kritiske systemer med en større trafikvolumen.
Patches kommer tilfældigt fordelt over tid - fra forskellige leverandører. Det er arbejds- og tidskrævende at teste nye patches i eget miljø før produktionsfasen. På grund af hastigheden, som nye sårbarheder bliver publiceret med, som beskrevet ovenfor, bliver det vanskeligt at opdatere med nye patches med det samme. Secode har kunder som blandt andet på grund af dette vælger at overvåge forsøg på udnyttelse af sårbarhederne i kritiske systemer (med Intrusion Detection System - IDS) eller spærrer for misbrug med Intrusion Prevention System - IPS.

31 prosent af webapplikationerne har været sårbare for "SQL injection"-angreb. Dette er et resultat af, at udviklere ikke anvender god nok filtrering af inddata fra webklienten til serveren. Dette er en svaghed, der giver ondsindede brugere på nettet mulighed for at sende uautoriserede kommandoer til databaseserveren og læse konfidentielle informationer, som de ikke skal have rettigheder til. De kan også få kørt egne script (dvs. en sekvens af instruktioner) sammen med databaserne. Kørsel af sådanne script kan ulovligt ændre data, fjerne data og hente udvalgte informationer. Tendensen for SQL injection sårbarheder er aftagende.
Desuden har vi i forskellige tests fundet mange eksempler på svagheder som f.eks. validering af inddata udelukkende på klienter, hvor valideringen kan omgås, brugernavn/adgangskode, som sendes ukrypteret over internettet, brugernavn/adgangskode, som ligger ukrypteret hardkodet i script, mangelfulde udlogningsfunktioner, hvor andre brugere kan udnytte kommunikationssessioner efterfølgende, manglende herding af servere og e-mailfunktioner, der kan benyttes til at sprede e-mail med falske afsenderadresser.

Secodes erfaringer fra andre projekter siger, at disse svagheder kunne have været undgået ved bedre specificering af krav til sikkerhed ved opstart af udviklings- og anskaffelsesprojekter, bedre opfølgning af udvikling af software samt bedre verificering/test af løsningen iht. sikkerhedskrav. Tilsvarende vigtigt er det at stille klare krav på forhånd til håndtering af sikkerhed hos leverandører af kundespecifik software, til udviklingsprocessen (etableret kodestandard, oplæring af udviklere, tjeklister for "bedste praksis" og "hvordan man undgår faldgruber") og til driftsleverandører vha. specifikke sikkerhedskrav i tjenesteniveauaftalen (SLA - Service Level Agreement).
Vores erfaring siger, at det er meget lettere og mere omkostningsfrit at specificere og indbygge et korrekt sikkerhedsniveau i applikationen, hvis sikkerhedsspørgsmål tages op fra projektstart. Dette forudsætter, at virksomheden har et bevidst forhold til informationsværdierne, der forvaltes gennem det nye eller ændrede system og beskyttelsesbehovet for disse værdier. Alternativet til dette er ofte ændringer kort tid efter, at applikationen/systemet er gået i produktion - med ekstra tidsforbrug/omkostninger, som resultat og uden synlig stigning i brugerfunktionalitet.

Specificering og opfølgning af sikkerhedskrav for nye webapplikationer er en blandt mange vigtige foranstaltninger. Det er meget vigtigt, at virksomheden iværksætter tilpassede sikkerhedsforanstaltninger - efter en overordnet risiko- og sårbarhedsanalyse - for at opnå kontrol over IT-sikkerheden i hele organisationen. Sådanne sikkerhedstiltag bør alle være forankret i en overordnet sikkerhedspolitik, der er godkendt af virksomhedens ledelse.

Ivar Aasgaard, Seniorkonsulent, Seacode ( www.sikkerhet.no )