De største web-sikkerhedsbrølere

Ved GOTO Copenhagen, der foregår fra d. 21-23. maj i København (ba dum tsch), har Anders Skovsgaard, der driver firmaet Hackavoid, demonstreret hvordan, nogle af de mest alvorlige og udbredte web app-sårbarheder fungerer, samt hvordan man lettest kan sikre sig.

Der var meget, der kom på tale:

Cross-Site Scripting (XSS), hvor man kan misbruge en sides mangel på input-validering til f.eks. at bryde ud af et H1-tag og indsætte vilkårlige scripts, der misbruger den tillid, brugeres browsere har til siden—indlæse falske login-sider, iframes der laver drive-by-downloads, og så videre. Man kan sikre sig ved at "escape" al input, der kommer fra brugere, så de ikke eksempelvis kan indsætte karakteren " i deres navn; eller man kan bruge et template-system, der automatisk escaper input for dig.

SQL Injections, der lader en ondsindet bruger eksekvere vilkårlige SQL-kommandoer på serveren, fordi webapplikationen ikke f.eks. validerer navnet "John'); DROP TABLE users;--" før, det udføres på SQL-serveren. Det kan forhindres ved at bruge parameter binding og prepared statements, to metoder der understøttes af de fleste programmeringssprog og SQL-servere. Med de to metoder adskilles den "rigtige" query og den dynamiske del, så respektive SQL-server eller API ved hvad, der kan indeholde skadeligt input. (Med prepared statements er det i de fleste SQL-servere ikke muligt at gøre andet efter, kommandoen er kompileret, da det forberedte statement kun kan bruges til at udføre et SELECT FROM users WHERE name = ?, hvor ?'et bliver byttet ud med det dynamiske input.

Cross-site Request Forgery (CSRF), hvor man kan misbruge en uskyldig brugers browser til at sende forespørgsler til sider, der tror, forespørgslerne faktisk kommer fra brugeren—altså hvor man misbruger den tillid, en server har til brugerens maskine. Her kan man f.eks. få en brugers browser, der er logget ind på en web-shop, til at købe diverse sager automatisk, og tjene penge via en affiliate-kode. Den mest effektive beskyttelse er, at bruge såkaldte CSRF-tokens i formularer, så man kan afvise forespørgsler med formular-data, der ikke indeholder den rigtige CSRF-token. CSRF-tokenen kan være bundet til brugerens konto eller ip-adresse/user-agent.

(Man kan også kigge på HTTP Referer-headeren, der, hvis der er tale om cross-site request forgery, vil vise et andet domæne end webshoppens. Det kan dog skabe problemer i nogle browsere, der ikke inkluderer headeren—f.eks. skjuler de fleste browsere din Referer når du klikker på et link fra en HTTPS-side.)

Clickjacking, der lader en ondsindet bruger bruge dit click med musen til at aktivere et skjult vindue bag ved f.eks. en videoafspiller. Det kan, som i Anders' eksempel, være en Facebook-"Synes godt om"-knap bag en video-afspiller, der så hurtigt spreder sig til eksponentielt mange uskyldige venner, og måske krydrer det med lidt malware eller phishing.

DNS rebinding, der foregår ved, at man sender et link til at domæne, der ligner det rigtige, f.eks. amazón.com, og peger det (via DNS) mod den rigtige amazon.com-maskine i det første request, men til sin egen maskine i det andet, så man kan samle login-information, m.m.

Miskonfiguration: At man viser for meget information i fejlmeddelelser, viser indholdet af mapper, der ikke har en index.html-fil, ikke holder sit CMS up-to-date, m.m..

Anders havde kun omkring en time, men han lykkedes alligevel vise hvordan de fleste af disse angreb foregår. Det er skræmmende at tænke på, at vi, efter mere end 10 år med det moderne Internet, stadig hører om SQL-injections og defacements hele tiden. Det er næsten hver uge! Og de fleste af de store "hacks", f.eks. den lange stribe hacks af Sony, er slet ikke så sexede som de lyder. Det er simple SQL injections og uddaterede Apache/PHP og IIS/ASP-installationer med let-tilgængelige Metasploit-moduler, der kompromitterer giganterne.

(For langsomme, eller en total mangel på opdateringer af operativsystemer og installerede programmer er i min mening det absolut værste og mest udbredte generelle sikkerhedsproblem. Alle de andre typer sårbarheder—i hvert fald i andres programmer—modtager jo, forhåbentlig, opdateringer, der fjerner hullerne indenfor en rimelig tidsperiode. Opdaterer du ikke, venter du jo bare på, at der er nogen der udnytter en kendt sårbarhed i det, du bruger. Ja, det lyder jo næsten hjernedødt logisk, men en god update management-kultur er desværre stadig noget, mange firmaer mangler—eller også irriterer opdateringerne brugerne så meget, at de slår dem fra.)

For mere læsestof om mange af sårbarhederne ovenfor, og hvad man kan gøre for at forhindre dem, tag et kig på OWASP's Top 10 [PDF] og deres samling af security cheat sheets. Jeg kan også anbefale Douglas Crockford's informative snak, Principles of Security, samt Marc Stiegler's, The Lazy Programmer's Guide to Secure Computing.

Hvis du er interesseret i at finde ud af, om du er sårbar, og ikke har noget imod at få lidt beskidte fingre, kan jeg varmt anbefale en sårbarhedsscanning med Nessus (gratis til personligt brug) og/eller OpenVAS, samt en manuel penetrationstest med Burp Suite, Metasploit og sqlmap (alle gratis).