Utredning och impementation av säkerhetslösningar för publika API:er

Datateknik C, Examensarbete, 15 högskolepoäng

UTREDNING OCH IMPLEMENTATION AV

SÄKERHETSLÖSNINGAR FÖR PUBLIKA

API:ER

Dataingenjörsprogrammet, 180 högskolepoäng Örebro Vårterminen 2020

Examinator: Thomas Padron-McCarthy

UREDNING OCH IMPLEMENTATION AV SÄKERHETSLÖSNINGAR FÖR PUBLIKA API:ER

Sammanfattning

Examensarbetet går igenom vanliga säkerhetsrisker med publika API:er och ger information om IIS, Apache, Nginx, OAuth 2.0 och några av deras säkerhetsmoduler som kan implementeras. IIS och Apache har inbyggda hanteringsprocesser för att motverka ”Distributed-Denial-of-Service” (DDoS) attacker som jämförs med varandra utifrån analys av en befintlig rapport som testar två olika DDoS attacktyper. Säkerhetslösningarnas autentiseringsmoduler bryts ner i olika verifieringsprocesser, där det framkommer att verifieringsprocesserna har en gemensam svaghet mot ”Man-in-The-Middle” (MitM) attacker. Rapporten går in djupare hur man kan skydda sig mot MitM attacker med bra krypteringsprotokoll, ”Transport Layer Security” (TLS), samt undersöker den nyaste versionen TLS 1.3.

Nyckelord: API, Datasäkerhet, IIS, Apache, Nginx, OAuth 2.0, Autentisering, DDoS, TLS

1.3.

Abstract

The thesis examines common security risks with public APIs and provides information about IIS, Apache, Nginx and OAuth 2.0 and some of the security modules they provide that can be implemented. IIS and Apache have builtin modules for handling Distributed-Denial-of-Service (DDoS) attacks that are compared against eachother through analyzing a existing report that tests two different DDoS attack types. The security solutions authentication modules are broken down into different types of verification processes, where it comes forth that the processes share a common security risk against Man-in-the-Middle (MitM) attacks. The report goes through how you can protect against MitM attacks with secure encryption protocols, Transport Layer Security (TLS), and analyzes the newest version TLS 1.3.

Förord

Stort tack till Triona för möjligheten att utföra studien med gott bemötande och stöd.

Jag vill även tacka min handledare på universitetet, Farhang Nemanti, för support under mitt examensarbete.

Innehållsförteckning

3.2 MICROSOFT INTERNET INFORMATION SERVICES (IIS) ... 10

3.2.1 Autentiseringsmoduler ... 10

3.2.2 Dynamic IP Restrictions (DIPR) ... 12

3.3 NGINX ... 13

3.3.1 Autentiseringsmoduler ... 13

3.4 APACHE HTTPSERVER ... 14

3.4.1 Autentiseringsmoduler ... 14

3.4.2 DDoS säkerhet (mod_evasive) ... 14

3.5 OAUTH 2.0 ... 16

3.5.1 Autentiseringsmodul ... 16

4 UTREDNING ... 17

4.1 DISTRIBUTED DENIAL OF SERVICE (DDOS)ATTACKER ... 17

4.2 AUTENTISERING ... 20

5 IMPLEMENTATION ... 26

5.1 ARKITEKTUR ... 26

5.2 SYSTEMARKITEKTUR ... 27

5.3 METODER OCH VERKTYG ... 28

5.4 RESULTAT ... 29

6 SLUTSATS & DISKUSSION ... 31

6.1 SOCIALA OCH EKONOMISKA IMPLIKATIONER ... 32

6.2 PROJEKTETS UTVECKLINGSPOTENTIAL ... 33

7 REFLEKTION KRING EGET LÄRANDE ... 34

7.1 KUNSKAP OCH FÖRSTÅELSE ... 34

7.2 FÄRDIGHET OCH FÖRMÅGA ... 34

7.3 VÄRDERINGSFÖRMÅGA OCH FÖRHÅLLNINGSSÄTT ... 35

1

Inledning

1.1

Bakgrund

Säkerhet är väldigt viktigt att tänka på när man har publika applikationer och det är oftast svårt att veta om alla säkerhetsrisker. Det finns många säkerhetslösningar idag som erbjuder säkerhet till webbapplikationer, dessa säkerhetslösningar tas upp och utreds gentemot varandra för att få bättre förståelse vad som erbjuds och vad för säkerhetsproblem som de försöker motverka. Triona, uppdragsgivaren, utvecklar och förvaltar många API:er och där har behovet att göra en utredning där befintliga säkerhetssystem lyfts fram. Det används befintliga säkerhetslösningar på företaget och studien ska göra det lättare för Triona att välja rätt säkerhetslösningar till nya och befintliga API projekt.

1.2

Projekt

Projektet gör en utredning kring befintliga säkerhetslösningar för publika API:er och upplyser om vanliga säkerhetsbrister på webbaserade tjänster. Projektet går igenom de valda säkerhetslösningarna och avgränsat ger information om vad för moduler som erbjuds och hur de fungerar. Säkerhetslösningarna jämförs med varandra utifrån olika perspektiv och diskuterar möjliga säkerhetsbrister och upplyser hur säkerhetslösningarnas autentiseringsmoduler kan göras säkra.

Implementationen är en konsolapplikation och en ASP.NET Core Web API. Information från utredningen har påverkat hur implementationen har skapats, där utredningen har upplyst vilka val en utvecklare kan göra för att skydda applikationen.

2

Bakgrund

”Web Application Programming Interface” (Web API) ger tillgång till data och funktioner som konsumeras av klienter över ett nätverk. Företag som Facebook har publika Web API:er för att andra applikationer ska kunna integrera Facebook funktionaliteter som att få tillgång till dina vänner, profilbilder och alla andra tjänster som Facebook själva kan välja göra tillgängligt. [1] API refererar vanligtvis till Web API så länge inte något annat sammanhang är nämnt [2]. I fortsättningen kommer rapporten använda API istället för Web API.

Det finns säkerhetslösningar till API:er som kan hjälpa till att säkra upp webbapplikationen mot angripare med hjälp av säkerhetsmoduler. Det är svårt att utveckla ett API interface som tänker på alla möjliga angrepp [3]. Det gäller att vara väl informerad om säkerhetsbrister för att kunna analysera från olika perspektiv, hur man kan åtgärda säkerhetsproblem.

”Open Web Application Security Project” (OWASP) är en ideell organisation med mål att förbättra säkerheten på mjukvara med stort fokus på webbapplikationer. OWASP har publicerat ett dokument för att upplysa om dom 10 vanligaste säkerhetsbristerna på webbapplikationer (Se figur 2.1). Organisationen vill att företag ska använda sig av dokumentet för att systematiskt gå igenom säkerhetsbristerna för att analysera om applikationen har implementerat skydd. [4]

(Figur 2.1: Lista av OWASP topp 10 säkerhetsbrister på webbapplikationer [4].)

Injection

”Injection” attacker utförs när angriparen skickar data till ditt program i ett försök att manipulera kodkörningen att köra otillåtna kommandon. Den vanligaste attacktypen är Structured Query Language Injection (SQL Injection) där angriparen använder speciella kommandon i SQL programspråket för att hämta ut konfidentiell information ur relationsdatabasen. [4, 5]

OWASP TOP 10 1. Injection

2. Broken Authentication 3. Sensitive Data Exposure 4. XML External Entities (XXE) 5. Broken Access Control 6. Security Misconfiguration 7. Cross Site Scripting (XSS) 8. Insecure Deserialisation

9. Using Components With Known Vulnerabilities 10. Insufficient Logging & Monitoring

Broken Authentication

Felaktiga implementeringar på autentisering eller sessionshantering gör att angripare kan stjäla eller gissa sig till autentiseringsuppgifter och utge sig för att vara någon annan. [4]

Beroende på hur användaruppgifterna representeras så finns det olika svagheter. Rapporten kommer att gå igenom de olika representationerna i utredningsdelen.

Sensitive Data Exposure

Webbapplikationer måste vara väldigt försiktiga vid hantering av konfidentiell information, till exempel personuppgifter, patientjournaler och kreditkortsuppgifter. Vid transaktioner över internet måste utvecklare ha extra säkerhetsskydd som säkra krypteringsprotokoll för att förhindra att angripare kan utvinna informationen. [4]

Saknas det extra säkerhetsskydd kan företaget hamna i legala problem och användarna bli utsatt för andra brott till exempel identitetstöld, kreditkortsbedrägerier och utpressning. Tumregel är att inte lagra konfidentiell information i onödan [4].

XML External Entities (XXE)

XXE attack görs mot program som har en dålig konfigurerad XML tolk (XML parser). Angriparen skickar XML data som innehåller referenser till externa enheter och på så sätt kan lura XML tolken att ge tillbaka konfidentiell information. [4]

Broken Access Control

”Access Control” innebär att begränsa tillgängligheten på resurser i systemet med att endast tillåta vissa användare att läsa och-eller modifiera resursen. Misstag i auktoriseringen innebär att resursen blir tillgänglig för angripare, vilket kan leda till att angriparen kan läsa, modifiera eller helt enkelt ta bort resursen från systemet. [4]

Security Misconfiguration

Applikationen, operativsystemet, bibliotek och ramverk som används tillsammans med applikationen måste vara korrekt konfigurerade och vara uppdaterad med den senaste och säkraste uppdateringen. [4]

Det är väldigt vanligt att fel uppkommer genom felaktiga konfigureringar eller att det har glömts bort att installera den nyaste uppdateringen som fixar en säkerhetslucka. Det sätts mycket press på utvecklare att vara uppmärksamma på förändringar i alla olika verktyg som används till applikationen, samt kräver mycket kunskap i många områden för att veta om allt är korrekt konfigurerat. [4]

Cross Site Scripting (XSS)

XXS är en annan typ av Injektions attack som skickar över kod till webbapplikationen i syfte att köra den hos mottagaren. Vanliga XSS attacker görs för att försöka stjäla krypteringsnycklar, användaruppgifter eller installera virus, till exempel ”key-logger” virus som registrerar alla knapptryck på tangentbordet hos mottagaren. [4]

Saknas det skydd mot XSS attacker kan det gå väldigt illa. Det finns automatiska verktyg som kan användas för att hitta XSS säkerhetsluckor för väl etablerade ramverk som PHP och ASP.NET. [4]

Insecure Deserialization

API:er och applikationer kan bli skadade när programmet avserialiserar data given från en angripare. Det finns två olika attacktyper: [4]

• Objekt & Datastruktur attack:

Angriparen försöker modifiera applikationens logik eller försöker köra kod som anropar på klasser som kan ändra beteendet på programmet under eller efter avserialiseringen.

• Datamanipulerings attack:

Försöker manipulera befintliga resurser i systemet, en typisk Access Control attack.

Using Components with Known Vulnerabilities

Ungefär samma sak som ”Security Misconfiguration”, när applikationer är byggda med flera komponenter med kända sårbarheter kan det vara ett sätt för angripare att exploatera systemet. Varje organisation eller företag måste ha en plan för att övervaka de ingående komponenterna efter nya uppdateringar och kritiska konfigureringar. I vissa fall kan det ta tid för komponentens utvecklare att fixa sårbarheten, vilket gör att applikationen blir sårbar under en lång tid. [4]

Insufficient Logging and Monitoring Tools

Angripare förlitar sig på att applikationen inte kan upptäcka dom i tid. Många av dom största exploateringar som gjorts har till grunden varit möjlig för att applikationen saknat övervakning och bokföring av händelser. [4]

För att undersöka om du har tillräcklig loggning av händelser finns det en vanlig strategi med att undersöka loggboken efter ”Penetration Testing”. Loggboken bör ha sparat ner aktiviteterna och förmedla information om vad för skada som kan ha skett. [4]

3

Säkerhetslösningar

Idag finns det många säkerhetslösningar som kan integreras tillsammans med en API, det är därför viktigt att göra en ordentlig avgränsning.

Avgränsningen har gjorts utifrån analys av mest använda webbservrar idag samt hur relevanta säkerhetslösningarna är till uppdragsgivaren Triona. Med relevanta säkerhetslösningar innebär det om uppdragsgivaren Triona eller deras kunder använder sig av speciella säkerhetslösningar. Avgränsningen och säkerhetslösningarna har diskuterats med handläggare hos Triona, där gemensamma beslut har tagits, men även egna beslut har tagits av rapportens författare. Det här kapitlet går igenom vilka befintliga säkerhetslösningar är valda för utredningen samt informerar några av de säkerhetsmoduler som går och implementera. Alla olika säkerhetsmoduler tas inte upp, utan en avgränsning har gjorts för att det finns många olika moduler. Ytterligare säkerhetsmoduler måste lämnas över till vidareutveckling av projektet.

3.1

Val av säkerhetslösningar

Netcraft, ett internettjänstföretag har utfört en undersökning som visar att dom mest använda webbservrar, inaktiva och aktiva, är Microsoft IIS, Apache och Nginx. Undersökningen fick 1,246,121,153 svar från hemsidor från 260,089,947 unika domäner och 9,669,267 datorer publikt vända mot internet. [6]

Nginx

Nginx är den mest använda enligt undersökningen [6] med 36,91 procent. Nginx tog över ledarpositionen mellan mars-april 2019 och har ökat ytterligare med 1,84 miljoner domäner fram till april 2020. Nginx kan användas som en ”Reverse-Proxy” som sitter mellan klienter och andra webbservrar vilket kan förklara varför den har flest marknadsandelar. Oavsett orsak kan Nginx användas som en lättviktig webbserver vilket gör den relevant för

vidareundersökning.

Internet Information Services (IIS)

Microsoft har haft många uppgångar och nedgångar enligt undersökningen, juli 2017 hade Microsoft sin topp med hela 53 procent av marknaden, senaste visar att Microsoft ligger på 13 procent. [6]

Apache HTTP Web Server

Apache är den webbservern som har varit i ledarpositionen under längst tid enligt undersökningen, senaste informationen visar att Apache ligger på 25 procent av marknaden. Apache har dubbelt så mycket procentandelar jämfört med Microsoft IIS, och är vald för vidareundersökning för att den är så populär. [6]

OAuth 2.0

OAuth 2.0 är ett industristandardprotokoll för autentisering som är vald för undersökning för att säkerhetslösningen är väldigt populär hos Trionas kunder. Många företag som Amazon och Google använder sig också av OAuth 2.0 för att dela med sig av kontoinformation till tredjeparts-applikationer och hemsidor [8, 9].

3.2

Microsoft Internet Information Services (IIS)

Microsoft Internet Information Services (IIS) är en serverprogramvara som installeras på Windows maskiner som hjälper till att hosta .NET applikationer som ASP.NET. IIS kan även installeras på maskiner som har Node.js och PHP servrar. [10,11]

IIS integrerat tillsammans med din applikation gör det möjligt för dig som utvecklare att få använda Microsofts egna autentiseringsmoduler och få extra säkerhetsskydd på din applikation. [10,11]

3.2.1 Autentiseringsmoduler

IIS har flera olika autentiseringsmoduler som är valbara för dig som utvecklare att implementera (se figur 3.1). Det finns även stöd för att integrera tredje-parts autentiseringsmoduler om du känner att ingen av de givna modulerna passar in på din applikation. [12]

Microsoft IIS Autentiseringsmoduler (ISS 7.0 och högre)

- Anonymous authentication - Basic authentication - IIS Client Certificate Mapping authentication - Digest Authentication - Windows Authentication

(Figur 3.1: Autentiseringsmoduler för IIS 7.0 och högre versioner [12].)

Anonymous Authentication

Autentiseringsmodulen ger tillgång till anonyma användare till de publika delarna i din applikation. Anonyma användare innebär att servern inte kräver användarnamn och lösenord, utan det är helt okej för vem som helst att få tillgång till din applikations publika delar. [13] IIS har som standard aktiverat Anonymous Authentication, för att använda någon annan autentiseringsmodul måste den stängas av först. [13]

Basic Authentication

Basic Authentication autentiserar användare genom att transportera användarnamn och lösenord genom nätverket i en okrypterad form [14]. Följer servern ett stateless protocol, det vill säga att servern inte lagrar användarsessioner, måste användare skicka användarnamnet och lösenordet i headern till varje förfråga till servern.

Client Certificate Mapping Authentication

Certifikat från Transport Layer Security (TLS) eller Secure Sockets Layer (SSL) kryptering används i denna autentiseringsmodul för att verifiera användare. Det finns två verifieringsmetoder du kan välja mellan: One-To-One Mapping eller Many-To-One Mapping. [15]

• One-To-One Mapping:

Verifieringsmetoden innebär att matcha ett klientcertifikat till ett individuellt

användarkonto. Det kräver att du har ett användarkonto till varje klientcertifikat. [15] • Many-To-One Mapping:

Verifieringsmetoden matchar flera klientcertifikat till ett användarkonto baserat på fälten i klientcertifikaten. Utvecklaren skapar regler som tillåter eller nekar användare. [15]

Client Certificate Mapping Authentication fungerar annorlunda när du använder dig av ett Active Directory istället för en server för att matcha certifikat. Active Directory processen kräver att IIS servern och klientdatorn är medlemmar i en Active Directory domän och att användarkonton är sparade inom Active Directory. [15]

Digest Authentication

Autentiseringsmodulen skickar användarnamn och lösenord fast inte i vanlig text, utan den skickas som en hash av användaruppgifterna (sträng med fixad längd). Det skyddar användarnamnet och lösenordet att läsas av från angripare, processen att rekonstruera en hash till vanlig text igen är extremt svårt. [16]

Angripare kan fortfarande skicka in användaruppgifterna till servern som en hash och utge sig att vara användaren, för servern ser allting normalt ut. Det en angripare ser är en hash som representerar användaruppgifterna, men angriparen kan inte veta exakt vad det är för användarnamn och lösenord i text genom att bara analysera hashen. [16]

Windows Authentication

Användarnamn och lösenord hämtas från Windows konton och skickas över nätverket för autentisering. Användaruppgifterna skickas som en hash vilket gör det svårt att utvinna användaruppgifterna. Servern verifierar användaren genom att matcha dom givna uppgifterna med användare i en lista. Detta sätter krav att alla användare ska ha något slag av Windows konton eller användandet av ”Active Directory Service domain entities”. [17]

3.2.2 Dynamic IP Restrictions (DIPR)

”Dynamic IP Restrictions” (DIPR) är en säkerhetsmodul som är inbyggt i IIS 8.0 och högre för att skydda mot ”Distributed Denial Of Service” (DDoS) attacker. DIPR blockerar IP-adresser som uppfyller speciella krav som sätts av utvecklaren. [18]

DIPR kan blockera användare som skickar för många förfrågningar på samma gång och antal förfrågningar under ett tidsintervall. Utvecklaren kan bestämma gränserna utifrån eget behov (se figur 3.2). [18]

(Figur 3.2: Konfigurering på DIPR [18].)

Utvecklaren kan konfigurera hur DIPR ska blockera IP-adresser, till exempel Proxy Mode (se figur 3.3). Proxy Mode blockerar IP-adresser som hittas i X-Forwarded-For HTTP headern (XFF). XFF innehåller den exakta IP-adressen för avsändaren. [18, 19]

3.3

NGINX

Nginx är en ”open-source” webbserver, reverse-proxy server och webaccelerator utvecklad av den ryska ingenjören Igor Sysolev. Igor startade projektet år 2002 och släppte det till allmänheten år 2004. Företag som Netflix och Dropbox använder sig av Nginx eftersom mjukvaran ger prestanda och skalbarhet som underlättar den höga trafiken företagen får på deras webbservrar [21].

Nginx Plus är en tilläggstjänst som är byggd ovanpå Nginx som erbjuder mer funktionaliteteter och autentiseringsmoduler än gratisversionen [22]. De autentiseringsmoduler som undersöks i utredningen är endast tillgängligt i Nginx Plus, men för enkelhetens skull hänvisar rapporten härefter till Nginx.

3.3.1 Autentiseringsmoduler

Nginx har två autentiseringsmoduler, JSON Web Token (JWT) Authentication och Basic Authentication (se figur 3.4). Nginx kan skicka iväg förfrågningar till en autentiseringsserver om autentiseringsmodulerna inte passar in till projektet. [23]

(Figur 3.4: Nginx autentiseringsmoduler. [23])

JWT Authentication

Användaren skickar en ”JSON Web Token” (JWT) till servern som fungerar som ett unikt ID i autentiseringsprocessen. ”JavaScript Object Notation” (JSON) är en datastruktur i text format som är uppbyggd av namn/värde par. [24]

JWT Authentication kan kombineras tillsammans med andra autentiseringsmoduler. Till exempel att användaren autentiserar först med Basic Authentication, där användaren skickar över användarnamn och lösenord på nätverket och får tillbaka en JWT. Därefter kan JWT användas för att autentisera din identitet som du skickar med i varje ny förfrågan.

Nginx Autentiseringsmoduler

- JWT Authentication - Basic authentication

3.4

Apache HTTP Server

Apache HTTP server är en open-source serverprogramvara för UNIX och Windows maskiner. Apache är en väldigt populär [6] serverprogramvara och har funnits under en lång tid, första versionen Apache 1.0 släpptes 1995. [25]

Apache HTTP server underhålls av organisationen Apache Software Foundation som grundades 1999. Organisationen hjälper Apache HTTP server med ekonomiska, juridiska och organisatoriska ändamål. [25]

3.4.1 Autentiseringsmoduler

Apache HTTP server har fyra autentiseringsmoduler (se figur 3.5) [26]. Tre av autentiseringsmodulerna fungerar på samma sätt som i IIS, No (Anonymous) Authentication, Basic Authentication och Digest Authentication.

Apache HTTP Server Autentiseringsmoduler

- No Authentication - Basic Authentication - Digest Authentication - Form Authentication

(Figur 3.5: Autentiseringsmoduler för Apache HTTP Server. [26])

Form Authentication

Form Authentication är en autentiseringsmodul som använder sig av en ”HTML login form” för att autentisera användare. När en användare har blivit autentiserad sparas användaruppgifterna i en ”mod_session” modul. Mod_session använder sig frekvent av HTTP cookies, vilket är väldigt benägen att påverkas av XXS attacker (OWASP nummer 7). Därför är det viktigt att se över alla säkerhetsrisker med XSS innan man använder sig av Form Authentication. [27]

3.4.2 DDoS säkerhet (mod_evasive)

Apache har en ”mod_evasive” modul som kan aktiveras till din applikation för att skydda mot DDoS attacker, förutsatt att du använder dig av LAMP stacken [28]. LAMP är en akronym som ingår av flera komponenter (se figur 3.6) [29].

(Figur 3.6: LAMP stacken som krävs för mod_evasive verktyget [29].)

Verktyget övervakar inkommande förfrågningar till applikationen och letar efter misstänksamma mönster som kan indikera en pågående DDoS attack. Mönstren som verktyget letar efter är; Flera förfrågningar till samma resurs under en sekund, mer än 50 förfrågningar samtidigt och förfrågningar från IP-adresser som är svartlistade. [29]

LAMP stack

Operativsystem Linux

Webbserver Apache HTTP server

Databas MariaDB / mySQL

3.5

OAuth 2.0

OAuth 2.0 är ett industristandardprotokoll som används för auktorisering, men går också att använda för autentisering med OpenID Connect [30]. Detta skiljer säkerhetslösningen ganska mycket från IIS, Apache och Nginx där OAuth 2.0 är utvecklat med syftet att ge ut behörigheter av resurser till användare mellan olika applikationer och fixa Access Control säkerhetsproblem (OWASP nummer 5).

3.5.1 Autentiseringsmodul

När det kommer till autentisering av användare, använder man OpenID Connect som är byggt ovanpå OAuth 2.0 protokollet. OpenID Connect tillåter klienter att verifiera sin identitet med autentisering utfört av en auktoriserings server (OpenID Provider). OpenID Connect ska vara konfigurerbart att kunna använda sig av ytterligare funktionaliteter som olika krypteringsprotokoll och sessionshantering för att anpassa sig till utvecklarens behov. [30]

(Figur 3.6: Autentiseringsmodul för OAuth 2.0 [30].)

OpenID Connect

OpenID Connect skickar en autentiseringsförfrågan till en OpenID Provider, användaren ombeds att autentisera sig med en verifieringsprocess som är bestämd beroende på hur OpenID Providern är konfigurerad. Vanligt exempel är att användaren tas till en ny hemsida för att auktorisera sig med att skriva in användarnamn och lösenord. När användaren har givit ut rätt användaruppgifter och kan verifieras skickar OpenID Providern en ”ID Token” tillbaka till användaren, vilket representeras som en JWT. [30]

ID Token är säkerhetstoken som innehåller information om användaren och har egenskapen att inte kunna bli manipulerad. För att kolla att det är en giltig ID Token så finns det ett signaturfält i JWT som används med en krypteringsnyckel för att kontrollera att hela JWT inte har blivit manipulerad. [30]

OAuth 2.0 Autentiseringsmodul

4

Utredning

4.1

Distributed Denial of Service (DDoS) Attacker

I en rapport analyserades IIS 10.0 och Apache 2 mot varandra i deras förmåga att skydda sig mot ”HTTP Flood” och ”SYN Flood” attacker. Nyckeltal som rapporten analyserades var responstid, fel, standardavvikelse och CPU användning. [31]

HTTP Flood attack är en applikationslager DDoS attack där det oftast rör sig om ett bot-nätverk som skickar HTTP förfrågningar till webbservern i syfte av att överbelasta servern (se figur 4.1). När servern har överbelastats med förfrågningar får vanliga användare ”Denial-of-Service” svar på deras förfrågningar till servern. [32]

(Figur 4.1: Illustrering av en HTTP Flood attack mot en server [32].)

SYN Flood attack görs på transportlagret, där attacken försöker utnyttja handskakningsprocessen på Transmission Control Protocol (TCP). Handskakningen för TCP sker i tre steg: klienten skickar ett SYN paket till servern i syfte av att skapa en uppkoppling, servern skickar tillbaka ett SYN/ACK paket för att godkänna uppkopplingen och klienten skickar sist ett ACK paket för att konfirmera att SYN/ACK paketet mottagits (Se figur 4.2). [33]

(Figur 4.2: Handskakningsprotokollet (Three-Way Handshake) för TCP [33].)

För att utnyttja TCP protokollet skickas det kontinuerligt många SYN paket till servern för att starta handskakningsprocessen, det är vanligt att paketen är manipulerade med en annan IP-adress (IP spoofing) för att gömma avsändarens identitet. Servern skickar sedan ut SYN/ACK paket i hopp av att starta upp en ny uppkoppling, men inga ACK paket kommer någonsin tillbaka (se figur 4.3). Den ofullständiga handskakningen gör att resurser tas upp på servern, vilket kan ta upp alla resurser och förhindra legitima användare att skapa en uppkoppling med servern. [33]

Rapporten utvärderade prestandan på webbservrarna innan utförandet av en attack och fortsatte med att analysera varje attack var för sig. Varje test blev upprepat 5 gånger för att få bättre noggrannhet på resultaten och testerna utfördes under 120 sekunder. [31]

Analys av testresultaten visar att IIS var mer stabil, hade mindre CPU användning och gav snabbare responstid under en HTTP Flood attack. De första två testerna på 5000 och 10000 HTTP förfrågningar visade mycket bättre resultat för IIS 10.0 gällande responstiden. IIS 10.0 hade ett lägre medelvärde på responstiden på 58 millisekunder (under 5000 förfrågningar) och 106 millisekunder (under 10000 förfrågningar) jämfört med Apache 2 som hade medlevärden på 4527 respektive 6276 millisekunder (se figur 4.4). [31]

Apache 2 visade däremot bättre responstid under HTTP SYN attacker nästan identiskt som under vanlig användning (se figur 4.4). Apache 2 var dock den enda av säkerhetslösningarna som visade HTTP felmeddelanden till användare vid HTTP Flood attacker, IIS 10.0 skickade aldrig ut HTTP felmeddelanden under alla testscenarion. [31]

(Figur 4.4: Testresultaten för responstiden för IIS 10.0 och Apache 2 webbservrar [31]) Nginx kan hjälpa att identifiera pågående DDoS attacker men det är upp till utvecklaren att implementera hanteringsprocessen. Det finns inget inbyggt hanteringsprocess som finns i säkerhetslösningarna IIS och Apache och huruvida det är bra eller dåligt kan diskuteras. Fördelar med att utveckla din egen säkerhetslösning mot DDoS attacker är att säkerhet får en större roll i utvecklingsstadiet och att du får hantera processen på det bästa sättet för din applikation. Säkerhet är någonting som är viktigt och tänka på i början av utvecklingsstadiet och måste tas med största allvar. Det kan kännas enkelt att välja en säkerhetslösning som har inbyggt skydd för att spara resurser och tid på att utveckla sin egen lösning. Det värsta som kan hända är att applikationen blir utsatt för DDoS attack som gör applikationen oanvändbar och du retroaktivt utvecklar egna processer för att få applikationen användbar igen.

Problemet med att utveckla hanteringsprocesserna själv under en DDoS attack är att det finns risk att det konfigureras eller hanteras på fel sätt, hänger lite ihop med säkerhetsproblemet Security Misconfiguration (OWASP nummer 6). Inbyggda lösningar för att hantera DDoS attacker är oftast hanteringsprocesser som har existerat under en lång tid och har granskats av många olika utvecklare. Det gör det mer sannolikt att potentiella säkerhetsluckor har blivit fixade så länge säkerhetslösningen och utvecklarna fortfarande är aktiva.

Vid användande av befintliga moduler för DDoS attacker finns det ett problem om en säkerhetsbrist lyfts fram. Istället för att sätta utvecklare och säkerhetsexperter att starta processen att fixa säkerhetsluckan så måste ansvaret läggas över till företaget som har gett ut lösningen. Det kan leda till att företaget måste sitta och vänta på en uppdatering och får hoppas på att ingen angripare utnyttjar sårbarheten medan säkerhetsluckan åtgärdas (OWASP nummer 9).

4.2

Autentisering

Autentisering är en verifieringsprocess som görs av systemet för att försöka säkerställa identiteten på en klient. Systemet ber klienten att presentera information om antingen, något du

vet, något du har eller något du är som kan verifiera din identitet. [34]

Den här sektionen går igenom hur vi kan verifiera en identitet och vilka svagheter tillkommer med det olika verifieringsprocesserna. Det diskuteras förslag på åtgärder som kan göras för att se till att verifieringsprocessen kan anses vara så säker som möjligt.

Något du vet

Identiteten kan bekräftas när du presenterar något hemligt som bara användaren och autentiseraren har kännedom om, något du vet. För Basic Authentication i IIS sker detta med att skicka ett användarnamn och lösenord över nätverket. Användaruppgifterna som presenteras till autentiseraren säger att användaren vet någonting som ingen annan vet, och systemet använder det som ett bevis på användarens identitet. [34]

Svagheten med att presentera något du vet är att systemet förlitar sig på att det alltid är och förblir hemligt, men det är inte realistiskt. Avlyssnare på nätverket kan få tag på användaruppgifterna med en så kallad ”Man-in-the-middle” (MitM) attack. Presenterar angriparen dom stulna eller duplicerade användaruppgifter till auktoriseraren, ser systemet angriparen som legitim. [34, 37]

Används det enkla och korta lösenord finns det risk att utsättas för ”Force” attack. Brute-Force attacker går ut på att genom upprepade försök, gissa sig till lösenordet. Används det lösenord som fotboll, soligsommar eller kreativa lösenord2 blir det väldigt enkelt att göra en Brute-Force attack. [34]

Något du har

Genom att skicka något du har kan servern bekräfta din identitet [34]. Det kan vara en JWT som skickas med i varje meddelande som i Nginx JWT autentiseringsmodul, där JWT är beviset på din identitet som verifieras hos auktoriseraren.

Verifieringsprocessen har samma svaghet som något du vet, där angripare på nätverket kan få tag på informationen genom en MitM attack. Återigen kan autentiseraren inte särskilja vem som presenterat informationen, är det en angripare eller legitim användare, utan måste anta att

Brute-Force attacker däremot, är lite svårare att göra på något du har för det är oftast väldigt stora objekt som skickas över nätverket att försöka gissa sig till (se figur 4.5).

Angripare som får tag på en ID Token med MitM attacker, kan använda Brute-Force för att testa olika symmetriska nycklar för att hitta rätt signatur. Det gör det möjligt för angriparen att förfalska sina egna JWT. Problemet ligger ju inte direkt i Brute-Forcing delen på något du har utan det är MitM attacker som är svagheten, angripare som fångar upp datan från nätverket. [36]

(Figur 4.5: Exempel på en ID Token för OpenID Connect [35].)

Något du är

När det talas om något du är innebär det fysiska egenskaper som kan bekräfta identiteten, till exempel fingeravtryck, handgeometri och irismönster. Metoden är väldigt svårt för angripare att ta sig runt men det är väldigt kostsamt att införa biometriska verktyg för autentisering. [34] Ska du autentisera dig över ett nätverk så kräver det att dom fysiska egenskaperna måste konverteras om till bytes, då har vi gått från något du är till något du har. Det innebär att angripare fortfarande kan stjäla informationen på nätverket med MitM attacker.

Det finns ytterligare en egenskap, vart du är, som kan användas på de tre verifieringsprocesserna [34]. System kan analysera meddelandet och titta på avsändarens IP-adress för att bestämma om användaren ska verifieras. Låt oss tänka oss att en användare har autentiserat sig till systemet under många år och IP-adressen har alltid varit lokaliserad inom Sverige. En dag försöker en angripare autentisera sig med en IP-adress från ett annat land som presenterar korrekta användaruppgifter. Autentiseraren märker detta och blockerar användarens autentiseringsförfråga och startar en två-stegs-verifieringsprocess med att bekräfta inloggningsförsöket genom email eller sms.

Säkerhetslösningar och autentiseringsmoduler

Säkerhetslösningarna har flera olika autentiseringsmoduler men alla kan kategoriseras utifrån de olika verifieringsprocesserna som tagits upp (se figur 4.6). Alla tre verifieringsprocesser har en gemensam svaghet mot MitM attacker.

(Figur 4.6: Verifieringsprocesser och säkerhetslösningarnas autentiseringsmoduler.) Man-in-the-middle attack

Man-in-the-middle (MitM) attacker går ut på att fånga upp paket mellan klient och server och utvinna information eller manipulera trafiken [37]. MitM har funnits under en väldigt lång tid, redan under 1980 talet har datavetare försökt att motverka denna typen av attacker [38]. För att ha en säker autentiseringsprocess mot MitM attacker är det vanligt att använda sig av Transport Layer Security (TLS) eller Secure Sockets Layer (SSL) som gör om orginaldata till en krypterad form som liknar slumpmässiga data [39]. Det gör det möjligt att skicka användaruppgifter över nätverket, där angripare kan fånga upp meddelandet men får extremt svårt och dekryptera vad som har skickats.

Det finns en bra egenskap på krypteringsprotokoll, ”Perfect Forward Secret” (PFS). Innebörden av PFS är att vid varje ny session ska nya unika krypteringsnycklar skapas. Det gör att varje krypterad session skyddas från varandra, om en sessionsnyckel lyckas bli knäckt är det endast för den sessionen [40].

För att komma överens om sessionsnycklar använder krypteringsprotokollen sig av nyckelutbytes algoritmer, det är vanligt att man kallar nyckelutbytet för

MitM attacker handlar inte bara om att fånga upp paket, utan kan försöka lura klienten med att posera som servern och utföra ”Phishing” attacker som försöker lura användaren att ge ut användaruppgifterna direkt till angriparen [37]. Krypteringsprotokoll måste ha egenskapen att kunna verifiera identiteten på både klient och användare. Detta uppnås med att TLS/SSL använder sig av av certifikat som ges ut av olika betrodda certifikatmyndigheter [43].

Transport Layer Security (TLS) & Secure Sockets Layer (SSL)

TLS är ett kryptografiskt kommunikationsprotokoll som används för att skydda mot avlyssnare och ser till att förhindra manipulation av meddelanden på osäkra nätverk. TLS är egentligen en nyare version av SSL som fick ett nytt namn när Internet Engineering Task Force (IETF), en internationell organisation för standardiseringar, bestämde att den skulle döpas om. Troligtvis för att tydligt markera ingen koppling till företaget Netcraft som skapade SSL. Begreppen TLS och SSL används oftast tillsammans men det är vanligt att man talar om TLS vilket är den nyaste versionen. [41,42]

TLS 1.3 är den nyaste versionen av TLS/SSL som har fått två bra egenskaper än tidigare versioner [43, 44]. Egenskaperna är följande:

• PFS nyckelutbytesalgoritmer:

Det är krav med TLS 1.3 att använda sig av nyckelutbytesalgoritmer som uppnår PFS, det innebär att alla algoritmer som har förlitat sig på publika krypteringsnycklar är borttagna. Att använda TLS 1.3 ger alltså garanti på att det är PFS.

• 1 ”Round Trip Time”:

Med att skala av alla nyckelutbytesalgoritmer som inte uppnår PFS, har TLS 1.3 kunnat optimeras ytterligare med att ta bort en RTT som har behövts på tidigare versioner. Nu kan handskakningsprocessen göras på 1 RTT istället för 2 som sker i TLS 1.2.

Det är möjligt att använda sig av tidigare versioner som TLS 1.2 och använda sig av bra nyckelutbytesalgoritmer som uppnår PFS. Den största skillnaden är att genom att använda sig av TLS 1.3 är att handskakningen sker på 1 RTT [43, 44]. För maskiner och användare som förlitar sig på snabb kommunikation kan det vara riktigt bra. Särskilt under situationer där det tar lång tid att skicka meddelande fram och tillbaka, där en extra RTT kan göra stora negativa påverkningar på användarupplevelsen.

Ephemeral Diffie-Hellman (DHE) är ett kryptografiskt nyckelutbytesprotokoll som går att använda i både TLS 1.2 och TLS 1.3 för att komma överens om symmetriska krypteringsnycklar för en session. DHE uppnår PFS med att den genererar nya sessionsnycklar för varje ny session, vilket är en eftersökt egenskap. Det som är speciellt med just DHE är att nyckelutbytet kan göras över internet utan att hela sessionsnyckeln transporteras över nätverket. Klient och server skapar en sessionsnyckel tillsammans baserat på information från ”delar” av nycklarna. [43,45]

För att skydda autentiseringsmoudlerna mot MitM attacker behöver vi åtminstone implementera TLS/SSL kryptering, vilket är möjligt att ha på alla autentiseringsmoduler (se figur 4.7). Att inte ha TLS/SSL kryptering och endast förlita sig på autentiseringsmodulerna blir inte säkert mot MitM attacker. Det är två autentiseringsmoduler där TLS/SSL kryptering kan argumenteras vara onödig, Anonymous Authentication (IIS) och No Authentication (Apache).

(Figur 4.7: Autentiseringsmodulernas TLS/SSL support och om det nödvändigt.) Anonymous och No Authentication behöver inte direkt ha TLS/SSL kryptering så länge alla resurser är tillgängliga för alla. Det gör MitM attacker värdelösa, angriparen kan själv gå in och hämta resursen. Bloggar och nyhetssidor kräver oftast ingen inloggning för att ta del av inlägget eller artikeln, där används det någon form av anonym autentisering. Det finns undantag där anonyma användare ändå måste ha starka krypteringsprotokoll.

Anonyma användare som skriver in konfidentiell information, som kreditkortsuppgifter, måste TLS/SSL implementeras för att skydda uppgifterna på nätverket. Många

shoppinghemsidor har just anonyma användare men tillåter användare att lägga in produkter i varukorgar och lägga beställning. Hade hemsidorna inte haft TLS/SSL kryptering när du lägger din beställning, är det stor risk att angripare får tag på alla uppgifter. Har du anonyma

Analyserar vi istället vilka av säkerhetslösningarna som har officiell support för TLS 1.3, kan vi observera skillnader mellan säkerhetslösningarna (Se figur 4.8). IIS saknar officiell support för TLS 1.3, resterande säkerhetslösningarna Apache, Nginx och OAuth 2.0 har support för den senaste versionen TLS 1.3. [41,42]

(Figur 4.8: Säkerhetslösningarnas officiella support för TLS 1.3 [41,42].)

IIS har som högst support för föregångaren TLS 1.2. Det finns många kända attacker som fungerar mot TLS 1.2 som BREACH, DROWN, ROBOT och Lucky 13 [41]. Det innebär att man måste noggrant gå igenom dom olika attackerna och se till att TLS 1.2 är konfigurerat på rätt sätt.

Detta kan vara ett övervägande beslut i vilken säkerhetslösning som man ska använda i ett projekt, det blir mer säkerhetsbrister och tänka på och mer konfigureringar vid användning av IIS tills officiell support för TLS 1.3 blir möjligt. Dessutom går det långsammare i handskakningsprocessen med tidigare versioner än TLS 1.3.

5

Implementation

5.1

Arkitektur

Implementationen är gjord med en klient och server arkitektur (se figur 5.1). Klient/server arkitekturen består av en server som hanterar och lagrar resurser som konsumeras av en eller flera klienter. Servern skickar tillbaka information till klienterna i datatypen JSON.

(Figur 5.1: Klient/server arkitektur.)

HyperText Transfer Protocol Secure (HTTPS)

För att skydda användaruppgifterna som ska skickas över nätverket, används HTTPS protokollet. HTTPS försöker alltid förhandla med att använda sig av den högsta protokollversionen som både klient och server stödjer. TLS 1.2 är den protokollversion som används för implementationen.

5.2

Systemarkitektur

Klientapplikation klassdiagram:

5.3

Metoder och Verktyg

Utvecklingsmetod

Utvecklingsmetoden som har använts är Plan-Do-Check-Act (PDCA). PDCA är en väldigt enkel metod att jobba utifrån, särskilt om man gör mindre implementationen och är en ensam utvecklare. PDCA använder sig av fyra steg som upprepas under projektets gång (se figur 5.2).

(Figur 5.2: Illustrering av PDCA cykeln.)

• Plan: Sätt ut målen med projektet och ta fram en implementeringsplan.

• Do: Börja utföra implementeringsplanen. Skriv ner problem som uppstår på vägen. • Check: Felsök igenom alla problem som skrivits ner.

• Act: Ta fram hur implementeringsplanen behöver ändras för att ta bort felen som har uppstått.

Programmeringsverktyg

Visual Studio Community 2017 är använd som utvecklingsmiljö och programspråket som har använts är C#.

Plan Do

Check Act

5.4

Resultat

API: n är konfigurerad med IIS Express, en lättviktig version av IIS. Den är mycket mer hanterbar och vänligare för enkla implementationer. Klient och server har endast existerat på samma maskin, där kommunikation har skett mellan ”localhosts”.

För att konfigurera API: n att använda sig av HTTPS, för att kunna utnyttja TLS, finns det certifikatkrav. Självsignerade certifikat har använts och lagts in i ”Trusted Root Certificates” mappen i datorn för att göra ”localhost” betrodd. Normalt sett behöver man köpa ett certifikat från en certifikatmyndighet, men för utvärderingssyfte är det enklare att använda sig av egna betrodda certifikat.

API: n använder sig av autentiseringsmodulen Basic Authentication för att autentisera användare till applikationen. För att en användare ska kunna göra en förfrågan till olika ”Controllers” som är markerade med [Authorize] attributen, måste användarnamn och lösenord inkluderas i meddelandet. API: n verifierar att användaren är legitim med att kolla upp att användarnamnet och lösenordet stämmer överens med vad som är sparat på servern i en ”Users” lista.

Klienten är en konsolapplikation, där användaren kan skriva in kommandon för att skicka olika förfrågningar mot API: n. Det användaren skriver in i konsolen, skickas vidare till en funktion som bryter ner strängen i olika variabler. Den uppdelade datan skickas vidare till ”Command” klassen som är ansvarig för att köra olika kommandon och kontrollera om användaren har skrivit in användarnamn och lösenord till applikationen. Vid avsaknad av användaruppgifter promptar Command klassen användaren att skriva in sina uppgifter, innan processen kan fortsätta.

I figur 5.3 ser vi hur användaren har skrivit in kommandot ”0 users”, vilket representeras som en GET förfrågan på användartabellen hos API: n. Command klassen märker att användarnamn och lösenord inte har givits, och promptar användaren att skriva in sina uppgifter.

När användaruppgifterna är ifyllda så ska GET förfrågan skickas iväg. För att skicka och ta emot förfrågningar till API: n används ”HttpClient” objektet, vilket kan göra asynkrona förfrågningar till servern. Användaruppgifterna läggs in i HttpClient objektets ”Authorization Header”, vilket gör att varje förfrågan som vi skickar till servern kommer ha med användarnamnet och lösenordet. Sist men inte minst görs det en asynkron GET request till servern på adressen ”https://localhost:44335/users”.

(Figur 5.4: Resultatet från servern.)

GET förfrågan hamnar hos API:n och den märker att resursen som klienten försöker få tag i är skyddad med [Authorize] attributen. API: n kallar på ”BasicAuthenticationHandler” som tar ut användarnamnet och lösenordet från Authentication Headern och passar uppgifterna vidare till en autentiseringsfunktion som kontrollerar om användaren existerar i systemet.

När API: n kan verifiera att användaren är legitim, skickar den tillbaka användarna i systemet. Konsolapplikationen tar emot svaret från API: n vilket är uppgifter om användare i systemet i ett JSON format. Lösenordet har exkluderats, vilket har hanterats på serversidan. Uppgifterna skickas vidare till en funktion som konstruerar upp en fin tabell i konsolapplikationen för användaren (Se figur 5.4).

6

Slutsats & Diskussion

Utvecklare måste ta hänsyn till flera olika säkerhetsbrister för att skapa säkra publika

applikationer. Det kräver noggrann planering vid utvecklingsstadiet i projekten men även att befintliga projekt kontrolleras periodvis efter nya förändringar. Allt som finns tillgängligt och räknas som säkert idag kan bli osäkert i framtiden, det enda man kan göra är att försöka ligga i framkanten och aldrig sluta söka ny säkerhetskunskap.

Organisationer som OWASP, har startats med mål att förbättra säkerheten för applikationer runt i världen, där utvecklare måste upplysas om potentiella säkerhetsproblem och få mer kunskap inom säkerhetsområdet. OWASP top 10 är ett dokument som upplyser om dom topp 10 säkerhetsbristerna med publika applikationer. Organisationen vill att utvecklare ska använda dokumentet för att se till att applikationen är säkrat mot just dessa potentiella säkerhetsbrister.

Analys av en existerande rapport där IIS 10.0 och Apache 2 testades mot HTTP Flood och HTTP SYN attacker observerades det skillnader mellan dom två säkerhetslösningarna. IIS 10.0 har bäst mätbart skydd mot HTTP Flood attacker och Apache 2 hade lite bättre responstid under HTTP SYN attacker. IIS under SYN attacker hade inte så avsevärt högre responstider än Apache, men Apache under Flood attack visade extremt höga responstider och skickade ut felmeddelanden. Utifrån den observationen härleder vi att IIS 10.0 är en mycket bättre säkerhetslösning för att hantera pågående HTTP Flood och HTTP SYN attacker än Apache 2.

Nginx saknar modul för att hantera DDoS attacker, men har verktyg för att övervaka

förfrågningar och även kommunicera med en egenutvecklad hanteringsprocess. Det blir därför svårt att jämföra säkerhetslösningen med IIS och Apache, men det kan diskuteras huruvida en egenutvecklad hanteringsprocess är bättre än existerande. Fördelar med att utveckla en egen lösning är att hantera angripare på valfritt sätt. IIS och Apaches DDoS moduler är enligt mig inte jättekomplicerade att implementera själv, det som är viktigt är att bokföringen av

förfrågningar görs på ett effektivt sätt med minimala resurser och bra indexering för snabba sökningar. Nackdelarna med att utveckla en hanteringsprocess själv är att det finns mer risk att det blir fel konfigurerat (OWASP nummer 6).

Delar vi upp säkerhetslösningarnas autentiseringsmoduler i kategorierna, något du vet, något

du har och något du är observerar vi att oavsett kategori finns det en gemensam svaghet mot

MitM attacker. Angripare kan fånga upp informationen när autentisering sker över ett nätverk vilket gör att autentiseringsmodulerna inte är säkra av sig själva med undantag för

TLS 1.3 är den nyaste och effektivaste krypteringsprotokollet som autentiseringsmodulerna bör använda sig av för att skydda sig mot MitM attacker. Det kräver endast 1 RTT för TLS 1.3 att komma överens om sessionsnycklar, samt alla nyckelutbytesalgoritmer skapar unika sessionsnycklar för varje ny session (PFS). Det skyddar alla tidigare sessioner för att bli dekrypterade om en angripare får tag på en krypteringsnyckel i framtiden.

IIS är den enda av säkerhetslösningarna som saknar officiell support för TLS 1.3. Det innebär att handskakningsprocessen tar längre tid än andra säkerhetslösningar och det sätts ansvar på utvecklaren att konfigurera TLS 1.2 för att bli skyddad mot vanliga attacktyper. Detta kan vara avgörande i vilken säkerhetslösning blir vald till projektet där kommunikation sker över långa avstånd eller applikationer som förlitar på många kortlivade sessioner samt att TLS 1.2 har säkerhetsbrister som inte finns i TLS 1.3.

6.1

Sociala och ekonomiska implikationer

Rapporten gör det enklare för uppdragsgivaren att välja bra säkerhetslösningar till nya och befintliga projekt. Det sparar företaget pengar, tid och andra resurser att kunna välja snabbt en säkerhetslösning till projektet och ha en säker produkt för att ge ut till samhället.

I ett miljöperspektiv kan det bli mindre utvecklingsmöten angående säkerhet. Projektet har utredda säkerhetslösningar vilket innebär att det går och göra snabbare beslut och kan på så sätt minska antalet utvecklingsmöten. Färre möten kan innebära mindre resande för arbetare eller kunder mellan kontor.

Företaget kan utveckla nya säkra API:er till kunder som använder sig av traditionella fysiska lagringsmetoder (papper) att gå över till en mer miljövänlig hantering med webbaserade system, kan säkerheten garanteras så blir det enklare att övertyga kunderna. Säkra applikationer kan utvecklas till sjukhus för att skydda patientintegriteten, till exempel att säkra patientjournaler från angripare utifrån. Möten mellan läkare och patient skulle kunna göras på ett säkert sätt över internet vilket låter som en bra idé i dagsläget.

Projektet kan vidareutvecklas med att gå in djupare på säkerheten och säkerhetsmodulerna som kan leda till nya säkerhetsbrister. Vid nyfunna säkerhetsbrister kan också metoder utvecklas för att åtgärda dom, vilket kan leda till nya projekt och lösningar inom säkerhet som kan ges ut till samhället.

Projektet är även till för att upplysa om säkerhetsbrister, vilket gör att läsare kanske tar med sig ny kunskap och kan skapa säkrare applikationer. OWASP jobbar just mot att skapa en gemensam front för att kämpa för en säkrare applikationsframtid och en strategi är att upplysa om säkerhetsbrister, precis som det här projektet gör.

6.2

Projektets utvecklingspotential

Projektet har god utvecklingspotential. Det finns väldigt många verktyg och lösningar på säkerhetsbrister ute på marknaden som är intressanta att utreda. Säkerhetslösningarna som tas upp i projektet har också andra moduler och säkerhetsskydd. Jag har ibland känt att det har varit orättvist att inte ta upp alla säkerhetsmoduler, men det är inte realistiskt att kunna hinna fördjupa sig i allting på den korta tiden man har. Jag känner att auktorisering är något som jag verkligen ville gå in djupare på och jag har intressanta utredningsvinklar i det området. Det känns lite surt att inte ha fått gå in djupare i det området, om projektet ska utvecklas vidare är det definitivt det området som ska undersökas först.

Projektet kan utvecklas till att inkludera olika slutprodukter för att kunna ge

rekommendationer på vilka säkerhetslösningar som fungerar bäst för respektive slutprodukt. Jag började med det lite med i utredningen att TLS 1.3 är mycket snabbare i

handskakningsprocessen vilket passar bra för projekt där det är viktigt med snabba uppkopplingar. Mer fördjupad analys i det området hade varit en potentiell utveckling av projektet, särskilt om auktoriserings hade undersökts på säkerhetslösningar.

Implementationen känner jag kan utvecklas vidare med att prova olika

autentiseringsprocesser, där man kan mäta responstid, meddelandestorlek och ytterligare egenskaper mellan dom. Det man kan göra är att jämföra autentiseringsmodulerna utifrån statistik från egna tester. Det tycker jag låter väldigt intressant att utveckla vidare och kan göra det ännu enklare att välja autentiseringsmodul om data presenteras.

Det finns många automatiserade verktyg tillgängligt online som kan hjälpa att testa

applikationen mot säkerhetsbrister. Vidareutveckling av projektet skulle kunna vara att testa verktygen mot dom olika säkerhetslösningarna för att se vilka hittar mest fel. Automatiserade verktyg är någonting som kan vara väldigt bra och ha när man utvecklar projekt. Särskilt om verktygen kan flagga alla säkerhetsbrister, det gör att man kan utveckla säkra applikationer på väldigt kort tid. Har man den möjligheten att få hitta alla säkerhetsbrister med en specifik säkerhetslösning känns det rätt så självklart vad för säkerhetslösning man ska välja.

Maskininlärning är väldigt populärt nuförtiden och jag tror att det kan användas i detektering och hantering av pågående DDoS attacker. Det kanske går att vidareutveckla en DDoS

lösning på Nginx, där man använder sig av maskininlärning för att känna igen om systemet är under attack. Intressant och kunna jämföra en sådan hanteringsprocess med egna tester mot dom befintliga DDoS modulerna.

7

Reflektion kring eget lärande

7.1

Kunskap och förståelse

Jag känner att jag har lärt mig mycket om säkerhet, vilka områden som blir mest angripna och vad man kan göra för att säkra upp sin applikation. Jag känner att jag har fått en förståelse för de olika krypteringsprotokollen, först hur man kan definiera att ett protokoll är säkert och förståelsen att med åren som går kommer det nya standarder och att man alltid måste ligga i framkanten med tekniken för att inte hamna efter.

Jag känner att det finns mycket mer och fördjupa sig i inom säkerhetsområdet för det finns mycket material tillgängligt, det har varit svårt att avgränsa arbetet med att det finns så mycket viktigt och gå igenom. Ska projektet vidareutvecklas känner jag att en bra strategi är att gå in djupare på säkerhetslösningarna och alla processer och moduler som erbjuds, framförallt inom auktorisering vilket jag höll på med rätt så mycket men beslutade att avgränsa bort. Det är väldigt enkelt att gå in på nya områden och börja upplysa och

undersöka, men att avsluta en ett nytt område tar rätt så mycket tid vilket jag definitivt märkte av i dom två utbredningsområdena jag gått igenom.

Intressant är att jag har tydligt märkt att min kunskap har ökat inom säkerhetsområdet när jag har gjort en genomgång på rapporten. Många olika delar blev ändrade sista veckorna, för jag hade lärt mig så mycket mer och kunde göra bättre förklaringar. Några delar var lite svårare att förstå men med viljekraft och en panna kaffe kommer man alltid framåt.

7.2

Färdighet och förmåga

Säkerhet är ett väldigt djupt och stort ämne, men jag tycker att rapporten har formulerat säkerhetsproblem och avgränsat på ett bra sätt. Arbetet har en bra struktur och är begripligt för läsare oavsett en bakgrund inom säkerhet, samtidigt som rapporten går in på

säkerhetsproblem i en fördjupad nivå. Jag har försökt att skriva rapporten så tydligt som möjligt för att dela med mig av den kunskapen jag har funnit under projektets gång. Utredningen på säkerhetslösningarna har gjorts med vetenskaplig litteratur och framgår tydligt med referenser, vid avsaknad av vetenskaplig litteratur har jag försökt hitta bra källor.

Mycket tid har lagts för att skaffa djup förståelse om olika moment för att säkerställa att det som tas upp i rapporten är sant, jag har försökt vara försiktig med att dra egna slutsatser och har alltid försökt att hitta referenser på saker jag vill få sagt. Informationen har försökts tas in från olika källor för att kunna förmedla metoder och tekniker på bästa möjliga sätt.

Jag tycker att rapporten har en bra struktur och begriplig för läsare oavsett bakgrund inom säkerhet. Rapporten ger förståelser om många säkerhetsproblem som finns med publika webbapplikationer och försöker förklara det på ett bra sätt. Jag har försökt att få till en liten sammanfattning på nya begrepp och metoder som tas upp, vilket jag tycker är en bra metod för att skapa en bra rapport.

7.3

Värderingsförmåga och förhållningssätt

Jag tycker att arbetet visar utifrån ett företagsperspektiv vad som är viktigt och tänka på med publika API:er och upplyser flera relevanta säkerhetsproblem. Det är inte bara företaget som får nytta av projektet, utan samhället gynnas av att lära sig om befintliga säkerhetsproblem och dom metoder och tekniker som finns idag och huruvida dom är tillräckligt säkra. Många av säkerhetslösningarna används av väldigt många människor världen runt.

Jag tycker att rapporten visar kunskap om flera delområden inom säkerhet och förklarar det på ett bra professionellt sätt. Röda tråden i arbetet gör det behagligt att läsa och följa rapporten från start till slut.

Jag har haft möten med uppdragsgivaren och vi har tillsammans gjort beslut gällande säkerhetslösningar som ska utredas, där jag också har förklarat mina egna avgränsningsbeslut och förmedlat intressanta utredningsvinklar. Det har varit ett kontorsmöte, annars så har kommunikationen skett med Microsoft Teams, detta på grund av den oroliga tiden i världen man har utfört sitt arbete under.

8

Referenser

1. Wittern, E.. "Web APIs - Challenges, Design Points, and Research Opportunities: Invited

Talk at the 2nd International Workshop on API Usage and Evolution (WAPI ’18)," 2018 IEEE/ACM 2nd International Workshop on API Usage and Evolution (WAPI),

Gothenburg, Sweden, 2018, ss. 18-18.

2. Wikipedia, Application Programming Interface, CA-US: Wikipedia. 2020. Besökt: 2020-05-30

URL: https://en.wikipedia.org/wiki/Application_programming_interface

3. Focardi, R.; Luccio, F.L.; Steel, G.. ”An Introduction to Security API Analysis”,

Foundations of Security Analysis and Design VI. 2011, vol 6858, Berlin: Springer.

DOI: 10.1007/978-3-642-23082-0_2

4. The OWASP Foundation, The Ten Most Critical Web Application Security Risks, 2017. Hämtad 2020-05-11.

URL: https://owasp.org/www-project-top-ten/OWASP_Top_Ten_2017/

5. Chandrasekhar, R.; Mardithaya, M.; Thilagam, S.; Saha, D.. ”SQL Injection Attack Mechanisms and Prevention Techniques”, Advanced Computing, Network and Security, vol 7135, 2011, ss 524–533.

DOI: 10.1007/978-3-642-29280-4_61

6. Netcraft, April 2020 Web Server Survey, 2020. Besökt 2020-05-12.

URL: https://news.netcraft.com/archives/2020/04/08/april-2020-web-server-survey.html 7. Netcraft, Januari 2020 Web Server Survey, 2020. Besökt 2020-06-09

URL: https://news.netcraft.com/archives/2020/01/21/january-2020-web-server-survey.html

8. Google Identity Platform, Using Oauth 2.0 to Access Google APIs, 2020. Besökt 2020-05-22.

URL: https://developers.google.com/identity/protocols/oauth2 9. Amazon, Login with Amazon Documentation. WA-US: Amazon.

Besökt 2020-05-22.

https://developer.amazon.com/docs/login-with-amazon/documentation-10. Microsoft Docs, Introduction To IIS, WA-US: Microsoft Corporation. 2007. Besöktes 2020-05-14.

URL: https://docs.microsoft.com/en-us/iis/get-started/introduction-to-iis/introduction-to-iis-architecture

11. DNSstuff, Ultimate Guide to IIS Server: What is IIS? 2020 IIS Tutorial, ATX-US: SolarWinds, 2020.

Besöktes: 2020-05-22

URL: https://www.dnsstuff.com/windows-iis-server-tools#top

12. Microsoft Docs, Authentication, WA-US: Microsoft Corporation. 2016. Besöktes 2020-05-23.

URL:

https://docs.microsoft.com/en-us/iis/configuration/system.webserver/security/authentication/

13. Microsoft Docs, Anonymous Authentication, WA-US: Microsoft Corporation. 2016. Besöktes 2020-05-23.

URL:

https://docs.microsoft.com/en-us/iis/configuration/system.webserver/security/authentication/anonymousauthentication 14. Microsoft Docs, Basic Authentication, WA-US: Microsoft Corporation. 2016.

Besöktes 2020-05-23.

URL:

https://docs.microsoft.com/en-us/iis/configuration/system.webserver/security/authentication/anonymousauthentication 15. Microsoft Docs, Client Certificate Mapping Authentication, WA-US: Microsoft

Corporation. 2016. Besöktes 2020-05-23.

URL:

https://docs.microsoft.com/en-us/iis/configuration/system.webserver/security/authentication/clientcertificatemappingaut hentication

16. Microsoft Docs, Digest Authentication, WA-US: Microsoft Corporation. 2016. Besöktes 2020-05-23.

URL:

https://docs.microsoft.com/en-us/iis/configuration/system.webserver/security/authentication/digestauthentication 17. Microsoft Docs, IIS Client Certificate Mapping Authentication, WA-US: Microsoft

Corporation. 2016. Besöktes 2020-05-23.

URL:

https://docs.microsoft.com/en-us/iis/configuration/system.webserver/security/authentication/iisclientcertificatemappinga uthentication/

18. Microsoft Docs, Windows Authentication, WA-US: Microsoft Corporation. 2016. Besöktes 2020-05-23.

URL:

19. Microsoft Docs, IIS 8.0 Dynamic IP Address Restrictions, WA-US: Microsoft Corporation. 2012.

Besöktes: 2020-05-22.

URL: https://docs.microsoft.com/en-us/iis/get-started/whats-new-in-iis-8/iis-80-dynamic-ip-address-restrictions

20. MDN Web Docs, X-Forwarded-For, MTV-US: Mozilla Corporation. 2019. Besöktes: 2020-05-22

URL: https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/X-Forwarded-For 21. Nginx, What is NGINX? How different is it from Apache (for example)?, CA-US: NGINX,

inc. Besöktes: 2020-05-23.

URL: https://www.nginx.com/faq/what-is-nginx-how-different-is-it-from-e-g-apache/ 22. Nginx, What is NGINX plus?, CA-US: NGINX, inc.

Besöktes 2020-05-23.

URL: https://www.nginx.com/products/nginx/ 23. Nginx, Nginx Documentation, CA-US: NGINX, inc.

Besöktes 2020-05-23.

URL: http://nginx.org/en/docs/

24. Nginx, ”Setting up JWT Authentication”, CA-US: NGINX, int. Besökt: 2020-05-24.

URL: https://blog.logrocket.com/jwt-authentication-best-practices/

25. Apache HTTP Server Project, About Apache, MA-US: Apache Software Foundation. Besöktes 2020-05-23.

URL: https://httpd.apache.org/ABOUT_APACHE.html

26. Apache HTTP Server Project, Apache Module mod_authn_core, MA-US: Apache Software Foundation. Besöktes 2020-05-23.

URL: https://httpd.apache.org/docs/2.4/mod/mod_authn_core.html#authtype

27. Apache HTTP Server Project, Apache Module mod_auth_form, MA-US Apache Software Foundation. Besöktes 2020-05-23.

URL: https://httpd.apache.org/docs/2.4/mod/mod_auth_form.html

28. PheonixNAP, Defend Against DoS & DDoS On Apache With Mod_evasive, AZ-US: PheonixNAP. 2019. Besöktes 2020-05-23.

URL: https://phoenixnap.com/kb/apache-mod-evasive 29. Wikipedia, LAMP, CA-US: Wikipedia. 2018

31. Zebari, R.R.; Zeebaaree, S.R.M.; Jacksi, K..”Impact Analysis of HTTP and SYN Flood DDoS Attacks on Apache 2 and IIS 10.0 Web Servers”, 2018 International Conference on

Advanced Science and Engineering (ICOASE), Duhok, 2018, ss 156-161.

DOI: 10.1109/ICOASE.2018.8548783

32. Cloudfare, HTTP Flood Attack, CA-US: Cloudflare, Inc. Besöktes: 2020-05-23.

URL: https://www.cloudflare.com/learning/ddos/http-flood-ddos-attack/ 33. Cloudfare, SYN Flood Attack, CA-US: Cloudflare, Inc.

Besöktes: 2020-05-23.

URL: https://www.cloudflare.com/learning/ddos/syn-flood-ddos-attack/

34. Kizza, Joseph Migga. ”Authentication”, Guide to Computer Network Security, Cham, Schweiz: Springer. 2017.

DOI: 10.1007/978-3-319-55606-2_10

35. Tyler Rosonke, ”JWT Hacking 101”. KS-US: TrustFoundry. 2017 Besöktes: 2020-06-11

URL: https://trustfoundry.net/jwt-hacking-101/

36. Sakimura, N; NRI; Bradley, J; Ping Identity; Jones, M; Microsoft; et al. ”OpenID Connect

Core 1.0 errata set 1.”, 2014.

Besöktes: 2020-06-11.

URL: https://openid.net/specs/openid-connect-core-1_0.html#id_tokenExample

37. Ordean, M. & Giurgiu, M.. ”Towards securing client-server connections against man-in-the-middle attacks”. 2012 10th International Symposium on Electronics and

Telecommunications. 2012. ss 127-130.

DOI: 10.1109/ISETC.2012.6408076

38. Lamport, Leslie. ”Password Authentication with insecure communication”,

Communications of the ACM, 1981, vol 24, no 11, ss 770-722.

DOI: 10.1145/358790.358797

39. Yang, Y.; Kang, C.; Gou, G.; Xiong, G.. ”TLS/SSL Encrypted Traffic Classification with Autoencoder and Convolutional Neural Network”, 2018 IEEE 20th International

Conference on High Performance Computing and Communications; IEEE 16th International Conference on Smart City; IEEE 4th International Conference on Data Science and Systems (HPCC/SmartCity/DSS), 2018, ss 362-369.

DOI: 10.1109/HPCC/SmartCity/DSS.2018.00079

40. Thomas Wu, ”The Secure Password Protocol”, CA-US: Stanford University. 1998. URL: https://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.81.7567

41. Ivanov, O.; Ruzhentsev, V.; Oliynykov, R.. "Comparison of Modern Network Attacks on

TLS Protocol" 2018 International Scientific-Practical Conference Problems of

Infocommunications. Science and Technology (PIC S&T), 2018, ss 565-570. DOI: 10.1109/INFOCOMMST.2018.8632026

42. Cloudfare, ”What is Transport Layer Security (TLS)?”, CA-US: Cloudfare, inc. Besöktes: 2020-05-29

URL: https://www.cloudflare.com/learning/ssl/transport-layer-security-tls/

43. Sullivan, Nick, ”A Detailed Look at RFC 8446 (a.k.a. TLS 1.3)”, CA-US: Cloudfare, inc. 2018. Besöktes: 2020-05-31

URL: https://blog.cloudflare.com/rfc-8446-aka-tls-1-3/

44. SLLTrust, ”The Complete and Easy Guide to TLS1.3”, Australien: SSLTrust. 2019 Besöktes: 2020-05-31

URL: https://www.ssltrust.com.au/help/setup-guides/complete-guide-to-tls-1-3 45. Scott Helme, ”Perfect Forward Secrecy – An Introduction”, 2014.

URL: https://scotthelme.co.uk/perfect-forward-secrecy/

46. Campbell, B.; Ping Identity; Bradley, J.; Yubiko; Sakimura, N.; Nomura Research Institute; et al. ”OAuth 2.0 Mutual TLS Client Authentication and Certificate-Bound

Access Tokens”, RFC 8705. 2020.

Besöktes: 2020-05-31