Print:

Het gevaar van mobiele apps

Mobiele applicaties zijn niet alleen maar leuk. Ze zeggen heel veel over de veiligheid van je totale systeem, en ze kunnen zomaar een paar forse beveiligingsgaten blootleggen waar je organisatie flink last van kan krijgen. Hoe leuk is dat nog – en hoe kun je het voorkomen?

Er verschijnen tegenwoordig meer en meer serieuze zakelijke toepassingen voor mobiele platforms zoals Android en iOS. In de meeste gevallen zijn die apps verlengstukken van bestaande zakelijke web-applicaties, met name voor consumentgerichte functies.

Een belangrijk verschil tussen de meeste web-apps en de meeste mobiele apps zit in wat bedrijven de consumenten in handen geven. Bij web-apps gaat het gewoonlijk om HTML, en JavaScript, en wat voor andere technische componenten het bedrijf ook verkiest te gebruiken. In het merendeel van de gevallen regelt de client-code de presentatielaag en het grootste deel van de user interface. Dat wil zeggen: er zit gewoonlijk maar weinig business logic in verwerkt.

Bij mobiele apps is dat vaak anders. Voor Android worden mobiele apps in het algemeen geschreven in Java, en voor iOS in Objective-C. Beide talen zijn in principe geschikt voor aanzienlijke procesfunctionaliteit (waarmee ik overigens de capaciteiten van JavaScript en aanverwanten niet tekort wil doen).

Het gevolg is dat mobiele apps vaak meer functies vervullen dan alleen die van de esthetische presentatie. En daar ligt het gevaar.

Voor Android is het niet ondenkbaar dat Java-bestanden gedecompileerd worden, zelfs als ze gebouwd zijn voor de Davlik JVM (dat net weer anders is dan de traditionele JVM). iOS applicaties zijn zelfs vrij simpel te ‘reverse-engineeren’, zelfs als ze via Apple’s App Store versleuteld zijn.

Via reverse engineering van de apps gaan potentiële aanvallers op zoek naar mogelijke ingangen waarmee ze toegang kunnen krijgen tot je systemen. Die ingangen zijn grofweg in te delen in twee categorieën: fouten in de implementatie en ontwerpfouten. In het eerste geval moet je denken aan programmeerfouten, zoals aanpasbare SQL queries in de vorm van dynamisch gebouwde query strings die te injecteren zijn met besmette data. Deze problemen zijn relatief eenvoudig op te lossen, bijvoorbeeld door gebruik te maken van niet-aanpasbare SQL query API’s, zoals PreparedStatement in Java.

Designfouten kunnen helaas een stuk problematischer zijn. Een oplossing is vaak lastiger te vinden en kost gewoonlijk ook meer geld.

Op zich zijn dat zaken die voor alle software opgaan, dus waarom zouden we ons om mobiele apps meer zorgen moeten maken? Dat komt door het design van de software zelf. Als de architect een systeem ontworpen heeft waarin de client-code gevoelige functionaliteit bevat, dan worden fouten in het design volledig zichtbaar voor de aanvallers als ze reverse engineering toepassen op de mobiele applicaties.

Iedere keer dat we een mobiele app bouwen en die app naar buiten sturen via een app store of play market, geven we direct informatie prijs over onze software. De meeste gebruikers zijn zich nauwelijks bewust van de werking van apps – ze willen niet eens weten hoe het werkt, àls het maar werkt. Maar de gebruikers die van plan zijn ons aan te vallen zijn juist uitermate nieuwsgierig. Zij zullen onze apps statisch en dynamisch analyseren om de werking zo goed mogelijk te doorgronden.

Ze installeren onze apps op geroote of gejailbreakte apparaten en leggen ze onder de spreekwoordelijke microscoop. En als ze dat doen, komen ze vroeger of later zwakke punten in het ontwerp tegen die ze kunnen gebruiken. Het is al erg genoeg als zo’n fout ze toegang geeft tot een enkel apparaat en de data van de eigenaar gestolen of beschadigd kan worden. Maar zo’n ontwerpfout kan ook grotere gevolgen hebben.

Stel dat in zo’n app een functie is opgenomen voor client-side authenticatie. Zodra de app wordt opgestart, voert de gebruiker zijn gebruikersnaam en wachtwoord in om de app te kunnen gebruiken. En stel je nu eens voor dat die authenticatiefunctie een enkel Booleaans dataveld bevat dat bepaalt of de gebruiker toegang krijgt of niet. Stel dat de aanvaller in staat is dat dataveld standaard op TRUE te zetten, zonder dat daarvoor eerst een geldige gebruikersnaam en wachtwoord combinatie hoeft te worden ingevoerd. In die hypothetische situatie is het systeem zo gek te krijgen dat de gebruiker op die manier toegang krijgt tot uw systemen.

Dit is een simpel voorbeeld, maar het geeft wel aan welk gevaar er schuilt in beveiligingsmaatregelen die je op de client zelf laat draaien, en het vertrouwen dat je daar in stelt. Web apps kunnen soortgelijke client-side problemen hebben, maar in mobiele apps lijkt dit probleem groter, omdat mensen geneigd zijn de capaciteiten van de aanvallers te onderschatten.

Het reverse-engineeren van een Android of iOS app om designfouten te vinden blijkt opvallend eenvoudig te doen. De tools en technieken zijn voor beide platformen vrij beschikbaar voor iederen die het wil proberen.

Het is aan designers om ervoor te zorgen dat security controls, gevoelige data, protocollen en algoritmen uberhaupt niet in handen van de aanvallers komen. Dat betekent dat al in de ontwerpfase voorzichtigheid geboden is. Het kan heel verleidelijk zijn om gevoelige functionaliteit in de client onder te brengen, maar als je dat doet geef je wellicht meer informatie prijs dan goed voor je is.

Wat is wijsheid voor bewuste softwareprogrammeurs? Er zijn tenslotte nogal wat zaken om rekening mee te houden. Hieronder geven we een aantal overwegingen – zeker geen volledige lijst, maar de belangrijkste aandachtspunten staan er wel in.

  • Sla zo min mogelijk op in de client. Tenzij je echt niet anders kunt, is het beter helemaal niets wat ook maar een beetje gevoelig zou kunnen zijn op de client te bewaren. Als het echt per se moet, maak dan gebruik van een container, zoals keychain in iOS. Dat is bepaald geen perfecte oplossing, maar het is in elk geval vele malen beter dan opslaan als platte tekst.
  • Plaats geen security controls op de client. Zorg dat alle operationele en beveiligingsfuncties op de server worden uitgevoerd, en nooit op de client.
  • Ga er altijd vanuit dat de client onder controle is van een tegenstander. Programmeer je software vanuit de gedachte dat je tegenstander alles kan zien wat je doet, want uiteindelijk komt het daar wel op neer.

Betekent dat dan dat we helemaal niets leuks meer kunnen doen op onze mobiele apparaten? Natuurlijk niet. Zo lang we de voordelen van mobiele apparaten hoger inschatten dan de risico’s die ze met zich meebrengen, zullen we altijd mooi spul voor onze mobieltjes blijven ontwerpen. Maar dat vereist wel dat we een juiste inschatting blijven maken van de risico’s die we daar mee lopen.

Wij gebruiken cookies om IIR.nl gemakkelijk te maken. Bezoekt u onze website, dan gaat u akkoord met deze cookies meer informatie

De cookie-instellingen op deze website zijn ingesteld op 'toestaan cookies "om u de beste surfervaring mogelijk. Als u doorgaat met deze website te gebruiken zonder het wijzigen van uw cookie-instellingen of u klikt op "Accepteren" hieronder dan bent u akkoord met deze instellingen.

Sluiten