Inget nytt i den delen, det handlar om hyfsat kända problem som “bara” drabbar den som envisas med att använda Internet Explorer. Det som är intressant och skrämmande är mängden sajter som laddar scriptet för den intet ont anande besökaren.

Bland de drabbade hittar man sajter från FN, flygbolag och ambassader. Resesajter, privata sajter, forum och många andra. Kort sagt, sajter som man besöker utan att ha anledning att tro att de vill skada ens dator. Vid en snabb kontroll igår hittade jag ett helt gäng svenska sajter som drabbats.

Det de här sajterna har gemensamt är att de är databasdrivna. Det innehåll som visas för besökaren finns inte lagrat som HTML-sidor i textfiler utan ligger istället i en databas. Det gör att sajternas “redaktörer” via ett administratörsgränssnitt enkelt kan uppdatera innehållet, lägga till artiklar eller ändra rubriker och texter.

Problemet är att om den illvillige hackern Filip Fjunmustasch lyckas ändra i databasen, så kommer hans ändringar att visas för sajtens besökare. Den snabbtänkte läsaren tycker nu förstås att den som äger sajten borde se till att Filip inte kan ändra i databasen. Det är så sant, men det är inte alla sajtbyggare som har tänkt så långt.

Bombmatta

Veckans angrepp är inte på något sätt riktat mot specfika sajter. Det är en bombmatta som lagts ut, praktiskt taget varenda sajt i världen har blivit utsatt för ett intrångsförsök men bara de sajter som varit sårbara har drabbats. Nu är det förstås inte fråga om en miljon kineser som manuellt suttit och besökt alla sajter i världen utan en programvara som systematiskt bearbetat alla sajter.

Den teknik som använts kallas SQL Injection och innebär att man som besökare på en websajt tillåts skicka ett SQL-kommando till sajten som glatt skickar det vidare till databasen utan att fundera över om det är klokt eller inte.

I de fall angreppet lyckats har javascript-kod lagts in i databasen och därmed visats för besökarna. De besökare som använt Internet Explorer har hämtat hem scriptet och i alltför många fall drabbats av elak kod som installerats i deras dator.

När jag skriver detta ser det ut att vara mer än 700 000 sajter som drabbats (en enkel google-sökning visar ett ungefärligt antal). Många systemadministratörer och webmasters torde ha slitit sitt hår de senaste dygnen. Hur många användare som fått sina datorer infekterade för att de besökt någon av dessa sajter vill jag inte ens tänka på.

Vad kan man då lära sig av detta?

Som användare kan du se till att inte använda en trasig webläsare. Oavsett vilken du föredrar ska du se till att den är uppdaterad, även en version som bara är några månader gammal kan innehålla säkerhetshål som Filip och hans kompisar redan hittat. Ett uppdaterat virusskydd hjälper också.

Om du varit med om att bygga någon av de drabbade sajterna så kanske du borde överväga att byta yrke. Eller om du trivs med det du gör, se till att lära dig allt du behöver för att göra ett bra jobb. Ta ansvar för vad du levererar.

(IDG har också rapporterat nu: här och här)

Cross site scripting innebär att man lurar en vanligtvis pålitlig sajt att visa ett script för besökaren.

Ett exempel

Säg att jag besöker Facebook och hittar en sida eller funktion som är öppen för mina onda avsikter. Det kan finnas ett fält som jag som användare kan fylla i själv och vars innehåll visas för alla besökare till min Facebookprofil. Men istället för att ange de uppgifter som fältet är till för, så lägger jag in ett litet javascript som i sin tur laddar ett större script från en sajt jag har tillgång till.

När du senare besöker min sida kommer din webbläsare att ladda scriptet och köra den programkod som det innehåller. Beroende på vad jag förberett för elakheter och vilka säkerhetshål i din webbläsare mitt script kan upptäcka kan praktiskt taget vad som helst hända. Utan att du märker något kan scriptet installera program i din dator, radera filer eller sända dina privata filer till en server på nätet.

Osannolikt? Tyvärr inte. Facebook är kanske inte ett väl valt exempel, den är hyfsat säker mot cross site injection men ett par säkerhetshål upptäcktes där för bara några dagar sedan. Du besöker säkert många andra sajter och forum där besökare själva kan lägga in information och då finns en stor risk att exemplet blir verklighet.

Hur skyddar man sig?

Det enda du som användare kan göra för att skydda dig är att använda en modern webbläsare som uppdateras så snart något säkerhetsproblem blir känt (helst ska den förstås uppdateras innan hålet blir känt…). Du kan också stänga av scripthantering i din webbläsare, men det är inte ett särskilt praktiskt alternativ eftersom de flesta sajter helt enkelt inte fungerar då.

Hur skyddar jag användare på min egen sajt?

Om du själv bygger webbsajter så finns det en del att tänka på för att dina användare ska slippa bli utsatta för den här typen av problem.

Grundprincipen är att aldrig presentera information som användarna har matat in utan att först tvätta den ordentligt. För att bli av med giltiga html-taggar typ <script> kan man konvertera ‘<’ och ‘>’ till “&lt;” och “&gt;”. När webbläsaren presenterar detta kommer det att skrivas ut istället för att tolkas som en giltig html-tagg.

Exemplen nedan är inte på något sätt heltäckande, men det viktiga är att du förstår principen. Varje gång du presenterar information som en användare har lagt in måste du vara medveten om riskerna med cross site injection. Det “rätta” sättet att skydda dina användare kan variera med funktionerna på din sajt.

Om du använder PHP

I PHP finns några standardfunktioner som gör mesta av jobbet åt dig, men du måste förstås se till att använda dem. htmlspecialchars() och htmlentities() konverterar alla specialtecken i HTML, tex ‘<’ till “&lt;”. strip_tags() tar bort alla html-taggar ur strängen utom de man uttryckligen sagt är tillåtna. (funktionsnamnen här är länkade till php-dokumentationen)

Studera php-dokumentationen för att lära dig skillnaderna, men i de flesta fall klarar du dig bra med htmlspecialchars(). Använd den när du ska skriva ut data som användare har lagt in. T ex:

$stringFromTheUser = "<script>alert('elakt script');</script>";
echo htmlspecialchars($stringFromTheUser);


Om du använder ASP.NET

ASP.NET har ett inbyggt skydd mot olämplig inmatning, men du kan inte förlita dig enbart på det. Det kan också finnas tillfällen när du behöver stänga av det, beroende på vilken sorts information du faktiskt tillåter att användaren lägger in.

För att vara säker på att du har det inbyggda skyddet aktiverat, se till att du har attributet validateRequest satt till true i sidan:

<%@ Page validateRequest="true" %>


När du skriver ut information som en användare lagt in, använd HttpUtility.HtmlEncode() för att konvertera alla specialtecken:

string stringFromTheUser = "<script>alert('elakt script');</script>";
response.write HttpUtility.HtmlEncode(stringFromTheUser);


Läs även den här artikeln på MSDN, men ta tipsen om att använda unika funktioner i Internet Explorer med en nypa sajt. Även om de i vissa fall går att använda som både hängslen och livrem kan du inte basera säkerheten på att användaren ska använda en viss webbläsare.

Men, verktyg och hjälpmedel gör inte automatiskt användaren till expert. Om jag tvättar mina vita T-shirts tillsammans med de röda julgardinerna blir resultatet antagligen inte vad jag hade tänkt mig.

Samma sak gäller utvecklingsverktyg. När jag började programmera fanns inte många hjälpmedel och inga färdiga bibliotek med rutiner att använda. För att hantera data på disk så fick man lära sig hur man gjorde ett index för att snabbt kunna leta upp det man ville hämta. Sånt slipper man idag, eftersom det finns databasmotorer som går att komma igång med utan alltför lång lärotid.

Problemet är att om man inte har en hyfsad förståelse för hur databasen fungerar invändigt kommer man så småningom att få problem. Applikationen som fungerade så bra när utvecklaren testade den med sina 10 poster blir outhärdligt slö i den riktiga miljön där det finns tusentals rader i tabellerna och det visar sig att man inte tänkt på att lägga till några index i databasen.

Integrerade utvecklingsmiljöer

Microsoft Visual Studio är ett exempel på integrerad miljö som gör det möjligt att snabbt skapa en applikation. Rätt använd är det en riktigt trevlig miljö att arbeta i.

Det inbyggda problemet med såna här verktyg är att det kan vara FÖR lätt att bygga en applikation. Dra och släpp några färdiga komponenter och du har en applikation som pratar med en databas.

För att göra en BRA applikation måste man fortfarande ha kunskaper och erfarenhet. För att göra en säker applikation, särskilt om vi pratar web, måste man veta vad man gör. Mer om det någon annan dag…

Bra verktyg skapar helt enkelt inte en bra hantverkare.