B.7
Slutsats
Detta avsnitt besvarar frågeställningarna utifrån resultatet på denna studie.
B.7.1
Vilka för- och nackdelar kan det finnas med att enbart utveckla
webbapplikationer före mobilapplikationer för mobilanvändare inom
prestanda och i vilka scenarion är det fördelaktigt att utveckla enbart en
webbapplikation eller mobilapplikation?
En fördel med enbart utveckla en webbapplikation är att det inte kräver lika mycket resurser i form av att utbilda oerfarna utvecklare eller anställa mer erfarna utvecklare. Ett tillfälle då det kan vara värt att spara resurser kan vara då en applikation utvecklas som prototyp eller skiss, likt MRP, eftersom att prototyputveckling är avsett att kräva relativt få resurser. Ett annat fall kan vara för småföretagare som är begränsade i resurser. För en småföretagare skulle det också kunna vara fördelaktigt eftersom att det gör att den kan nå ut till en större målgrupp eftersom att en webbapplikation fungerar på både iOS och Android.
En annan fördel med att enbart utveckla en webbapplikation är vid användning av de vanligaste programmeringsspråken för respektive applikation är inlärningskurvan snabbare för JavaScript och webbapplikationers utveckling. Det gör exempelvis att i ett projekt med oerfarna programmerare kan det vara effektivare att utveckla en webbapplikation. Det är också lättare för en oerfaren grupp programmerare att skriva ut “Hello World”. Det kan visa på att det kräver färre förkunskaper för en oerfaren programmerare att koda webbapplika- tioner.
Intäktsgenerering är vad som driver företag och om en applikation är avsedd att generera pengar skulle det kunna finnas situationer då det bättre alternativet är att utveckla en mobi- lapplikation. Detta eftersom att mobilapplikationer kan ta betalt för en nedladdning medan webbapplikationer inte har samma alternativ. Ett exempel på en sådan situation kan vara när applikationen är företagsprodukten och företaget inte vill ha reklamannonser i sin applika- tion. Då kan det vara fördelaktigt att ta betalt för användarna att ladda ned applikationen.
Det kan vara fördelaktigt att utveckla en mobilapplikation ifall applikationen kräver myc- ket prestanda, eftersom att webbapplikationer har ineffektiv prestanda på Android och iOS. Detta innebär att liknande funktionalitet tar längre tid för en webbapplikation.
B.7.2
Var det lämpligt att välja webbapplikation istället för mobilapplikation i
detta projekt?
Ja. I detta projekt skulle ett konceptbevis utvecklas för NFC i syfte att visa att ett sådant sy- stem kan ha praktisk användning och är genomförbar. Ett konceptbevis är en typ av prototyp. Eftersom att MRP inte skulle vara så prestandakrävande var inte prestandaförlusten med att utveckla en mobilapplikation ett problem. För att kunna fokusera på att applikationen skulle ha mycket funktionalitet snarare än prestanda var det lämpligt att utveckla en webbapplika- tion.
C
Man-in-the-middle attack i
HTTPS av Elmedin Zildzic
C.1
Inledning
Idag sker nästan allting på internet, allt från e-handel till bankhantering. Dessa tjänster han- terar privat och känslig information om användare, och därför är det också viktigt att dessa tjänster utvecklas på ett sätt som inte utsätter användare av tjänsterna för diverse attacker. Ett sätt att uppfylla säkerhet för en webbsida är att implementera HTTPS protokollet, som krypterar informationen som sänds från en klient till en server. Google försöker idag att få utvecklare att implementera HTTPS i sina hemsidor genom att i Google Chrome markera hemsidor utan HTTPS som osäkra [47]. HTTPS räcker långt vad gäller säkerhet, men i vissa fall kan användare hamna i en falsk känsla av säkerhet genom att helt förlita sig på hemsidor som använder sig av HTTPS. En typ av attack som HTTPS är sårbar mot kallas för Man-in- the-middle attack, och är den typ av attack som rapporten kommer att fokusera på.
C.1.1
Syfte
Syftet med denna studie är att ge en översiktlig förståelse i hur HTTPS fungerar, samt förstå riskerna som finns för Man-in-the-middle attacker i HTTPS och hur en användare kan skydda sig mot dem.
C.1.2
Frågeställning
Följande frågor har tagits fram för att lättare förstå syftet med studien. 1. Vad är Man-in-the-middle (MITM) attacker för något?
2. Vilka risker finns för att drabbas av en MITM attack?
3. Hur kan webbapplikationen samt användarna skyddas mot MITM attacker?
C.1.3
Avgränsningar
Denna studie kommer enbart att vara en litteraturstudie, vilket innebär att studien endast kommer att ta hänsyn till publicerade artiklar och eventuellt andra källor som uppfyller syftet
C.2. Bakgrund
med studien. Egna erfarenheter och experiment kommer ej att behandlas eller utföras inför denna studie.
C.2
Bakgrund
Googles API:er blir otillgängliga för webbapplikationer som ansluter sig till API:erna utan HTTPS, såvida själva HTTP förfrågan innehåller känslig data. I projektets fall krävdes au- tentisering i form av en API nyckel för att använda Google Maps API, vilket innebär att nyckeln behövdes skickas med i HTTP förfrågan till API:t. Nyckeln räknas som känslig data, och måste därför skickas med HTTPS [48]. HTTPS implementerades därför i produkten som utvecklats för projektet eftersom att moderna webbläsare inte tillåter HTTPS förfrågan från en HTTP hemsida, eller vice versa [49]. Frågan är ifall HTTPS är tillräckligt säkert, eller om utvecklare bör överväga andra säkerhetsåtgärder utöver HTTPS för att fullständigt skydda sin webbapplikation och sina användare mot angrepp.
Även om säkerhet inte har varit ett fokus för projektet kan det fortfarande vara använd- bart och relevant att ha koll på hur säkerheten fungerar i HTTPS, speciellt ifall en liknande produkt senare ska utvecklas av polisen som har väldigt höga krav på säkerhet.
C.3
Teori
I detta avsnitt ges en översiktlig teori om HTTPS och de olika komponenterna som ingår i protokollet.
C.3.1
HTTPS
Skillnaden i HTTP och HTTPS är att HTTPS kan kryptera datan som skickas mellan två sy- stem för att skydda känslig information som kan finnas i datan, medan HTTP skickar okryp- terad data som kan läsas av alla system. HTTPS åstadkommer detta med hjälp av protokollen SSL (Secure Socket Layer) och TLS (Transport Layer Security) [50].
C.3.2
Certificate Authorities (CA)
Som namnet antyder, kan en Certificate Authority tilldela giltiga SSL/TLS certifikat till företag och organisationer som tillhandahåller servrar som begärt detta. Ett exempel på en CA är Let’s Encrypt [51].
C.3.3
SSL/TLS
SSL är ett protokoll som används för att kryptera data som skickas mellan två system i syfte att göra en anslutning säker och skyddad mot avlyssnare. SSL finns normalt i versionerna 2.0 och 3.0, medan TLS 1.0 är dess efterträdare. Som förväntas av nyare versioner är de säkrare, och säkerhetshål som kan ha funnits i tidigare versioner finns inte i de senare. TLS finns även i versionerna 1.1, 1.2 och 1.3 (senaste). SSL/TLS versionerna är inte bakåtkompatibla, men servrar och klienter som stödjer äldre versioner kan välja att köra dem istället [52].
SSL/TLS används tillsammans med HTTP genom att först genomgå en SSL/TLS hands- hake, där klienten initialiserar en handskakning. Servern skickar sedan ett signerat certifikat till klienten. Ett certifikat är giltigt endast om det är signerat av en Cerftificate Authority som klienten, i detta fall webbläsaren, känner igen. Klienten kan dock förbigå detta genom att en användare av klienten väljer att ignorera varningen om ogiltigt certifikat, men det är starkt rekommenderat att detta inte görs. Efter att klienten godkänt certifikatet skickas en privat nyckel till servern som servern kan använda för att dekryptera datan som skickas från klien- ten. När detta skett och handskakningen avslutas utan systemfel kan klienten skicka HTTP på vanligt vis [52].
C.4. Metod
C.4
Metod
Eftersom att denna rapport enbart är en litteraturstudie kommer metoden främst gå ut på att leta efter trovärdiga källor som kan refereras till i texten.
Det primära tillvägagångssättet för att hitta källor har varit genom Google Scholar. Där har sökningen skett med hjälp av nyckelord så som HTTPS MITM eller HTTPS Man-in-the- middle för att hitta artiklar som är relevanta för studiens syfte. Fördelen med Google Scholar är att resultatet av sökningen främst visar publicerade artiklar och studier som ofta gjorts i kända konferens som IEEE och ACM. I denna studie hittades majoriteten av källorna från IEEE, och endast dessa har använts för att besvara frågeställningen.
Övriga källor har använts för att stödja vissa påståenden som gjorts i denna studie, som exempelvis att Google Chrome markerar vanliga HTTP sidor som osäkra. I dessa fall har den vanliga Google sökmotorn använts, där söksträngen innehåller själva påståendet eller delar av påståendet. Därefter har den mest lämpliga källan använts, exempelvis från Googles eller Mozillas egna hemsidor som själva utvecklar webbläsare, och kan därmed räknas som trovärdiga.