Thomas

Thomas

The author works at and owns Mint Security, a mean and lean security company founded in 2015. No fuzz (literally - we do not fuzz, there are companies better equipped to do that).
Share on facebook
Share on twitter
Share on linkedin
Share on xing
Share on whatsapp

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

0. Päätä ja budjetoi
Monimutkainen ja kattava testaus vaatii sekä aikaa että rahaa. Se ei välttämättä ole kustannustehokasta. Joskus tämä kuitenkin on tarpeen. Silloin toimitaan esimerkiksi seuraavasti.
1. Hanki päätelaite
Testaus edellytää sopivan päätelaitteen hankinnan jotta testausta voidaan tehdä mahdollisimman oikeanlaisessa ympäristössä.
2. Jailbreak tai root
Sopiva päätelaite pitää sopivasti rikkoa. Päätelaite pitää hallita, jotta oikeanlaiset temput voidaan suorittaa ja luoda oikeanlaiset testiolosuhteet.
3. Winning
Temppujen jälkeen toivotaan että päätelaite edelleen toimii oikealla tavalla, jotta testausta voidaan suorittaa.
Previous
Next

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:

  • Android binäärit - käännetty erityisesti testausta varten

    - Pääsemme testaamaan sovelluksen toiminnallisuuksia.
    - Pääsemme näkemään liikennettä helposti.
    - Varmistumme siitä, että sovelluksessa ei ole testausta estäviä asioita.
    - Voidaan myös skannata staattisesti (SAST & SCA)

  • Lähdekoodit

    - Pääsemme analysoimaan ja näkemään muun muassa, mitä oikeuksia laitteelle annetaan.
    - Pääsemme React Native -maailmassa näkemään sipulin sisimmän kerroksen suoraan.

  • Projekti

    - Pääsemme suoraan kääntämään sovelluksen itse tarvittavilla optioilla.

  • React Native main.jsbundle

    - Pääsemme suoraan kääntämään sovelluksen itse tarvittavilla optioilla.

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.

Valitaan työkalut
Läpileikkaus sovelluksesta
Sovelluksen testaus ja analysointi
Previous
Next

Ostakaamme siis ... mitä?

Thomas

Thomas

The author works at and owns Mint Security, a mean and lean security company founded in 2015. No fuzz (literally - we do not fuzz, there are companies better equipped to do that).
Share on facebook
Share on twitter
Share on linkedin
Share on xing
Share on whatsapp

ota yhteyttä

Pyydä rohkeasti lisätietoa. Vastaamme todennäköisesti nopeammin kuin osasit kuvitella.