Din hemsida och säkerheten

Det finns många aspekter av det här med säkerhet när det gäller hemsidor. En av de vi möter varje dag, och som är av yttersta vikt för den som utvecklar en hemsida att tänka på, är hanteringen av indata. Har man inte koll på sin indata öppnar man enkelt för hemskheter som MySQL Injections och Cross-Site Scripting (XSS).

Hantering av indata – vad innebär det?

Majoriteten av alla hemsidor idag hanterar någon typ av indata. Det kan vara allt från att en besökare fyllt i ett formulär, till att hemsidan självt genererat indata som skall behandlas. Vilken hemsidesmakare har inte behövt hantera indata på nedanstående form någon gång?

http://www.mindoman.se/mail.php?to=john@mindoman.se&subject=Test

Den gyllene regeln till all hantering av indata är att förutsätta att den inte går att lita på. På så sätt är det enkelt att förstå att felhantering utgör den största delen av allt programmeringsarbete.

Varför kan felaktigt indata vara farligt?

Enklast är att illustrera detta med några exempel. Anta att du har en gästbok på din hemsida i vilken dina besökare kan skriva meddelanden. När en besökare fyllt i ett meddelande så visas meddelandet på sidan. Anta vidare att din hemsida inte bearbetar indatat från besökaren och att du lagrar alla meddelanden i en MySQL-databas.

Utan hantering av indata kan besökaren (eller ett skript), medvetet eller omedvetet, ange koder som kan hanteras av antingen servern eller besökarens webbläsare. Exempelvis kan besökaren fylla i HTML-kod i meddelande-rutan och på så vis, åtminstone delvis, designa om din hemsida.

Ett inte lika harmlöst exempel är om besökaren fyller i JavaScript-kod i meddelande-rutan. När din hemsida sedan skall visa besökarens ”meddelande”, så exekverar webbläsaren istället den programkod som fylldes i, med allt vad det kan innebära.

Ett ännu mer potentiellt skadligt exempel är om användaren fyller i SQL-kod i meddelanderutan. Utan hantering av indata kan användaren då eventuellt manipulera data i databasen, få tag i känsligt data, eller till och med helt tömma databasen.

Anta att din hemsida använder följande SQL-sats för att lista alla gästboksinlägg som skrivits av besökaren Alice.

select * from guestbook where name='Alice';

Om hemsidan låter besökaren fylla i valfritt namn att söka efter, skulle besökaren kunna fylla i följande SQL-sats istället för ett ”vanligt” namn:

x'; update guestbook set name='Marvin' where id != '

På detta sätt kommer hemsidan exekvera följande SQL-sats:

select * from guestbook where name='x';
   update guestbook set name='Marvin' where id != '';

… vilket skulle kunna innebära att besökaren helt på egen hand byter ut samtliga namn i databasen till Marvin.

Hur skyddar jag mig då mot detta?

I samtliga ovanstående fall är lösningen att ersätta tecken som kan tolkas av webbläsaren eller servern, med tecken som ej tolkas på särskilt vis. För att göra detta behöver du använda så kallade escape characters.

Om någon fyller i HTML-kod och det skall visas på din hemsida, vill du förstås inte att webbläsaren skall börja tolka besökarens HTML-kod, utan istället visa HTML-koden så som besökaren fyllde i den. Om din besökare fyller i följande kod …

<strong>Fet text</strong>

… bör du konvertera den på följande vis …

<strong>Fet text</strong>

På så sätt visas texten korrekt i din webbläsare. Skall du dessutom lagra detta i en MySQL-databas bör texten konverteras vidare så tecken som har speciell betydelse för MySQL också byts ut.

Allt detta är givetvis ganska komplext, så som tur är innehåller alla moderna skriptspråk funktioner som hjälper dig att hantera detta. Exempelvis hjälper PHP dig med detta genom funktioner som bland annat htmlspecialchars() och mysql_escape_string().

För mer information om säker in- och utdata, besök gärna Wikipedia.

Värt att notera är förstås att felaktig indata även kan orsaka andra typer av problem, som felaktiga index (out of range exceptions) och annat, men det ligger utanför denna artikel.

Trevlig helg!