Vad är ett mobilapplikationstest?

I takt med att användandet av mobila enheter och dess applikationer ökar har säkerhetstester av dessa blivit ett allt vanligare uppdrag för våra pentestare. I denna artikel tittar vi närmare på hur ett mobilapplikationstest går till och vilka de vanligaste säkerhetshålen vi hittar är.

Innan den första iPhonen presenterades för snart 15 år sedan var det knappast någon som kunde förutspå att mobila enheter skulle stå för över 67 % av all trafik på internet år 2020. Inte nog med att vi kan göra allt mer eller mindre direkt med hjälp av de små datorer vi ständigt bär omkring i fickan; de innebär också en centralisering av vår digitala identitet, där tjänster såsom BankID har gjort smartphonen till en nyckel till vårt digitala liv. De är också digitala GPS-sändare med konstant information om var vi befinner oss, vad vi gör och innehåller all vår digitala kommunikation med vår omvärld. 

Att de utöver detta även är utrustade med accelerometrar, kameror och mikrofoner, och dessutom redan finns planterade i allas fickor, har transformerat denna beräkningsmässigt beskedliga manick till den ideala spionutrustningen och ett av de mest åtråvärda målen för hackare. 

Den enorma genomslagskraften i kombination med allas vår egen relation till smartphones gör att hotet mot mobila operativsystem knappast behöver förankras i statistik och varnande siffror. I denna artikel ska vi istället gå igenom hur vi på Sentor säkerhetstestar mobilapplikationer och vilka de vanligaste säkerhetshålen vi hittar är.

Mobilapplikationer kontra webapplikationer

Som i all nätverksbaserad teknologi har mobiltelefoner både en klient- och en serversida. Medan serversidan kan se precis likadan ut som servern gör för en webbapplikation, är det desto större skillnad mellan klienterna; alltså den kod som körs i webbläsaren gentemot den som körs på telefonen.

Medan våra webbläsare bygger på ett lapptäcke av teknologier som lagts omlott över varandra sedan 90-talet kom, byggdes smartphones från grunden i ett långt senare skede, med ett mycket större fokus kring säkerhet. Både Android och iOS bygger i hög utsträckning på separation av processer, där varje applikation körs i en egen så kallad sandlåda – utrymmen för processer som är strikt separerade från varandra och designade för att inte läcka data mellan varandra. Varje sandlåda kör inte bara som en egen process, utan också som en egen unik användare.

Även om denna användarisolering är en bättre säkerhetsmässig utgångspunkt än den traditionella separationen som finns i andra operativsystem kan det som i alla system uppstå problem, och vi kommer i artikeln att gå igenom de vanligaste.. 

Hur ett test går till

Ett mobilapplikationstest från Sentor utgår från OWASP Mobile Top 10 som består av de tio vanligaste bristerna hos mobilapplikationer:

 För ett typiskt pentest av en mobilapplikation brukar M8-M10 utelämnas. För en applikation som är publikt tillgänglig via Google Play och App Store kommer en angripare alltid kunna analysera och modifiera applikationen på ett eller annat sätt, för att sedan lura användare att installera den skadliga versionen. Denna typ av angrepp är baserat på phishing, vilket generellt sett är exkluderat vid ett pentest. Däremot kan en tjänst som inkluderar phishing-metoder, såsom Red Team Testing, identifiera dessa typer av sårbarheter. För ett mobilapplikationstest återstår därmed punkt M1-M7. 

M1: Improper Platform Usage

Denna brist berör felaktig användning av funktioner hos den mobila enhetens operativsystem (Android/iOS) med påverkan på applikationens säkerhet, eller att inbyggda säkerhetsfunktioner ej används korrekt eller inte alls. Exempel på denna brist kan vara att applikationen har onödigt höga behörigheter eller exponerar funktionalitet som skulle kunna utnyttjas av en skadlig applikation som körs på samma enhet. 

M2: Insecure Data Storage

Allvarliga säkerhetshot kan uppstå om känslig information lagras felaktigt, vilket kan leda till att en obehörig part kan komma åt den. Om en mobilapplikation lagrar känslig data i klartext kan denna röjas genom att en annan applikation kommer åt den, särskilt om informationen sparas på disk där andra applikationer vanligtvis har läsbehörighet.

M3: Insecure Communication

Osäker kommunikation innebär att nätverkstrafiken mellan mobilapplikationen och backendservrarna inte är krypterade. Mobila enheter är särskilt utsatta om de befinner sig på ett offentligt WiFi-nätverk, exempelvis på ett café eller en flygplats, då detta ökar risken för att trafiken är avlyssnad. 

M4: Insecure Authentication

Om det finns brister i applikationens autentisering kan en angripare potentiellt utnyttja funktionalitet som endast är tillgänglig för autentiserade användare i skadligt syfte. Exempelvis kan denna brist bestå av att det går att utföra anrop mot applikationens API utan att autentisera sig.

M5: Insufficient Cryptography

Kryptering används som bekant för att skydda information, men för att uppnå sitt syfte krävs det att det inte finns några brister i krypteringsprocessen i sig. Exempel på brister som uppstår är användning av sårbara krypteringsalgoritmer eller sårbara implementationer av algoritmerna. Det förekommer även att krypteringsbilbioteket är fritt från brister, men att koden i applikationen som använder biblioteket använder det felaktigt, vilket leder till att sårbarheter uppstår.

M6: Insecure Authorization

Brister i auktorisering av användare kan förekomma, vilka är viktiga att skydda sig emot för att undvika att angripare eller illasinnade användare kan tillskansa sig obehörig information. Ett exempel på denna brist är ett sårbart API där en användare kan komma åt andra användares information genom att exempelvis byta ID:t på ett filnamn, en så kallad insecure direct object reference (IDOR)-brist.

M7: Client Code Quality

Denna sårbarhet betecknar olika typer av säkerhetsbrister i koden till applikationen. Dessa brister kan bland annat innefatta olika typer av injektionsattacker såsom SQL injection, cross-site scripting (XSS) eller buffer overflow.

Så kan vi hjälpa dig att stärka säkerheten i din mobilapplikation

Vår specialistgrupp som fokuserar på just mobilapplikationer utför åtskilliga tester av detta slag varje år. Under ett mobiltapplikationstest genomförs både så kallade statiska analyser, där antingen källkod eller den dekompilerade applikationen analyseras, såväl som dynamiska analyser där testerna utförs medan koden exekveras. Testerna inkluderar generellt även API:et och kan med fördel kombineras med webbapplikationstester. Hör av dig, så berättar vi mer.