Denne artikel stammer fra det trykte Computerworlds arkiv. Artiklen blev publiceret den CTO d. 3. marts 2006.
Webudviklere bør tænke sikkerhed ind allerede fra begyndelsen af et udviklingsprojekt.
De seneste ugers hacking af danske websider som følge af striden om Jyllands-Postens 12 Muhammed-tegninger har sat spot på sikkerheden for webapplikationer. Sikkerhedseksperter anbefaler, at virksomheder ser sikkerheden for webapplikationer efter i sømmene.
Der er to ting, der er vigtige rent sikkerhedsmæssigt for webapplikationer: Produktionsmiljøets sikkerhed og selve webapplikationens sikkerhed.
Produktionsmiljøets kan sikres ved at sørge for at infrastruktursikkerheden er i orden. Det kræver at firewalls, gateways, applikationsservere og webservere er velkonfigurerede og sikre. Desuden skal jævnlig patchning af styresystemer og andet software være en selvfølgelig i produktionsmiljøet. De seneste angreb mod danske webdomæner har vist, at sikkerheden på nogle webhoteller ikke er god nok.
- Problemet som Muhammed-hackningerne belyser er, at priserne på webhoteller efterhånden er kommet så langt ned, at nogle af dem (webhotellerne, red.) formentlig er begyndt at skære ned på sikkerheden, mener Preben Andersen fra DK-Cert.
Han opfordrer til, at kunderne spørger webhotellerne, hvad de gør for at minimere risikoen ved et eventuelt angreb.
Sikkerheden i selve webapplikationen skal også være i orden.
En Gartner-undersøgelse viser eksempelvis, at 75 procent af alle angreb sker ved at udnytte sårbarheder i applikationerne.
Det er noget man nikker genkendende til hos webudviklingsfirmaet Adapt. Her siger udviklingschef Tommy Davis:
- De fleste sikkerhedshuller findes i selve applikationen. Det er klart det alvorligste problem.
Derfor har Adapt altid fokuseret på at indbygge sikkerhed i sine webapplikationer. Med kunder som Skat, PBS og Ikea har Adapt nogle højprofilkunder, der ville miste troværdighed og image, såfremt deres webapplikationer blev hacket.
Firmaet anvender egenudviklede, automatiske værktøjer, der eksempelvis tester, hvordan applikationer reagerer på forskellige parametre i URL'en.
- Vi bruger det til at checke, om der er nogle returkoder, der kan misbruges, siger Tommy Davis.
Returkoderne kan afsløre, hvilket styresystem, applikationsserver eller database, som applikationen anvender. Altsammen oplysninger som en hacker kan bruge til at forsøge at få adgang til applikationen.
Man kan vælge at udvikle sine egne testværktøjer som Adapt, men der findes også kommercielt tilgængelige produkter. Eksempelvis Devpartner Securitychecker 2.0 fra Compuware, der er rettet mod at finde sårbarheder i ASP.net-applikationer.
Tommy Davis understreger, at værktøjerne kun er et supplement til en egentlig sikkerhedsorienteret tilgang til webudviklingsprocessen.
- Det handler ikke så meget om værktøjer som om selve udviklingsmetoden. Testværktøjerne fanger kun de trivielle ting. Under selve udviklingen skal man prøve at tænke: Hvordan vil jeg kunne bryde ind i det her system, siger Tommy Davis.
- Hvis det skal fungere ordentligt, skal sikkerheden ikke smides på senere. Det er ret dyrt at gøre det til sidst, så derfor skal det tidligt ind i udviklingsprocessen. Udviklerne skal undervises i sikkerhed, de skal tænke anderledes, siger Tommy Davis.
Konkret handler det seksempelvis om at lave reviews af koden. Ved sikkerhedsreview bør man fokusere på, hvad der kan gå galt i koden og hvilke følger det kan få. Det gælder om at identificere eventuelle sårbarheder i koden. Men det er ikke kun den aktive kode, man bør kigge efter.
- Det er vigtigt at checke source-koden for kommentarer. Kommentarer kan give en hacker en ide om, hvor det kan være interessant at bore, siger Tommy Davis.
Problemer med sikkerhed kan opstå, når interne systemer bliver web-enablede.
- Når interne applikationer som mainframe eller lignende bliver web-enablede, befinder de sig pludseligt i et andet miljø. De gamle systemer er ikke forberedt på det trusselsbillede, der er i dag, siger Tommy Davis.
Han mener ikke, at man skal forlade sig på javascript til validering i sikkerhedsmæssigt øjemed, da brugeren blot kan slå det fra i browseren. Javascript er velegnet til at give feedback til brugeren, men ikke til sikkerhed.
- Foretag validering på webserveren. Der skal være en streng validering af data inden de overføres til de interne systemer. En valideringsregel kunne måske være, at et navn ikke må indholde anførselstegn, siger Tommy Davis.
Ved at udelukke anførselstegn kan man undgå, at et skadeligt SQL-statement smugles ind i databasen.
Tommy Davis understreger, at det er alt input, der skal valideres; også URL'en.
- Input er både felter i en formular og parametre til URL'en. Ofte glemmer man at checke URL'en.
Den bliver nemlig ofte genereret automatisk, så derfor tænker man måske ikke over at checke den, siger Tommy Davis.
Ifølge Tommy Davis kan hackere finde mange spændende ting ved at ændre på parametrene i en URL.
- Eksempelvis kan gamle oplysninger eller testdata, som man troede var taget off-line, pludselig risikere at dukke frem igen, hvis man ændrer lidt på URL-parametrene, siger Tommy Davis.
Billedtekst:
Før en tyrkisk hacker tog fat på denne webside, handlede den om biler.
