Bokmärket En säker webbapplikation. Maria Westin. Projektrapport, DT144G Webbapplikationssäkerhet, 7,5 poäng

Transkript

1 MITTUNIVERSITETET Institutionen för informationsteknologi och medier (ITM) Examinator: Daniel Bosk, Författarens e-postadress: Utbildningsprogram: Webbutveckling, 120 poäng Datum: [Plats för ev. illustration] Projektrapport, DT144G Webbapplikationssäkerhet, 7,5 poäng Bokmärket

2 Sammanfattning Sammanfattning Denna rapport beskriver utvecklingen av en webbapplikation med namnet Bokmärket. Målet var att utveckla en säker webbapplikation. För att åstadkomma detta har jag följt OWASP:s topp-tio-lista med de säkerhetsbrister som de anser det viktigast att skydda sig mot, och de åtgärder som de rekommenderar. Projektet har varit mycket lärorikt och jag känner mig efter omständigheterna nöjd med den säkerhet som jag lyckats implementera. ii

3 En säker webbapplikation Innehållsförteckning Innehållsförteckning Sammanfattning.. ii 1 Inledning Bakgrund Mål Bakgrundsmaterial Metod Applikationen A1 - Injektioner A2 - Autentisering och sessionshantering A3 - Cross-Site Scripting (XSS) A4 - Insecure Direct Object References A5 - Osäker konfiguration A6 - Känslig data A7 - Åtkomstkontroll A8 - Cross-Site Request Forgery A9 - Komponenter A10 - Omdirigering och vidarebefordring Resultat Slutsatser Källförteckning iii

4 1 Inledning 1 Inledning 1.1 Bakgrund 1.2 Mål Kursen webbapplikationssäkerhet handlar om att belysa de vanligaste säkerhetsbristerna för webbapplikationer och vilka åtgärder man kan ta för att öka säkerheten. Kursen bygger på OWASP:s topp-tio-lista [1] över de mest kritiska säkerhetsriskerna för webbapplikationer. OWASP är en förkortning av The Open Web Application Security Project [2] och är en världsomspännande frivilligorganisation med målet att förbättra säkerheten genom att sprida information om risker och rekommendera åtgärder. Examinationen i kursen består av att utveckla en säker webbapplikation, med hantering av användarkonton och lagring av användaruppgifter. I webbapplikationen ska det finnas åtgärder för att minimera säkerhetsriskerna från OWASP:s topp-tio lista. Målet med projektet är att utveckla en säker webbapplikation, med hantering av användarkonton och lagring av användaruppgifter. I webbapplikationen ska det finnas åtgärder för att minimera säkerhetsriskerna från OWASP:s topp-tio lista [1]. Målet enligt uppgiftsbeskrivningen: - Att redogöra för de vanligaste attackerna mot webbapplikationer. - Att förklara hur de vanligaste attackerna mot webbapplikationer fungerar. - Att tillämpa metoder för att förebygga de vanligaste attackerna mot webbapplikationer. - Att granska programkod för att finna säkerhetsbrister. 1

5 2 Bakgrundsmaterial 2 Bakgrundsmaterial Projektet bygger på OWASP:s topp-tio-lista [1] så här kommer jag gå igenom och förklara punkterna i listan, från A1, högst prioritet, till A10, lägst prioritet. Hur riskerna prioriteras är en kombination av hur lätta de är att upptäcka, hur lätta de är att åtgärda och vilka effekter en attack kan ha. A1 - Injection Injektion uppstår när opålitlig data skickas till en databas som en del av ett kommando eller en fråga. Angriparen kan på så vis utföra oönskade kommandon, t.ex. radera hela databasen, eller komma åt hemlig data, t.ex. personliga uppgifter och lösenord. A2 - Broken Authentication and Session Management Bristande autentisering och sessionshantering kan göra att angripare kommer över andras lösenord, nycklar eller sessioner och kan därmed ta över någon annans användaridentitet. A3 - Cross-Site Scripting (XSS) XSS innebär att applikationen skickar opålitlig data till webbläsaren utan att först validera eller sanera. Med XSS kan angriparen exekvera skript i användarens webbläsare och exempelvis kapa sessions-id eller omdirigera användaren till en skadlig webbplats. A4 - Insecure Direct Object References Inträffar när en hänvisning till ett internt objekt, t.ex. en fil, katalog, databaspost eller nyckel, finns synlig i webbadress eller formulär utan åtkomstkontroll eller annat skydd. Då kan en angripare manipulera hänvisningen och få tillgång till andra objekt utan tillstånd. A5 - Security Misconfiguration För god säkerhet måste alla delar av applikationen vara konfigurerade på ett säkert sätt. Undvik standardinställningar eftersom dessa ofta är osäkra. Dessutom bör programvaran hållas aktuell. 2

6 2 Bakgrundsmaterial A6 - Sensitive Data Exposure Utan ordentligt skydd av känslig data, t.ex. kreditkort och lösenord, kan angripare stjäla sådana uppgifter och utföra bedrägerier, identitetsstöld, eller andra brott. Känsliga uppgifter kräver extra skydd både i lagring och vid utbyte med webbläsare. A7 - Missing Function Level Access Control Det är viktigt att webbapplikationen verifierar åtkomsträttigheterna innan innehållet visas i användargränssnittet. Men det är också viktigt att samma åtkomstkontroll sker på servern innan informationen skickas, annars kan angripare förfalska förfrågningar för att utan rättighet få tillgång till innehåll. A8 - Cross-Site Request Forgery (CSRF) CSRF innebär att angriparen tvingar en inloggad användares webbläsare att skicka en förfalskad HTTP-begäran, med sessions-id och övrig autentiseringsinformation, t.ex. genom att lura användaren att klicka på en länk med dold funktionalitet. Angriparen kan sedan tvinga användarens webbläsare att göra förfrågningar som applikationen tror kommer från den berättigade användaren, utan att denna märker något. A9 - Using Components with Known Vulnerabilities Komponenter, såsom bibliotek och ramverk, med kända sårbarheter kan undergräva applikationens säkerhet och öppna upp för en rad möjliga attacker. Sådana komponenter körs nästan alltid med full behörighet och ett angrepp skulle kunna orsaka allvarlig dataförlust. A10 - Unvalidated Redirects and Forwards Webbapplikationer omdirigerar och vidarebefordrar ofta användare till andra sidor och webbplatser. Om opålitlig data används för att bestämma destinationen utan ordentlig validering, kan angripare skicka användare till sidor som utsätter denna för t.ex. nätfiske eller sabotageprogram. Angripare kan också komma åt sidor med känslig information utan behörighet. 3

7 3 Metod 3 Metod 3.1 Applikationen Jag har valt att göra en applikation för annonsering av begagnade böcker till försäljning. Namnet är: BOKMÄRKET, med underrubriken: Köp & sälj begagnade böcker! Besökare ska kunna söka efter titlar, titta på annonser och skicka svar på annons till säljare. För att lägga in en annons måste användaren skapa ett konto. Som inloggad kan användaren även se och ändra sina personliga uppgifter och se och radera sina annonser. 3.2 A1 - Injektioner Injektioner kan finnas i information som användare skriver in i formulär. För att minska risken för otillåtna inmatningar valideras inmatningarna med formvalidator.php innan de behandlas vidare. Alla inmatningar begränsas till att bara innehålla de bokstäver, siffror eller andra tecken som kan behövas för ändamålet. Undantaget är lösenord som får innehålla alla typer av tecken för att öka möjligheten att skapa säkra lösenord. Nästa steg för att skydda applikationen från injektioner är att sanera inmatningarna från skadliga tecken genom funktionen mysqli_real_escape_string(), samtidigt binds också den inmatade informationen till en variabel. Förutom detta görs alla databasanrop med Prepared Statements, vilket innebär att förfrågan till databasen är förberedd och variablerna som kommer från användarinmatning stoppas in i efterhand. Ytterligare en åtgärd som man kan ta för att skydda sig mot injektioner är att använda Stored Procedures, vilket är i princip samma som ovanstående men sker i databasen. Jag har valt att inte använda mig av detta eftersom databasanropen i applikationen är ganska simpla. 4

8 3 Metod 3.3 A2 - Autentisering och sessionshantering För att hantera inloggning i applikationen använder jag mig av PHP:s egna sessionshanteringssystem $_SESSION som kopplar samman användarens sessions-id med parametrar som talar om ifall användaren är inloggad $_SESSION['authorized'], vad användaren heter, vilken E-postadressen är, användar-id samt en verifieringskod (token). Sessionen avslutas automatiskt när webbläsarfönstret stängs och användaren loggas då automatiskt ut. Användaren kan också logga ut genom att trycka på en knapp som leder till sidan logout.php. När sidan laddas körs session_destroy(), användaren loggas ut och skickas vidare till startsidan. För att vara säker på att bara inloggade användare får tillgång till vissa sidor görs en kontroll varje gång en sådan sida laddas. Detta sker med en if-sats som kontrollerar att $_SESSION['authorized'] är satt till true, om inte skickas användaren till login-sidan. Det är rekommenderat att verifiera användaren igen vid kritiska operationer och därför skickas ett E-mejl till användaren varje gång E- postadress eller lösenord ändras. För att ändra lösenord måste också det gamla lösenordet fyllas i först. Det är viktigt att användarna väljer säkra lösenord för att inte angripare ska kunna gissa sig fram. Därför är alla tecken tillåtna i lösenorden och kravet är minst 16 tecken. 3.4 A3 - Cross-Site Scripting (XSS) XSS-attacker kan utföras genom att skadlig kod skrivs in i t.ex. gästböcker, forum, eller kommentarsfält. Eller så skickas koden till en sårbar webbserver som styr tillbaka till användare, t.ex. en skadlig länk/formulär. En attack kan också utföras genom skadlig URL. För att skydda sig mot dessa attacker måste alla användarinmatningar som på något vis skrivs ut i applikationen saneras. Det gör jag genom funktionen safe() som läraren Nayeb Maleki tipsade om under en föreläsning. Funktionen ligger i filen config.php och sanerar inmatningen med php-funktionen htmlentities(). 5

9 3 Metod 3.5 A4 - Insecure Direct Object References Genom att ändra synliga parametrar i URL:en kan en angripare försöka få tillgång till andra användares sidor eller uppgifter. Bästa skyddet mot detta är att kontrollera användarens rättigheter för varje begäran som utförs. Ett exempel är annonsnumret som syns i URL:en när en inloggad användare öppnar sina egna annonser. Utan skydd skulle användaren kunna ändra numret i URL:en för att få tillgång till andra användares annonser. Nu kan man inte göra något mer än läsa annonsen, vilket alla användare ändå kan göra, men skulle man lägga in en knapp för att ta bort annonsen skulle det bli mycket viktigt att bara säljaren kommer in på sidan. Genom att lägga in inloggad användares id i databasfrågan och jämföra med ägaren till efterfrågad annons, säkerställs att användare bara kan titta på sina egna annonser. Som en extra åtgärd har jag också minimerat risken att angripare kan gissa sig till olika annonsnummer genom att generera slumpmässiga nummer genom uniqid(rand(), true). 3.6 A5 - Osäker konfiguration Saker som man bör tänka på när det gäller konfiguration är att begränsa åtkomst till eller ta bort serverns standardkonton med default lösenord. Debugfunktionalitet och administrationskonsoller, t.ex. phpmyadmin, måste tas bort vid publicering. Stänga av kataloglistning på servern. Det är också viktigt att kontrollera alla felvägar i applikationen och hantera alla möjliga fel. Applikationsservern får inte ge stack-trace felmeddelanden och självklart får applikationen inte krascha. Jag försöker hantera olika fel som kan uppstå genom olika if-satser i koden. Jag har skapat en sida som heter error.html, dit användare kan skickas om det uppstår fel. Detta sker t.ex. om det inte går att koppla upp mot databasen. Loggning är viktig del under den här rubriken och det utför jag genom PHP:s funktion error_log(). Jag loggar inte bara fel som uppstår utan allt viktigt som händer i applikationen, tillsammans med tidpunkt, ipadress, sessions-id och användare. Känsliga uppgifter som lösenord loggas inte. 6

10 3 Metod 3.7 A6 - Känslig data Skydd av känslig data är oerhört viktigt då det kan få stora konsekvenser om någon obehörig kommer åt uppgifterna. I min applikation är det lösenordet som måste skyddas extra noga. För att skydda lösenordet saltas det med slumpade tecken som tas fram vid registrering genom openssl_random_pseudo_bytes(32). Lösenord och salt krypteras sedan med sha256 innan det skickas till databasen. I databasen lagras det krypterade lösenordet tillsammans med det unika saltet. När en användare försöker logga in, hämtar servern saltet från databasen och lägger ihop det med lösenordet som användaren matat in, salt och lösenord krypteras och jämförs sedan med det krypterade lösenordet som finns sparat i databasen. Om lösenorden stämmer överens blir användaren inloggad. För att lösenordet inte ska kunna snappas upp på väg från webbläsaren till servern krävs en säker anslutning. Applikationen måste därför köras på en https-anslutning, där kommunikationen krypteras med SSL (Secure Sockets Layer), på så vis ska anslutningen inte kunna avlyssnas. För att användaren ska kunna lita på att servern är den den utger sig för att vara krävs att ett undertecknat digitalt certifikat installeras på servern. För att skydda inloggningsuppgifterna till databasen har jag lagt dessa i filen config.php, som sedan kopplas till alla sidor med require_once. På så vis skrivs uppgifterna ut i klartext på bara ett ställe i hela applikationen. 3.8 A7 - Åtkomstkontroll För att minska risken att någon utför en handling i databasen utan rättighet, så har jag skapat tre olika användare med olika rättigheter som används i uppkopplingarna. Det finns en användare (read) som bara har rätt att läsa innehåll. Denna används för uppkoppling på sidorna index.php, add.php och myadd.php. 7

11 3 Metod Det finns en användare (write) som har rätt att läsa, lägga till och uppdatera. Denna används på för uppkoppling på sidorna login.php och edit.php. Slutligen finns det en användare (delete) som har rätt att läsa, lägga till och ta bort. Denna används på sidan mypage.php. 3.9 A8 - Cross-Site Request Forgery (CSRF) För att skydda sig mot CSRF måste man först och främst skydda sig mot XSS, hur jag gör det står under punkt 3.4. Om man är skyddad mot XSS är nästa steg att använda CAPTCHA för att verifiera att användaren är en människa och inte en maskin, samt att använda one-time tokens för att verifiera att det är användaren som skickar informationen inifrån applikationen och inte någonting som kommer utifrån. Jag har valt att använda en typ av CAPTCHA som heter Are You A Human, vilken är en roligare version där man spelar ett litet spel istället för att skriva bokstäver från en bild. Denna verifikation sker vid registrering och inloggning. Nackdelen med CAPTCHA är att javascript krävs. För att kunna logga in på applikationen måste fyra skript slås på: ajax.googleapis.com areyouahuman.com ayah_data2.s3.amazonaws.com. Jag har också valt att skapa en token vid inloggning som sedan används under den sessionen för att verifiera att informationen kommer inifrån applikationen. Denna token skapas med uniqid(rand(), true) och göms i formulären. När formulärdatan skickas till servern jämförs denna token med den som finns i sessionsparametern A9 - Komponenter Jag använder inte bibliotek och ramverk i applikationen. 8

12 3 Metod 3.11 A10 - Omdirigering och vidarebefordring Rekommendationen är att undvika omdirigeringar och vidarebefordringar så långt som möjligt. Om man ändå använder detta ska man undvika att låta användarparametrar bestämma destinationen. På vissa ställen vidarebefordrar jag användaren på serversidan genom funktionen header() och jag använder inte några användarparametrar för att bestämma destinationen. Det handlar bl.a. om att skicka användare som inte är auktoriserade bort från den hemliga sidan till login.php, eller vid utloggning från logout.php till startsidan. 9

13 4 Resultat 4 Resultat Webbapplikationen som jag har skapat är enligt min kunskap säker mot injektioner (A1), då alla användarinmatningar saneras innan de skickas till databasen och eftersom databasanropen sker med Prepared Statements. Med PHP:s sessionshanteringssystem blir sessionshanteringen (A2) säker. Autentiseringskontroller sker regelbundet och vid kritiska operationer vidtas extra åtgärder. Som skydd mot XSS (A3) saneras alla användarinmatningar innan de skrivs ut i applikationen. För att skydda mot Insecure Direct Object References (A4) sker åtkomstkontroll vid hämtning av data. Med if-satser och felmeddelanden försöker jag kontrollera olika felväger. För ytterligare kontroll loggas alla viktiga händelser. (A5) Känslig data (A6), i detta fall lösenord, skyddas med salt och kryptering. Databasens inloggningsuppgifter skyddas genom att bara skriva ut dem i klartext på ett ställe. Applikationen är också tänkt att köras över en säker anslutning, med SSL-kryptering. Kopplar upp med databasanvändare som har få rättigheter för bättre åtkomstkontroll (A7). För att skydda mot CSRF (A8) används CAPTCHA och sessiontokens. Finns ingen risk för komponenter med kända svagheter (A9) och jag undviker omdirigeringar och vidarebefordringar (A10). 10

14 5 Slutsatser 5 Slutsatser Efter att ha försatt mig i svår tidspress är jag riktigt nöjd med de säkerhetsåtgärder som jag lyckats implementera i min webbapplikation. Fån början hade jag tänkt använda Facebook för inloggning, men det var en sak som fick strykas på grund av tidsbrist. En annan sak som inte riktigt hunnits med är att gå igenom alla felvägar så noga som jag skulle ha velat. Detta är något som jag är medveten om och jag hoppas att det ändå syns att jag gjort ett försök. CAPTCHA är ingenting som användarna uppskattar och jag tänker efter en extra gång innan jag använder det. Men eftersom fokus på denna webbapplikation ligger på säkerhet så fick den i det här fallet gå före användbarheten. Det har varit oerhört nyttigt att genomföra detta projekt och jag tar med mig många nya kunskaper till framtiden. 11

15 Källförteckning Källförteckning [1] OWASP, Top , Hämtad [2] OWASP, The Open Web Application Security Project, Hämtad