Meiltä kysytään säännöllisesti mobiilisovellusten tietoturvatestauksesta. Vastaus ei aina ole suoraviivainen vaan ”it depends” -henkinen. Miksi? Sitä yritämme avata seuraavassa.
Mikä on mobiilisovellus
Responsiivinen HTML
Ensinnäki kaikki mobiilisovellukset eivät ole oikeasti mobiilisovelluksia. Moni mobiilisovellus on yksinkertaisesti pienelle näytölle sovitettua html-koodia – ja samaa sovellusta ajetaan myös selaimessa. Näin tehään siksi, että saadaan samalla vaivalla (rahalla) tehty loppukäyttäjälle moneen laitteeseen sopiva sovellus. Webbisovellus paketoidaan ”paketoidaan” nätisti siten että sille saadaan klikattava ikoni puhelimeen jonka jälkeen meillä on käytössä mobiilisovellus. Teknisesti kyseessä on edelleen webbisovellus. Näissä tapauksissa testaaminen on suoraviivaista – testaus tapahtuu oikeasti perinteisin keinoin käyttämällä selainta ja Burpia tai muita vastaavia työkaluja. Testauksen kohteena on tällöin itse webbisovellus ja sen käyttämät API:t.
Natiivi mobiilisovellus
Jos puhutaan oikeista mobiilisovelluksista – eli sovelluksista, jotka on tavalla tai toisella kirjoitettu mobiililaitteen (ekosysteemin) ehdoin ja mobiililaitteen ohjelmointikielellä tulee meille uusia haasteita. Lähtökohtaisesti mobiilisovellukset kuuluu kahteen ekosysteemiin, Androidiin tai Appleen. Nämä eroavat merkittävästi toisistaan. Testaus vaatii aina jomman kumman laitteen – emulaattoripohjaisesti ei tietoturvatestauksessa saavuteta merkittäviä tuloksia tai testaus ei toimi ollenkaan. Jos testataan muuta kuin tuotantosovellusta – eli virallisesta kaupasta saatavaaa sovellusta – on sovellus siis jollain tavoin saatava tähän laitteeseen.
Kumpikin ekosysteemi tarjoaa oman tapansa tuottaa testivaiheen sovelluksia – Applella tämä tapa on TestFlight ja Androidilla esimerkiksi Play Console. Android mahdollistaa myös testattavan sovelluksen siirtämisen suoraan laitteeseen. Tämä kuulostaa kaikki hyvältä, mutta ei oikeasti palvele tietoturvatestausta kovinkaan hyvin.
Jotta päästään asioita muutenkin kuin käyttöliittymän käytettävyyden näkökulmasta, pitää päästää ”eri asioiden väliin”. Monesti tämä tarkoittaa että laite rootataan jotta voidana ohittaa viralliset valmistajien varmistusmekanismit. Androidin ollessa kyseessä, testaus on kaiken kaikkiaan helpompaa siksi että sovelluksia voidaan siirtää suoraan laitteeseen ja väliin pääsemin non helpompaa. Android-maailmassa asiakkaalta saatu APK voidaan reverse-engineerata ja sitä kautta päästä testaamaan. Applen ollessa kyseessä, kaikki on vaikeampaa – esimerkiksi sellaisen rootattavan laitteen löytäminen joka on versioltaan oikea jossa sovellus toimii ja joka täyttää muut ehdot, voi olla mahdotonta.
Miksi sitten pitää rootata tai jailbreakata on hyvä kysymys – muun muassa siksi, että jotta päästään laitteen ja liikenteen väliin, on manipuloitava sertifikaatteja.
Apple-ekosysteemin sovelluksia on siis kertauokkaa monimutkaisempaa testata kuin vastaavia Android-sovelluksia.
Jotta kokonaisuus ei helpottuisi, kaiken tämän päälle voidaan vielä tuoda kryptattuja, obfuskoituja tai minifioituja sovelluksia jotka lopullisesti tekevät testaamisesta äärettömän tuskallista.
Tämä kirjoitus avaa todella hyvin jo normaalinkin testauksen monimutkaisuuden – https://blog.securityevaluators.com/debugging-ios-applications-a-guide-to-debug-other-developers-apps-c041311498eb
React Native
Sovellusten toteuttaminen erikseen kahteen ekosysteemiin on kallista. Webbisvellusten adaptointi mobiililaiteen näytölle on kätevää ja kustannustehokasta, mutta jättää toivomisen varaa sillä läheskään kaikkia mobiililaitteen alustan ominaisuuksia ei silloin voida hyödyntää.
Kuvaan astuu tällöin esimerkiksi React Native. React Native on javascript-pohjainen sovelluskehitysympäristö, jossa koodi kirjoitetaan kerran – alustan tarjoamat ominaisuudet on abstraktoitu – ja käännösvaiheessa luodaan kummallekin alustalle sopiva natiivi binääriversio. Tästä on kehitys- ja ylläpitoprosesseihin todella paljon hyötyä. Haasteena testausmielessä tässä on, että sovellus on natiivi – eli edellisen kappaleen kaikki haasteet on edelleen olemassa. Lisäksi tässä tuodaan mukaan valtava Native-kerrostuma – jotta kerran kirjoitettu koodi kaikkinensa toimisi kaikissa mobiililaitteissa, tarvitaan valtavasti tukevia toimintoja ja kirjastoja.
React Native on kuin sipuli, ytimessä on pienen pieni osa omaa itse kirjoitettua koodia, ympärillä valtava kasa tunnettua ja tuntematonta. Testauksessa useimmiten on kiinnostavaa se, mitä se sipulin ydin pitää sisällään, ei se mitä kaikkea siihen ympärille tuodaan – varsinkin kun sovellukset yleensä käyttää vain murto-osan kaikista toiminnoista mitä React Native tuo mukanaan.
Tässä kirjoituksessa on hyvin tuotu esille React Nativen testaaminen silloin, kun käsillä on testausta varten käännetty sovellus käsillä – https://reactnative.dev/docs/running-on-device
Kuinka sitten Mint testaa
Mikään edellä mainituista tekniikoista tai lähestymistavoista eivät ole mahdottomia. Useimmiten kaikesta tästä ei kuitenkaan olla valmiit maksamaan – useasti perustellustikin niin. Me olemme valinneet tiettyjä omasta mielestämme kustannustehokkaita tapoja lähestyä tätä asiaa, sillä testattava kuitenkin on.
Me testaamme seuraavia asioita ja seuraavasti – riippuen asiakkaan tarpeista ja tahtotilasta sekä testattavasta sovelluksesta:
Me yritämme välttää Apple-ekosysteemin käännettyjä binääreitä tai Applen sovelluskaupasta suoraan saatavia binäärejä. Kustannusten säästämiseksi, yritämme myös välttää sitä, että joutuisimme rakentamaan omia dedikoituja asiakaskohtaisia testausympäristöjä ja ottamaan käyttöömme erilaisia kaupallisia developer toolkitteja.
Ostakaamme siis ... mitä?
