Säkerhetstestning av mobila applikationer

2013-12-03 Artikelbanken Test Läst 7431 gånger

Allt fler tjänster blir tillgängliga i våra mobiler. Det ger många fördelar både för privatpersoner och företag men det ger också upphov till nya utmaningar vad gäller säkerhet, i synnerhet då området är förhållandevis nytt och inte har uppnått samma mogenhet som webapplikationer. Den här artikeln beskriver hur man som testare kan bidra till ökad säkerhet för mobilapplikationer genom att på ett ganska enkelt sätt utföra säkerhetstestning i meddelandegränssnittet mellan mobil och server. Artikeln ger också en lista med idéer om vad man kan testa i gränssnittet.

Bakgrund

Gemensamt för mobila appar och webapplikationer är att serversidan är öppen för vem som helst att anropa, vanligtvis via http-anrop. Det betyder att logiken på serversidan inte kan förutsätta att det verkligen är den avsedda klienten som anropar utan det kan lika väl vara en angripare som försöker efterlikna klienten i syfte att komma över otillbörlig information eller otillbörliga fördelar. Kommunikationen sker dessutom över ett nätverk som man inte kontrollerar och som kan avlyssnas.

Säkerhetsmekanismer i mobillösningar

En mobillösning har ett antal mekanismer för att se till att kommunikationen är säker så att det går att utföra exempelvis bankärenden utan att vara orolig. Det mest självklara är att kryptera all känslig information. På en websida syns detta genom att adressen (URL) börjar med https. För en mobilapp finns inget lika enkelt sätt att kontrollera om kommunikationen är krypterad. Https-kryptering anses vara tillförlitlig och omöjlig att knäcka, förutsatt att den körs på uppgraderad programvara, så på den punkten kan vi vara lugna.

Mobilapplikationen på serversidan måste kunna säkerställa att den kommunicerar med rätt klient där rätt person har loggat in. Det löses genom att klient och server under inloggning kommer överens om en gemensam hemlighet som används i anropen. Hemligheten kan vara ett större slumptal som ingen utomstående kan gissa.

Eftersom serversidan inte kan förutsätta att anropen kommer från en klient måsta alla indata och behörigheter kontrolleras för varje anrop. Det räcker inte att kontroller sker i klienten.

Servern bör också ha en spärr för att det inte skall gå att upprepa liknande anrop många gånger. Om inte kan en angripare exempelvis knäcka PIN-koder eller lösenord genom upprepade försök.

Ett vanligt angrepp är att försöka injicera programkod, till exempel html eller sql, i textinmatningsfält. Angriparen hoppas då att servern exekverar det inmatade programmet, eller att den gör programsnutten tillgänglig i en html-sida där en ovetande användare klickar på den och därigenom kör den skadliga koden i sin läsare. Försvaret mot kodinjektion kan vara att förbjuda vissa styrtecken som förekommer i programkod, såsom <>/;´”, eller att se till att lagra all text på ett format som gör att den inte går att exekvera.

Testmiljö för säkerhetstestning av mobilapp

För att kunna studera kommunikationen till och från mobilapplikationen behövs ett analyserande proxyverktyg. Sådana finns att ladda ner gratis och är förhållandevis enkla att installera och använda. Med hjälp av verktyget går det bland annat se alla anrop och svar. Det går också att fånga upp och ändra anrop eller upprepa anrop med ändrade parametrar.

Verktyget installeras på en dator med Wifi. Genom att ändra telefonens inställningar styrs trafiken om så att den istället för att gå över mobilnätet kommunicerar med datorn via Wifi och därigenom passerar proxyn. För att kunna studera krypterad https-trafik skapar man ett eget certifikat med hjälp av proxyverktyget och för över det till mobilen. Mobilen kan komma att klaga lite om att den inte känner igen certifikatet eftersom det inte kommer från en känd certifikatutfärdare. Den varningen går att kvittera bort.

Det här skall naturligtvis bara göras i testmiljön! Vi avråder för att göra motsvarande saker i produktion utan tillåtelse, då det kan anses vara försök till intrång. Dessutom är det i vanliga fall en riktigt dålig idé att acceptera ett certifikat som inte kommer från betrodd utfärdare. Vi skall snart se varför.

Testfall och testidéer

Efter att ha satt upp testmiljön och verifierat att kommunikationen syns i proxyn kan vi påbörja riktigt spännande testning.

Först är det lämpligt att verifiera att all känslig information verkligen går krypterat med https. Det ser man genom att gå igenom alla funktioner i appen och studera trafiken. Alla anrop med känslig information skall ha en URL som börjar med https, exempelvis:

POST https://secure.reqtest.com/WebServices/ProjectSelector.asmx/GetProjects HTTP/1.1

Trots att både server och klient kommunicerar krypterat kan vi tack vare tricket med det konstgjorda certifikatet se all kommunikation i klartext i proxyn: anropshuvud, innehåll och svar. Anropen kan innehålla intressanta saker som personnummer, PIN-koder, medlemsnummer eller kontonummer.

Nu förstår vi anledningen till att man i vanliga fall inte skall läsa in okända certifikat: En angripare som skapat certifikatet och placerar sig mellan klient och server kan läsa det som egentligen skall vara krypterat. För testaren är all denna klartextinformation hur som helst en guldgruva. Genom att fånga upp och ändra den går det att testa om serversidan verkligen har de kontroller som behövs eller om den okritiskt förutsätter att klienten anropar med rätt argument.

Om till exempel mobilappen anropar servern med kundnummer som argument i syfte att leta upp kundens information kan man fånga meddelandet i proxyn och byta till ett kundnummer för en annan person. Om kontonummer överförs kanske man kan byta till annan testkunds kontonummer. Det går också att försöka gå runt olika begränsningar som finns implementerade i appen. Om appen till exempel har en meny med heltal mellan 1 och 3 är det en bra idé att prova med heltal som ligger utanför intervallet för att se ifall man kan komma över information man inte borde se.

Här kommer fler exempel på intressanta saker att testa:

  • Verifiera att anrop förkastas ifall de saknar den gemensamma hemlighet som identifierar en inloggad session (sessions ID). Detta verifieras genom att fånga in ett anrop och ändra sessions-ID.
  • Försök ändra det händelseflöde som finns implementerat i appen. Är det exempelvis möjligt att hoppa över signeringssteget och gå direkt på en operation som för över pengar?
  • Försök injicera snuttar av programkod i meddelande till servern. Det kan vara så att klienten har logik för att ta hand om inmatad text på ett ofarligt sätt, men vad händer om man går förbi klienten och försöker injicera kod från proxyn? Om det går att injicera kod den vägen kan en angripare också använda metoden.
  • Kontrollera ifall det går att upprepa ett anrop många gånger. Kanske gör appen att man blir utspärrad efter ett antal försök med felaktig verifieringskod. Men vad händer med upprepade gissningar från verktyget? Kommer servern att säga till eller går det att hålla på och försöka tills det lyckas?

Så går det att fortsätta och det är bara fantasin som sätter gränser. Trots att det är ganska osannolikt att hitta fel är testningen spännande, speciellt om man tänker på att det är viktigt att själv hitta bristerna innan någon med mindre gott uppsåt lär sig utnyttja dem.

Nästa steg

Konsultbolag1 har testare som specialiserat sig på säkerhetstestning och som kan genomföra sådan eller hjälpa en organisation att komma igång inom området.

KONTAKTA OSS

Har du frågor? Vill du ha hjälp med områden inom kravhantering och test?
Hör av dig till oss! Vi hjälper dig gärna. 

Kontakt 

Dela artikeln