November 2003 - Fra StayInTouch™ - Fort Consults elektroniske sikkerhedsnyheder   Af Ulf Munkedal, direktør og grundlægger af Fort Consult Web-servere er i deres natur komplekse og meget åbne mod nettet. Derfor er der mange aspekter, man skal være opmærksomme på som web-udviklere og web-mastere for at opretholde en høj sikkerhed. I denne artikel ser jeg nærmere på, hvad man bør være specielt opmærksom på og kan gøre ved sikkerhed på web-servere. Især med hensyn til programmering af selve siderne. De seneste måneder er mange danske web sites blevet hacket - eller "defaced" som det hedder på nudansk. Der er en stigende tendens fra hackere til at ville markere sig ved at sætte deres mærke eller aflevere budskaber på hjemmesider. Samtidig baserer flere og flere virksomheder en stigende del af deres kundeservice og omsætning på netop web-services. Derfor er der naturligvis et øget behov for at sikre web-servere.   Web-servere er dobbelt så usikre Lige siden jeg startede med at teste IT-sikkerhed i Neupart & Munkedal tilbage i 1997, er web-systemer den kategori af udstyr, som vi har fundet langt de fleste sårbarheder på. I gennemsnit cirka dobbelt så mange sårbarheder som på andre systemer. Hvorfor? Fordi, web-servere er komplekse samtidig med at de i sagens natur skal være meget åbne mod nettet for at fungere.   Sikkerhedsfejl i web-programmering Det er min erfaring, at programmeringsfejl i web-koden er det sværeste at sikre sig imod. Hele problemstillingen er som udgangspunkt også vanskelig at forstå, hvis ikke man lige selv er programmør. Men hvis vi skal web-sårbarhederne ordentligt til livs, bliver vi nødt til proaktivt at tage fat ved nældens rod, nemlig i selve programmeringen. Jeg vil derfor gennemgå en række af de mest almindelige af programmeringsfejl inkl. hvad man kan gøre for at undgå dem.   Buffer overflow En buffer overflow finder sted, når et program eller en proces gemmer flere data, end der er reserveret plads til f.eks. på stakken. Andre data bliver derved overskrevet, f.eks. returadressen i en subrutine, hvilket kan betyde, at instruktionspointeren kommer til at pege et helt forkert sted hen - måske på ondsindet kode, som er konstrueret til formålet. Hvis ikke programmet er skrevet således, at overskydende data faktisk kan håndteres, ja, så opstår der mulighed for buffer overflow. Konsekvenserne er nedbrud, adgang til data eller udførsel af kommandoer. Buffer overflows er den mest hyppigt forekommende sårbarhedstype generelt og er typisk ret alvorlige. De kan forekomme i alle programmer, applikationer og operativ-systemer, hvor der ikke er taget højde for problemet i kildekoden. Løsningen er inputvalidering. Kopier ikke noget web-input ind i de variable, du bruger i dit program, uden at du har 100% styr på mængden af data, du kopierer! I C og C++ gør en strncpy fx underværker i stedet for en strcpy.   Session-håndtering Session-håndtering på web-servere klares typisk via cookies, som er en lille stump information, som bliver gemt på web-surferens harddisk. En cookie kan fx bruges til at opretholde en autentificeret session med en bruger uden at bede om brugernavn/password hele tiden. En session ID kan også være skrevet i en URL, og her gælder samme forholdsregler som ved cookies (fx i følgende URL: http://lw11fd.law11.hotmail.msn.com/cgi-bin/hmhome?curmbox?F000000001&a=b867164aa4b15cadc4749ae74fd590b5&fti=yes&_lang=EN hvor IDen er markeret.   Skjul din kode Error- og debug-information kan være nyttigt under udviklingsforløbet, men det bør ikke findes på en web-server i drift. Versionsnumre, systemnavne, database-detaljer, source-kode er eksempler på informationer, som man ikke bør dele med en evt. angriber. Sikkerhedsmæssigt kan man med fordel selv fange evt. fejlkoder og fremvise en hjemmelavet fejlbesked, som ikke giver en angriber nyttige informationer. Visse sprog fx Java er nemme at lave reverse-engineering på. Det vil sige, at en eksekverbar fil "tilbagekompileres" således, at den oprindelige source-kode er helt eller delvist synlig. Løsninger til dette er at sørge for, at debug-informationer er fjernet i den kompilerede kode og helt at fjerne fortrolige informationer fra source-koden, så de ikke kan findes med reverse-engineering.   Code reviews anbefales Alle laver programmeringsfejl uanset hvor dygtige de er. Derfor er det en god idé at foretage et sikkerhedstjek af kodningen, såkaldte code reviews, inden man går i produktion med hjemmesiden. Koden skal simpelthen kigges igennem for sikkerhedsbøffer. Code review bør foretages af en tredje part, som ikke har været med til at skrive koden - fx en kollega eller ekstern samarbejdspartner.   De 4 store web-problemområder De vigtigste web-relaterede sikkerhedsproblemer er: Programmeringsfejl Udviklerne har ikke skrevet koden til web-serveren sikkerhedsmæssigt forsvarligt. Manglende opdateringer De sidste patches og sikringer er ikke lagt på. Der vil blive fundet omkring 4500 nye sårbarheder alene i år og en stor del af disse er desværre web-sårbarheder. Fejlopsætning af operativ-system og web-server-applikationen Der er f.eks. ikke lavet en ordentlig grundlæggende sikkerhedsmæssig "hærdning" af systemet, inden det er sat i produktion. Fejl i netværksdesignet Web-serveren er ikke ordentligt beskyttet i netværket. Der er som bekendt mange andre måder at bryde ind i en maskine på end blot via HTTP-porten   Eksempler på hackede web-sider: http://www.zone-h.org/defacements/onhold I det følgende går jeg i dybden med SQL-injections og input-manipulation på web-servere.   SQL-injections Mange web-udviklere bruger i dag databaser og SQL (Structures Query Language) til dynamisk opbygning af web-sider ved hjælp af database-forespørgsler (Queries). Web-serveren foretager SQL-kald i en database-server for at udtrække og efterfølgende præsentere de ønskede data. Ved at manipulere i de web-inputfelter som anvendes, fx direkte i et SQL-kald, kan en angriber læse følsomme oplysninger, ændre data, foretage ude-af-drift angreb, udføre kommandoer og andre kedelige ting. SQL-injections er de seneste år blevet en meget populær angrebsmetode mod web-servere. Lad os sige, at web-applikationen har kode som dette: SQLQuery = "SELECT Username FROM Users WHERE Username = '" & strUsername & "' AND Password = '" & strPassword & "'" strAuthCheck = GetQueryResult(SQLQuery) If strAuthCheck = "" Then boolAuthenticated = False Else boolAuthenticated = True End If Hvis strUsername and strPassword hentes direkte fra en web-form, vil det i dette eksempel kunne lades sig gøre for en angriber at konstruere noget input, som omgår hele ideen med programmet. Først et eksempel på uskadelig opførsel, hvor brugeren fra en web-form indtaster følgende: Login: Ulf Password: Hemmeligt Det resulterer i SELECT Username FROM Users WHERE Username = 'Ulf' AND Password = 'Hemmeligt' hvilket jo er meget fint. Men hvad så med følgende indtastning: Login: ' OR ''=' Password: ' OR ''=' Som resulterer i SELECT Username FROM Users WHERE Username = '' OR ''='' AND Password = '' OR ''='' hvilket betyder at udtrykket altid er sandt, og at brugeren dermed altid bliver valideret! Ups. Dette er grundprincippet. Og med "SQL Server stored procedures" på en SQL-database bliver det naturligvis endnu mere festligt for angriberen, hvis han kan kalde en kommando via web-server-applikationen f.eks. i stil med ; EXEC+master.dbo.xp_cmdshell(cmd.exe+/c);-- Løsningen er forebyggelse via input-validering i koden - vel at mærke ikke mængden af data (antal tegn), men validering af de data, der er blevet indtastet. Dvs. sørg for at input ikke indeholder "farlige" tegn for web-serveren. Fjern fx "plinger", anførselstegn, semikolon, slash, backslash og andre unødvendige tegn. Det bedste er faktisk at lave en streng positiv-liste med tilladte tegn og droppe alle de tegn, der ikke er med i listen.   Input-manipulation Ved SQL-injection har jeg allerede løftet sløret for, hvordan en angriber arbejder, når han udfører manipulation af input-data. Samme problemstilling gælder også i mange andre tilfælde, når man som udvikler skal behandle bruger-input på web-serveren, fx meta characters. Meta characters er karakterer, som påvirker et programs, operativ-systems eller applikations opførsel. Historisk set har UNIX-baserede web-servere været mest påvirkelige pga. deres shell-funktionaliteter i scripts. Den klassiske Unicode-sårbarhed på IIS er faktisk en fejl i input-valideringen på server-niveau. I følgende eksempel svarer %C0%AF fx til slash (/) i Unicode i det latinske tegnsæt: http://www.fortconsult.net/scripts/..%C0%AF../winnt/system32/cmd.exe?/c+dir+c:\ Som med SQL-injection er det bedste forsvar mod input-manipulation at foretage omfattende og grundig input-validering af alt bruger-input. Fjern alle tegn undtagen de specifikke tegn, som programmet absolut skal acceptere. Når du foretager input-validering, så sørg for, at det altid foregår på web-serveren! Det må ikke ske i HTML koden, java-scripts og. lignende, som afvikles på klienten. En angriber kan blot gemme koden lokalt, fjerne begrænsningen i antal tegn eller typen af tegn, og kalde de samme scripts eller programmer, som den oprindelige kode side gjorde - men denne gang uden begrænsningerne.   Proaktiv sikkerhed At undgå sikkerhedsfejl, allerede når man udvikler sin web-kode, er den mest effektive måde at forbedre web-sikkerheden på. Det resulterer typisk også i en mere proaktiv sikkerhedsmæssig holdning i organisationen, som kan gavne virksomheden på mange andre fronter end blot ved web-udvikling.   Læs mere om SQL-Injections her: http://www.spidynamics.com/papers/SQLInjectionWhitePaper.pdf   Husk sikkerhed lige fra projektstart Når man kaster sig ud i et web-udviklings-projekt bør man fra start tage sikkerhed med i betragtning. Det man investerer i at sikre sin web-server, bør have en klar sammenhæng med den mængde energi, man poster i at få udviklet hjemmesiden. Hvis man f.eks. har brugt 24 mandemåneder på at udvikle virksomhedens web site, så er det ikke nok med 1 uges sikkerhedsfokus til sidst i projektforløbet. Egenudviklet kode er med til at forøge kompleksiteten væsentlig og dermed behovet for fokus på sikkerhed. Tilbage >