Panduan Keselamatan Aplikasi Mudah Alih: Ujian Penembusan untuk iOS dan Android
Aplikasi mudah alih menyimpan kunci, token, data peribadi dan kredensial pembayaran pada peranti yang tidak anda kawal. Bagi bank digital, e-dompet dan aplikasi kerajaan di Malaysia, pentest aplikasi mudah alih bukan lagi pilihan, tetapi keperluan asas. Panduan ini menerangkan ancaman unik terhadap iOS dan Android, OWASP Mobile Top 10, persediaan binari yang diperlukan untuk pentest, dan perbezaan permukaan serangan antara kedua-dua platform. Matlamatnya ialah membantu pasukan produk dan keselamatan memahami apa yang diliputi dalam pentest aplikasi mudah alih dan cara untuk bersedia.
Ancaman Unik terhadap Aplikasi Mudah Alih
Aplikasi web berjalan pada pelayan yang anda kawal. Aplikasi mudah alih pula berjalan pada peranti pelanggan, iaitu peranti yang mungkin telah di-jailbreak (dibuka sekatan perisian) atau di-root (diberi akses akar), dijangkiti perisian hasad (malware), atau dianalisis oleh penyerang yang mempunyai akses fizikal sepenuhnya. Model ancaman ini berbeza secara asasnya daripada web.
Penyerang yang menyasarkan aplikasi mudah alih boleh melakukan analisis statik binari (menyahkompil APK atau IPA) dan analisis dinamik dengan Frida atau Objection. Mereka juga boleh mencuri kredensial daripada keychain atau SharedPreferences jika data itu tidak dilindungi dengan betul. Mereka boleh memintas trafik dengan sijil sendiri jika pengikatan sijil tidak dilaksanakan.
Di Malaysia, peningkatan penerimaan e-dompet (Touch 'n Go, GrabPay dan Boost), bank digital baharu di bawah lesen BNM, dan aplikasi MyKad Digital telah menjadikan platform mudah alih sasaran utama penipuan dan penyalahgunaan. Kerentanan dalam aplikasi ini boleh membawa terus kepada kerugian kewangan pelanggan dan tindakan kawal selia.
OWASP Mobile Top 10
OWASP Mobile Top 10 ialah panduan yang setara dengan OWASP Top 10 bagi aplikasi mudah alih dan harus menjadi rujukan utama pasukan pembangunan. Panduan ini menekankan ancaman yang khusus kepada konteks aplikasi mudah alih.
Berikut ialah ringkasan kategori dalam versi terkini, dengan tumpuan pada apa yang biasa dijumpai dalam aplikasi di Malaysia.
- M1 Penggunaan Kredensial yang Tidak Betul (Improper Credential Usage): token disimpan dalam teks biasa dan kunci API tertanam dalam kod.
- M2 Keselamatan Rantaian Bekalan yang Tidak Mencukupi (Inadequate Supply Chain Security): pustaka pihak ketiga yang mempunyai kerentanan diketahui.
- M3 Pengesahan dan Kebenaran yang Tidak Selamat (Insecure Authentication/Authorization): pintasan biometrik dan pengesahan berbilang faktor (MFA) yang rosak.
- M4 Pengesahan Input dan Output yang Tidak Mencukupi (Insufficient Input/Output Validation): suntikan ke dalam WebView dan penyalahgunaan pautan dalam (deep link).
- M5 Komunikasi yang Tidak Selamat (Insecure Communication): TLS lemah dan tiada pengikatan sijil.
- M6 Kawalan Privasi yang Tidak Mencukupi (Inadequate Privacy Controls): perkongsian data di luar dasar dan akses lokasi yang berlebihan.
- M7 Perlindungan Binari yang Tidak Mencukupi (Insufficient Binary Protections): tiada antinyahpepijat dan tiada pengesanan root/jailbreak.
- M8 Salah Konfigurasi Keselamatan (Security Misconfiguration): bendera nyahpepijat aktif dan aktiviti terdedah (exported activities) yang sensitif.
- M9 Penyimpanan Data yang Tidak Selamat (Insecure Data Storage): penyalahgunaan keychain dan SQLite tanpa enkripsi.
- M10 Kriptografi yang Tidak Mencukupi (Insufficient Cryptography): kunci tertanam dalam kod dan algoritma lemah.
Bank Digital dan E-Dompet: Kes Penggunaan di Malaysia
Sejak BNM mengeluarkan lesen bank digital pada 2022, sektor perbankan mudah alih di Malaysia telah berkembang pesat. Setiap bank digital perlu memenuhi standard RMiT yang sama seperti bank tradisional, termasuk pengujian keselamatan aplikasi mudah alih sebelum dan selepas pelancaran.
Tugasan pentest yang lazim untuk bank digital di Malaysia merangkumi pengesahan transaksi dan aliran kerja pembayaran, integrasi DuitNow dan FPX, kawalan biometrik dan pengikatan peranti (device binding), perlindungan API ke sistem perbankan teras, serta ketahanan terhadap aplikasi yang diubah suai (contohnya APK yang diubah suai).
E-dompet yang mempunyai had transaksi tinggi (lebih daripada RM10,000) menghadapi pengawasan tambahan daripada Jabatan Penyeliaan Pembayaran BNM. Pentest aplikasi mudah alih yang berkualiti perlu memetakan penemuan kepada kawalan RMiT 10.x dan piawaian pembayaran yang berkaitan.
Persediaan Binari untuk Pentest
Salah satu kelewatan yang paling kerap dalam pentest aplikasi mudah alih di Malaysia ialah penyerahan binari yang terlalu dikaburkan. Penguji memerlukan APK (Android) dan IPA (iOS) yang boleh dianalisis dengan munasabah dalam tempoh tugasan.
Untuk Android, sediakan APK nyahpepijat (debug) yang tidak ditandatangani dengan kunci tandatangan produksi, atau APK produksi dengan ProGuard dimatikan. Penguji juga memerlukan akses kepada kod sumber untuk pemeriksaan rutin kriptografi dan logik pengesahan. Untuk iOS, sediakan IPA yang boleh dipasang pada peranti ujian penguji (pengedaran ad hoc atau perusahaan).
Sediakan juga akaun ujian dengan beberapa peranan, dokumentasi API (Swagger atau koleksi Postman), dan senarai integrasi pihak ketiga. Jika aplikasi anda menggunakan pengesahan integriti peranti (Play Integrity, DeviceCheck), berikan mekanisme untuk memintasnya dalam persekitaran ujian. Tanpa mekanisme ini, separuh daripada tugasan akan dihabiskan untuk memintas perlindungan platform, bukan keselamatan aplikasi.
iOS berbanding Android: Jadual Perbandingan Permukaan Serangan
Walaupun banyak konsep keselamatan serupa, terdapat perbezaan praktikal yang mempengaruhi cara pentest dijalankan dan jenis penemuan yang biasa.
| Aspek | iOS | Android |
|---|---|---|
| Format binari | IPA (Mach-O dalam .ipa) | APK / AAB |
| Kotak pasir (sandbox) | Kotak pasir aplikasi yang ketat bagi setiap aplikasi | Kotak pasir serta model kebenaran |
| Penyimpanan selamat | Keychain (Secure Enclave) | Keystore (TEE pada SoC) |
| Root/Jailbreak | Jailbreak jarang berlaku pada pengguna biasa | Root lebih mudah, ROM yang diubah suai lazim digunakan |
| Pengedaran di luar kedai rasmi | App Store / TestFlight / ad hoc | APK boleh dipasang sendiri (sideload) secara bebas |
| IPC | skema URL, Universal Links, XPC | Intent, Content Provider, AIDL |
| Risiko binari diubah suai | Lebih rendah (tandatangan Apple) | Lebih tinggi (APK boleh ditandatangani semula) |
| Cabaran utama pentest | Pintasan pengesahan integriti peranti, JIT | Pintasan pengesanan root, pencangkukan Frida (Frida hooking) |
Penemuan Kritikal yang Sering Dijumpai
Walaupun pada aplikasi besar yang mempunyai pasukan keselamatan dalaman, kami sering menjumpai corak yang sama. Yang pertama ialah pengikatan sijil yang dilaksanakan hanya pada beberapa titik akhir, manakala titik akhir analitik dan pelaporan ranap aplikasi tidak dilindungi kerana terlepas pandang, lalu membuka peluang serangan orang di tengah (MITM) terhadap token sesi.
Yang kedua ialah token penyegaran disimpan dalam SharedPreferences atau UserDefaults tanpa enkripsi, sehingga boleh dibaca pada peranti yang di-root atau melalui akses fizikal. Yang ketiga ialah pautan dalam yang menerima parameter sensitif tanpa pengesahan input, lalu membuka peluang pancingan data (phishing) atau pengambilalihan akaun.
Yang keempat dan paling biasa ialah bahagian belakang yang menganggap aplikasi mudah alih sebagai 'klien yang dipercayai' dan melaksanakan pengesahan logik perniagaan di sisi aplikasi mudah alih sahaja. Penyerang yang menyalin permintaan API dapat melepasi semua kawalan tersebut. Pengajarannya: jangan sekali-kali mempercayai klien. Semua kawalan kritikal mesti diulangi di pelayan.
Bacaan Lanjut dan Perkhidmatan nCrypt
Soalan Lazim
Adakah aplikasi React Native atau Flutter memerlukan pentest yang berbeza?
Ya. Aplikasi merentas platform mempunyai permukaan serangan tambahan: berkas (bundle) JavaScript dalam React Native atau syot kilat (snapshot) Dart dalam Flutter mengandungi banyak logik aplikasi yang boleh dianalisis. Bagi React Native, penguji boleh mengekstrak berkas itu, menyahkaburkannya dan membaca logik perniagaan dengan agak mudah. Bagi Flutter, walaupun lebih sukar, alat seperti reFlutter telah matang. Pasukan pentest yang baik akan menyesuaikan metodologi dan alat dengan kerangka yang digunakan, serta menyemak komunikasi antara jambatan natif dengan komponen JS atau Dart.
Adakah perlu menguji versi APK lama yang masih digunakan pelanggan?
Sangat perlu. Banyak organisasi di Malaysia hanya memberikan tumpuan kepada versi terkini, tetapi penyerang menyasarkan pelanggan yang masih menggunakan versi yang dikeluarkan 6, 12 atau 18 bulan lalu, terutamanya jika tiada kemas kini paksa. Strategi keselamatan yang matang merangkumi kawalan peningkatan versi paksa yang ketat dan pengesahan versi minimum di bahagian belakang. Pentest patut menyemak sama ada bahagian belakang menerima permintaan daripada versi aplikasi yang sepatutnya 'tidak disokong'. Jika ya, kerentanan dalam versi lama menjadi lubang yang nyata.
Bagaimanakah pentest mengendalikan APK yang diubah suai dan emulator?
Pentest yang serius akan menguji ketahanan aplikasi terhadap pengubahsuaian dan persekitaran emulasi. Penguji akan mengubah suai APK (contohnya dengan memasukkan Frida gadget), menjalankannya dalam emulator yang diubah suai, dan menyemak sama ada aplikasi mengesan dan memberi respons. Ini bukan ujian akademik. Di Malaysia, kami pernah melihat penipuan e-dompet menggunakan APK yang diubah suai untuk memintas had transaksi dan kawalan pengikatan peranti. Penemuan ini biasanya diklasifikasikan sebagai Tinggi atau Kritikal kerana kesan kewangannya yang langsung.
Berbincang dengan Pasukan nCrypt
Pasukan kami yang sejajar dengan CREST membantu institusi kewangan, agensi kerajaan dan PKS Malaysia merancang ujian penembusan, pematuhan dan respons insiden. Dapatkan sebut harga atau tempah perbincangan percuma hari ini.