Keselamatan Aplikasi Mudah Alih: Ujian Penembusan untuk iOS dan Android
Aplikasi mudah alih menyimpan kunci, token, data peribadi dan kredensial pembayaran di peranti yang tidak anda kawal. Untuk bank digital, e-dompet dan aplikasi pemerintah Malaysia, pentest mobile bukan pilihan — ia keperluan asas. Panduan ini menerangkan ancaman unik kepada iOS dan Android, OWASP Mobile Top 10, persediaan binari yang diperlukan untuk pentest, dan perbezaan permukaan serangan antara kedua platform. Matlamatnya: bantu pasukan produk dan keselamatan memahami apa yang dilindungi dalam pentest mobile dan bagaimana untuk bersedia.
Ancaman unik kepada aplikasi mudah alih
Aplikasi web berjalan di pelayan yang anda kawal. Aplikasi mudah alih berjalan di peranti pelanggan — peranti yang mungkin di-jailbreak, di-root, dijangkiti malware, atau dianalisis oleh penyerang yang mempunyai akses fizikal sepenuhnya. Model ancaman ini secara asasnya berbeza daripada web.
Penyerang yang menargetkan mobile boleh melakukan analisis statik binari (decompile APK atau IPA), analisis dinamik dengan Frida atau Objection, dan boleh mencuri kredensial daripada keychain atau shared preferences jika tidak dilindungi dengan betul. Mereka boleh memintas trafik dengan certificate sendiri jika SSL pinning tidak dilaksanakan.
Di Malaysia, peningkatan adopsi e-dompet (Touch 'n Go, GrabPay, Boost), bank digital baharu di bawah lesen BNM, dan aplikasi MyKad Digital telah menjadikan platform mobile sebagai sasaran utama penipuan dan penyalahgunaan. Kerentanan dalam aplikasi ini boleh diterjemahkan terus kepada kerugian kewangan pelanggan dan tindakan pengawalseliaan.
OWASP Mobile Top 10
OWASP Mobile Top 10 adalah panduan setara untuk aplikasi mudah alih dan harus menjadi rujukan utama pasukan pembangunan. Ia menekankan ancaman yang spesifik kepada konteks mobile.
Berikut adalah ringkasan kategori dalam versi terkini, dengan tumpuan pada apa yang biasa dijumpai dalam aplikasi Malaysia.
- M1 Improper Credential Usage — token disimpan dalam plaintext, hardcoded API keys.
- M2 Inadequate Supply Chain Security — library pihak ketiga dengan kerentanan diketahui.
- M3 Insecure Authentication/Authorization — biometric bypass, broken MFA.
- M4 Insufficient Input/Output Validation — injection ke dalam WebView, deep link abuse.
- M5 Insecure Communication — TLS lemah, tiada certificate pinning.
- M6 Inadequate Privacy Controls — perkongsian data luar dasar, akses lokasi berlebihan.
- M7 Insufficient Binary Protections — tiada anti-debugging, tiada root/jailbreak detection.
- M8 Security Misconfiguration — debug flag aktif, exported activities yang sensitif.
- M9 Insecure Data Storage — keychain misuse, SQLite tanpa enkripsi.
- M10 Insufficient Cryptography — kunci hardcoded, algoritma lemah.
Bank digital dan e-dompet: kes guna Malaysia
Sejak BNM mengeluarkan lesen bank digital pada 2022, sektor mobile banking Malaysia telah berkembang pesat. Setiap bank digital perlu memenuhi standard RMiT yang sama seperti bank tradisional, termasuk pengujian keselamatan aplikasi mobile sebelum dan selepas pelancaran.
Engagement pentest tipikal untuk bank digital di Malaysia merangkumi: pengesahan transaksi dan workflow pembayaran, integrasi DuitNow dan FPX, kawalan biometrik dan device binding, perlindungan API kepada core banking, dan ketahanan terhadap aplikasi diubahsuai (modded APK).
E-dompet dengan limit transaksi tinggi (RM10,000+) menghadapi pengawasan tambahan dari Jabatan Penyeliaan Pembayaran BNM. Pentest mobile yang berkualiti perlu memetakan penemuan ke kawalan RMiT 10.x dan piawaian pembayaran yang relevan.
Persediaan binari untuk pentest
Salah satu kelewatan paling kerap dalam pentest mobile di Malaysia ialah penyerahan binari yang terlalu obfuscated. Penguji memerlukan APK (Android) dan IPA (iOS) yang boleh dianalisis dengan munasabah dalam tempoh engagement.
Untuk Android, sediakan APK debug yang tidak ditandatangani dengan production signing key — atau APK production tetapi dengan ProGuard dimatikan. Penguji juga memerlukan akses kepada source code untuk pemeriksaan crypto routine dan logik pengesahan. Untuk iOS, sediakan IPA yang boleh dipasang pada peranti ujian penguji (ad-hoc atau enterprise distribution).
Sediakan juga akaun ujian dengan beberapa peranan, dokumentasi API (Swagger atau Postman collection), dan senarai integrasi pihak ketiga. Jika aplikasi anda menggunakan attestation (Play Integrity, DeviceCheck), berikan mekanisme untuk membypass dalam persekitaran ujian — tanpa ini, separuh engagement akan dibelanjakan pada perlindungan platform, bukan keselamatan aplikasi.
iOS vs Android: jadual perbandingan permukaan serangan
Walaupun banyak konsep keselamatan adalah 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 |
| Sandbox | App sandbox ketat per-app | Sandbox ditambah permission model |
| Penyimpanan selamat | Keychain (Secure Enclave) | Keystore (TEE pada SoC) |
| Root/Jailbreak | Jailbreak rare di pengguna biasa | Root lebih mudah, modded ROM lazim |
| Distribusi luar | App Store / TestFlight / Ad-hoc | APK boleh sideload bebas |
| IPC | URL scheme, Universal Links, XPC | Intent, Content Provider, AIDL |
| Risiko binari diubahsuai | Lebih rendah (Apple signing) | Lebih tinggi (APK boleh resign) |
| Cabaran utama pentest | Bypass attestation, JIT | Bypass root detection, Frida hooking |
Penemuan kritikal yang sering dijumpai
Walaupun aplikasi besar dengan pasukan keselamatan dalaman, kami sering menjumpai corak yang sama. Yang pertama: SSL pinning yang dilaksanakan hanya pada beberapa endpoint, dengan endpoint analytics dan crash reporting dilupakan — membuka peluang MITM untuk token sesi.
Yang kedua: penyimpanan token refresh dalam shared preferences atau UserDefaults tanpa enkripsi, yang boleh dibaca pada peranti yang di-root atau dengan akses fizikal. Yang ketiga: deep link yang menerima parameter sensitif tanpa validation, membuka peluang phishing atau pengambilalihan akaun.
Yang keempat dan paling biasa: backend yang menganggap aplikasi mobile sebagai 'klien yang dipercayai' dan melaksanakan pengesahan business logic di sisi mobile sahaja. Penyerang yang menyalin permintaan API dapat melepasi semua kawalan tersebut. Pengajarannya: jangan sekali-kali percaya klien — semua kawalan kritikal mesti diulangi di server.
Bacaan Lanjut & Khidmat nCrypt
Soalan Lazim
Adakah aplikasi React Native atau Flutter memerlukan pentest yang berbeza?
Ya. Aplikasi cross-platform mempunyai permukaan serangan tambahan: JavaScript bundle (dalam React Native) atau Dart snapshot (dalam Flutter) mengandungi banyak logik aplikasi yang boleh dianalisis. Bagi React Native, penguji boleh mengekstrak bundle, deobfuscate dan baca logik bisnes dengan agak mudah. Bagi Flutter, walaupun lebih sukar, alat seperti reFlutter telah matang. Pasukan pentest yang baik akan menyesuaikan metodologi dan alat untuk kerangka yang digunakan, dan akan menyemak komunikasi antara native bridge dengan komponen JS atau Dart.
Adakah perlu menguji versi APK lama yang masih digunakan pelanggan?
Sangat perlu. Banyak organisasi Malaysia memberikan tumpuan kepada versi terkini sahaja, tetapi penyerang menyasarkan pelanggan yang masih menjalankan versi 6, 12 atau 18 bulan lalu — yang mungkin tiada force update. Strategi keselamatan yang matang termasuk kawalan force-upgrade yang ketat dan pengesahan versi minimum di backend. Pentest patut menyemak sama ada backend menerima permintaan daripada versi aplikasi yang sepatutnya 'tidak disokong'. Jika ya, kerentanan dalam versi lama menjadi lubang nyata.
Bagaimana pentest mengendalikan modded APK dan emulator?
Pentest yang serius akan menguji ketahanan aplikasi terhadap ubahsuaian dan persekitaran emulasi. Penguji akan memodify APK (contohnya memasukkan Frida gadget), menjalankan dalam emulator yang dimodifikasi, dan menyemak sama ada aplikasi mengesan dan bertindak balas. Ini bukan ujian akademik — di Malaysia, kami pernah lihat penipuan e-dompet menggunakan modded APK untuk melangkau had transaksi dan kawalan device binding. Penemuan ini biasanya diklasifikasikan sebagai High atau Critical kerana impak kewangan langsung.
Bincang dengan Pasukan nCrypt
Pasukan CREST-aligned kami membantu institusi kewangan, agensi kerajaan dan PKS Malaysia merancang ujian penembusan, pematuhan dan respons insiden. Dapatkan sebut harga atau tempah perbincangan percuma hari ini.