A.7 Slutsatser
C.5.4 Förhindrande av XSS
XSS-attacker är svåra att förhindra eftersom det finns många sätt en XSS-attack kan ske på [54]. Det finns därför inget standardsätt för en utvecklare att förhindra en XSS-attack. Därför är det viktigt att använda sig av en blandning av kodgranskning och testning under både utveckling och underhåll samt följa de kända programmeringspraxis som hjälper till att skapa en säker webbsida.
För att i grunden försöka förhindra XSS-attacker måste webbsidan först och främst separera det egna innehållet från externt innehåll som kommer från användaren eftersom externt innehåll inte går att lita på helt och hållet [54]. Efter att ha separerat på internt och externt innehåll måste det externa innehållet behandlas så att det inte kan tolkas som kod.
Teorin är att alltid förvänta sig att externt innehåll är otillförlitlig och skadlig data [54]. Allting som ursprungligen inte kommer från systemet och som systemet inte har full kontroll över riskerar att vara skadlig. Detta kan exempelvis vara formulärdata, inmatningssträngar, webb- kakor och begäran från andra system.
Trots att XSS-attacker är svåra att förhindra finns det några generella och grundläggande metoder som täcker och förhindrar en stor del av alla XSS-attacker [55]. Först och främst bör utvecklaren använda sig av HTML-kodade tecken (eng. HTML escape) för att representera- alla tecken som användaren kan mata in. Att använda sig av HTML-kodade tecken innebär att vissa specialtecken som tas emot av användaren inte ska tolkas på ett skadligt sätt [56]. Tecken som främst bör kodas om eller inte tillåtas att matas in överhuvudtaget är de tecken som används i kodsammanhang. Några av dessa tecken är &, <, >, ", ’ och /. I huvudsak censureras data som webbsidan tar emot genom att koda om inmatningstecken till specialtecken.
Utvecklaren bör som regel aldrig sätta icke-kodad inmatningsdata i programmeringstaggar som exempelvis <script>, HTML-kommentarer, <div> och webbadresser med <a> [54]. Utvecklaren bör heller inte låta icke-kodade inmatningsdata finnas i någon attribut för en tagg eller inom en attribut för CSS-kod.
För att skydda sig mot XSS-attacker kan utvecklaren även tillåta en viss inmatning från användaren och validera dessa [55]. Tillåtelse och validering av inmatning används ofta som ett skydd mot SQL-injektioner, men kan även användas som ett skydd mot XSS. Det är bättre att begränsa vad som går att mata in och använda sig av en så kallad whitelist än att förbjuda en viss inmatning och därmed använda sig av en så kallad blacklist. För att kunna använda sig av en blacklist behöver utvecklaren förbjuda allt skadligt som kan matas in, vilket är mycket svårare än att bara tillåta en viss inmatning som systemet har designats för.
Att validera inmatning är speciellt användbart för att förhindra XSS-attacker i formulär eftersom det hindrar en användare från att lägga till specialtecken i fälten [55]. Däremot är validering av inmatning inte en primär och heltäckande metod för att förebygga XSS-attacker, utan ska ses som en liten del av att göra systemet mer säker.
Ett annat sätt för att göra ett webbsystem mer säker mot en XSS-attack är genom att sanitera (rensa) användarinmatning [55]. Saniteringsprocessen inspekterar otillförlitlig data och gör om den så den blir säker att läggas in i användares DOM. Sanitering är ett starkt försvar
C.6. Diskussion
andra. Sanitering av användarinmatning är speciellt användarbar på webbsidor där extern och otillförlitlig inmatning kan innehålla kod. Metoden säkerställer att den mottagna datan inte skadar andra användare och systemet genom att modifiera inmatningen och ändra den till ett tillåtet format. Saniteringen beror även på kontexten, ett värde som är helt ofarligt i CSS kan vara farligt i en webbadress.
Det som bör noteras är att webbsidan och dess kod ursprungligen kommer från webbservern och det är utvecklarens ansvar att göra webbsidan säker mot XSS-attacker oavsett attacktyp [57]. Det vill säga, även om det rör sig om en DOM-baserad XSS-attack och attacken endast sker på klientsidan bör utvecklaren fortfarande sträva mot att förhindra attacken.
För att skydda sig mot DOM-baserade XSS-attacker där servern aldrig tar emot den skadliga inmatningen måste hantering och kontroll av inmatning göras på klientsidan [57]. Detta görs oftast med hjälp av JavaScript. Moderna webbläsare har redan till en viss del inbyggd funktionalitet för att detektera sådana attacker. Dessa är dock långt från heltäckande och många gånger lyckas den som attackerar komma runt dessa skydd.
Ett annat möjligt skydd som en utvecklare kan ge sina användare är att binda deras sessioner och användarkakor till deras IP-adresser [58]. På så sätt, om en XSS-attack skulle ske och den som attackerar kommer över användarens sessioner och webbkakor, blir det svårare att använda dessa. Detta är dock någonting som inte används i stor utsträckning eftersom det finns några nackdelar med det. Först och främst kan det finnas flera användare som använder samma IP-adress på grund av en proxyserver. En användare kan även ha olika IP-adresser under en och samma session, det vill säga om användaren byter nätverk men använder samma enhet. En attackerare kan dessutom ansluta sig till webbservern från samma IP-adress genom att exempelvis göra attacken från användarens dator eller helt enkelt befinna sig inom samma nätverk.
Ramverket Angular har ett inbyggt skydd mot XSS-attacker [59]. För att motverka XSS- attacker behandlar Angular normalt all extern data som otillförlitlig. Angular definierar tre säkerhetskontexter där alla tre saniterar användarinmatningen. Dessa är HTML, CSS samt webbadresser. När ett värde läggs in i webbläsarens DOM sker sanitering och omkodning av inmatningen. I Angular behandlas HTML-filerna för varje komponent som exekverbar kod och tillförlitlig kod. Kod, attributer och tilldelningar behandlas som säkra, medan värdena som blivit tilldelade behandlas som otillförlitliga. Det innebär alltså att en utvecklare måste se till att en användarinmatning aldrig utgör källkoden i HTML-filerna. Om detta görs, genom exempelvis att HTML-filer genereras genom konkatenering med användarinmatning, riskerar webbsidan vara sårbar.
C.6
Diskussion
När det gäller reflekterad XSS finns inga uppenbara sårbarheter i SecTrack. Det finns ett inmatningsfält för varje tabell som skulle kunna utgöra en säkerhetsrisk, men användar- inmatningen för filtreringen skrivs aldrig ut på webbsidan. Filtreringen sker på klientsidan och där kan inte ny information läggas till, utan funktionen begränsar endast visningen av informationen som redan finns på webbsidan. SecTrack anses alltså inom det området inte vara sårbar för reflekterade XSS-attacker och därför behövs inga extra åtgärder tas för att skyddas mot sådana attacker.
C.7. Slutsatser
Att skydda SecTrack mot sparade XSS-attacker är mer aktuellt då hela produkten går ut på att spara information i en databas som senare visas vid en annan session eller för andra användare. Att separera internt innehåll mot användarinmatning, som är externt innehåll, är inte svårt att göra i SecTrack. All användarinmatning som sparas sker genom inmatningsfält när användaren vill lägga till ny information, ändra information eller kvittera ett kort eller en handling.
Tillåtelse och validering av en viss inmatning på ett fält kan i SecTrack hjälpa till att skydda mot XSS-attacker. I SecTrack är detta redan implementerat då kontroller görs på varje inmatningsfält. Exempelvis används en whitelist på korttyp respektive dokumenttyp. Dessa typer är definierade i databasen och i dessa fält kan endast de definierade typerna fyllas i. Ett annat exempel där tillåtning av viss inmatning görs är alla datum. I SecTrack har ett kort ett utgångsdatum, en handling har ett inkommet datum samt ett daterat datum och en leverans har ett skickat datum och ett daterat datum. I alla dessa fälten görs en kontroll av datumet och dess format. Är detta inte korrekt går det inte att skapa eller modifiera en handling, leverans eller ett kort.
För de fälten som är fritext kan SecTrack istället förbjuda en viss inmatning. Sådana inmatningar kan vara special tecken som &, <, >, ", ’ och /. Eftersom kunden specificerat att de inte kommer att använda sig av specialtecken begränsas inte produktens användnings- område.
Att sanitera användarinmatningen hjälper till att motverka XSS-attacker. Eftersom SecTrack är uppbyggd av ramverket Angular sker sanitering av extern data redan automatiskt. I SecTrack genereras heller inga källkod baserad på användarinmatning, vilket bibehåller skyddet som Angular ger.
I SecTrack görs kontroll och sanitering av användarinmatning redan på klientsidan. Dess- utom använder SecTrack sig inte av några fragment identifierare. Det innebär alltså att inga fler åtgärder behöver tas för att skydda SecTrack mot DOM-baserade XSS-attacker.
Eftersom SecTrack endast kommer att användas internt hos kunden går det lätt att begränsa användarinloggningen. Exempelvis kan ett specifikt användarkonto vara kopplat till en dator med en specifik MAC-adress. På så sätt binds kontot till datorn och om någon annan kommer åt inloggningsinformationen kan de inte logga in utan åtkomst till den specifika datorn. Det här eliminerar i princip obehörig åtkomst till ett användarkonto om den obehörige inte har tillgång till användarens dator. Detta är ett väldigt starkt skydd och ger naturligtvis användarbegränsningar. Kontoinnehavaren kan exempelvis inte logga in från vilken dator som helst och kontot måste konfigureras om varje gång ägaren byter dator.
C.7
Slutsatser
Det finns alltså tre huvudkategorier som XSS-attacker kan delas in i. Den första, reflekterad XSS, är den vanligast förekommande attacken och sker då skadlig kod inkluderas vid en begäran till webbservern. Här sparas den skadliga koden inte sparas ner på webbservern. Det skiljer sig från den andra kategorin av XSS-attack som kallas för sparad XSS. Sparad XSS är den typen av XSS-attack som kan orsaka mest skada då den skadliga koden sparas ner på webbservern och kan därför nå ut till flest användare. Den tredje kategorin av XSS- attacker heter DOM-baserad XSS. Utmärkande för DOM-baserad XSS är att attacken sker lokalt i användarens DOM. Ingen begäran skickas eller sparas på webbservern och därför blir det svårare för utvecklaren att vidta åtgärder.
C.7. Slutsatser
Det finns flera små grundläggande metoder och åtgärder att vidta för att skydda sig mot XSS-attacker. Grunden bygger på att separera internt innehåll, som är pålitlig, mot externt innehåll, som kommer från användarinmatning och kan vara opålitlig. Därefter måste- det externa innehållet förväntas vara skadligt och inte tolkas som kod. De tre grund- läggande åtgärder som kan vidtas är att använda sig av HTML-kodande tecken, tillåta och validera användarinmatning samt sanitera användarinmatning. Att använda sig av HTML- kodande tecken innebär att vissa specialtecken inte ska tolkas på ett skadligt sätt. Att tillåta och validera användarinmatningen kan hindra en användare att exempelvis använda ett formulär på ett felaktigt sätt och fylla i med felaktiga format. Den tredje åtgärden, sanitering av användarinmatning, innebär att den mottagna användarinmatningen modifieras och ändras till ett tillåtet och icke-skadligt format.
Eftersom det inte finns några uppenbara sårbarheter i SecTrack när det gäller reflekterade XSS-attacker behöver inget skydd mot detta implementeras. När det gäller sparade XSS- attacker kan alla tre grundläggande åtgärder tillämpas. Först och främst kan SecTrack kan tillämpa HTML-kodade tecken och koda de specialtecken som behövs. Därefter kan tillåtelse och validering av användarinmatning användas för att exempelvis förbjuda vissa tecken, kräva en viss inmatning eller kräva inmatning på ett speciellt format. Sanitering av användarinmatning kan också göras, men detta görs detta redan av ramverket Angular som SecTrack använder sig av, vilket innebär att ingen ytterligare utveckling behöver göras kring saniteringen. För att få ett ytterligare skydd kan ett användarkonto knytas till en specifik dator och MAC-adress, vilket innebär att det blir svårare för en obehörig att logga in med ett viss användarkonto. När det gäller DOM-baserade XSS-attacker behöver inga ytterligare skydd implementeras eftersom kontroll och sanitering av inmatning redan sker på klient- sidan.
D
Sårbarhet mot SQL-injektioner i
en webbapplikation av Jennifer
Lindgren
D.1
Inledning
SQL-injektioner (eng. SQL injections) sker då en användare utnyttjar indatahanteringen i ett program för att få tillgång till eller manipulera data i en databas. Sårbarhet för sådana opera- tioner kan medföra stora konsekvenser för företag som lagrar känslig information i databaser. I den här redogörelsen tas de vanligaste anledningarna till sårbarhet upp samt hur utvecklare kan minimera den.
Alla datadrivna applikationer kan utsättas för SQL-injektioner men den vanligaste mål- tavlan är webbapplikationer [60]. Det finns verktyg som automatiskt kan detektera om en applikation är sårbar mot SQL-injektioner och utföra attacker mot den. En lyckad attack kan innebära att data extraheras, ändras eller till och med förstörs. Främst utförs attackerna för att ge någon typ av finansiell vinning. Till exempel kan det vara personuppgifter som stjäls för att användas till att stjäla någons identitet.
D.1.1
Syfte
Syftet med det här bidraget är att redogöra hur SQL-injektioner kan utföras mot en webb- applikation och vad utvecklare kan göra för att förhindra dem. Genom denna redogörelse sprids viktig kunskap kring ämnet till författarna och läsarna av denna kandidatrapport. I sin tur kan den kunskapen användas för att skydda webbapplikationer och tillhörande databaser mot SQL-injektioner i framtiden.
D.1.2
Frågeställningar
Frågeställningarna som denna redogörelse ämnar att besvara är följande:
1. Vad gör en webbapplikation sårbar mot SQL-injektioner?
2. Finns det någon säkerhetsbrist i SecTrack som gör att dess databas är sårbar mot SQL- injektioner?
3. Vad kan utvecklare göra för att minska risken för att en webbapplikation utsätts för SQL-injektioner?
D.2. Bakgrund
D.1.3
Avgränsningar
Alla datadrivna applikationer kan utsättas för SQL-injektioner men den här redogörelsen behandlar endast sårbarheten hos webbapplikationer.
Reglerna för hur SQL-kod ska skrivas, den så kallade syntaxen, i olika databasmjukvaror kan variera något. Därför antas för enkelhetens skull att MariaDB är databasmjukvaran som används i webbapplikationerna i denna redogörelse, eftersom det är mjukvaran som används i SecTrack.
Arkitekturen hos en webbapplikation kan variera. SecTrack är en så kallad three-tier application vilket innebär att den består av tre lager, se figur D.1. Det översta lagret är presentationslagret, det som användaren ser och interagerar med [61]. Det andra lag- ret är serverlagret och det lager som presentationslagret kommunicerar med. Serverlagret kommunicerar i sin tur med ett tredje lager, datalagret, som består av databasen. I den här redogörelsen antas webbapplikationen ha denna arkitektur där presentationslagret alltså inte kommunicerar med datalagret direkt.
Presentationslager
Serverlager
Datalager
Figur D.1: SecTracks arkitektur.
D.2
Bakgrund
Denna redogörelse kring SQL-injektioner görs i samband med kandidatprojektskursen TDDD96 som läses vid Linköpings universitet. Redogörelsen är relaterad till projektet i och med att SecTrack levererades med en databas som potentiellt skulle kunna utsättas för SQL- injektioner.
D.3
Teori
Det här avsnittet beskriver hur data i databaser hanteras. Se även kapitel 3.5 om databas- struktur.
D.3.1
Hantering av data
SQL (Structured Query Language) är ett välkänt programmeringsspråk som används för att hämta, lägga till, ändra och ta bort data i en databas [62]. När data ska hämtas eller ändras i en databas formuleras detta i SQL-kod som skickas till databasen. Kod som skickas till en databas för exekvering kallas i den här redogörelsen för kommandon eller förfrågningar. SQL-kod kan även användas för att ändra strukturen i databasen, till exempel för att lägga till eller ta bort tabeller, lägga till kolumner i tabeller eller byta namn på dem.
D.4. Metod
Något som kommer visa sig vara viktigt senare i denna redogörelse är att alla SQL- kommandon avslutas med ett semikolon. Det är så kompilatorn vet att ett kommando är avslutat och att det som eventuellt följer är början på ett nytt. Det kan även vara bra att veta att två på varandra följande bindestreck betyder att resterande del av raden är en kommentar från utvecklaren och därför inte ska tolkas som kod.
D.3.1.1 Kodexempel
För att ge läsaren en uppfattning om hur SQL fungerar visas här ett par exempel på SQL- kod. Det första exemplet hämtar alla användare från tabellen med användare. Det står även en kommentar i slutet av raden som inte kommer exekveras som kod:
SELECT * FROM Users; -- Hämta alla användare (detta är en kommentar)
Det går även att lägga till påståenden som måste vara sanna för att data ska hämtas. Det görs genom att lägga till WHERE och sedan skriva påståenden som till exempel Age=25 för att hämta alla användare som är 25 år gamla. Påståenden kan separeras med AND för att kräva att både påståendet till vänster och det till höger om AND måste uppfyllas. De kan på samma sätt separeras med OR för att säga att det räcker om det ena eller det andra påståendet är sant för att datan ska hämtas. Ett kommando som hämtar alla användare som är 25 år gamla är:
SELECT * FROM Users WHERE Age=25; -- Hämta alla användare med ålder 25
Det sista kodexemplet tar bort tabellen med användare och dess innehåll:
DROP TABLE Users; -- Ta bort tabellen med användare, detta kan inte ångras!
ãÑ
D.4
Metod
Det här kapitlet beskriver hur svaren på frågeställningarna togs fram genom en litteratur- studie samt en analys av webbapplikationen SecTrack.
D.4.1
Litteraturstudie
För att få en förståelse för vilka metoder som kan användas för att utföra SQL-injektioner studerades flertalet texter från kvalificerade källor. Några av källorna som användes var kandidat- och masterarbeten som hittades via sökmotorn Google Scholar. Andra källor var till exempel boken SQL: Practical Guide for Developers som är publicerad av Elsevier Science and Technology och artikeln On automated prepared statement generation to remove SQL injection vulnerabilities publicerad i Information and Software Technology.
Denna studie gav svaret på vad som gör en webbapplikation mottaglig för SQL-injektioner och vad utvecklaren kan göra för att förhindra dem. Slutligen användes resultatet från litteraturstudien för att analysera SecTrack samt dra slutsatser kring huruvida applikationen är sårbar mot SQL-injektioner.
D.5. Resultat
D.4.2
Analys av SecTrack
För att besvara frågeställningen om huruvida det finns någon säkerhetsbrist i SecTrack som gör att dess databas är sårbar för SQL-injektioner utfördes en analys av applikationen. D.4.2.1 Kodanalys
Det första steget i analysen var att identifiera delar av koden som uppenbart innebar sårbar- het mot SQL-injektioner. Det som främst uppmärksammades var om det fanns implemen- tationer där indata från användare användes direkt när en förfrågan till databasen skulle skickas. En sådan implementation möjliggör för användaren att integrera kommandon till databasen i indatan vilket tas upp mer ingående i kapitel D.5. På samma sätt kontrollera- des hur data hanteras då den hämtas. Det finns sätt att hämta data som möjliggör olovlig exekvering av kommandon, även detta tas upp i kapitel D.5.
D.4.2.2 Tester
Den andra delen av analysen bestod av tester. En del av testerna som utfördes var de manu- ella tester som föreslås på OWASPs (The Open Web Application Security Project) webbsida [63]. Det finns även mjukvara som kan skanna, utföra tester och identifiera säkerhetsrisker i en webbapplikation. En sådan mjukvara är OWASP ZAP som användes i den här redo- görelsen för att identifiera sårbarhet mot SQL-injektioner hos SecTrack [64].
D.5
Resultat
Det här avsnittet redovisar de resultat som litteraturstudien och analysen av SecTrack gav.