Ternyata Android Aman Belum Tentu Bikin Aplikasinya Aman

Ngl, sebelumnya aku mikir begini. Android kan udah punya banyak proteksi bawaan, jadi aplikasi apapun yang jalan di atasnya pasti ikut aman. Terus baru-baru ini aku mulai belajar soal Android Security dan Application Penetration Testing, dan turns out, anggapanku itu lowkey kurang tepat.

Aku bukan sebagai orang yang udah paham banget. ini hanya sharing dari apa yang baru aku pelajari dan menurutku menarik. CMIIW kalau ada yang keliru.

Android memang punya pertahanan berlapis. Tiap aplikasi dikurung di App Sandbox dengan UID sendiri, jadi satu aplikasi nggak bisa sembarangan baca data aplikasi lain. Di atasnya ada SELinux, sistem permission, sampai enkripsi. Ada satu contoh di materi yang bikin aku langsung kebayang. Aplikasi jahat mencoba baca data aplikasi perbankan, lalu kernel menolak karena UID-nya beda. Kalaupun lapisan itu lolos, SELinux masih bisa jadi penjaga berikutnya.

Tapi dari yang aku pahami, proteksi itu fokusnya di sistem, bukan di kebiasaan developer. Kalau token disimpan plaintext di SharedPreferences, atau API key ditaruh begitu aja di strings.xml, sandbox nggak bisa nolong banyak. Jujur.. kalau dipikir-pikir, hal -hal kayak gitu tuh kebiasaan yang gampang banget kejadian waktu lagi ngerjain proyek.

Aku juga baru ngeh kalau APK itu bisa di-decompile pakai tools seperti JADX atau apktool, dan hasilnya bisa dibaca lagi. Obfuscation memang bikin lebih ribet, tapi bukan enkripsi. Pretty interesting, karena dari sisi developer, kita biasanya fokus bikin fiturnya jalan, bukan mikirin gimana orang lain bisa membongkar hasilnya.

Yang paling bikin penasaran itu AndroidManifest.xml. Dulu aku lihat file ini cuma sebagai tempat daftar activity sama permission. Ternyata disitu juga ada hal-hal yang jadi bahan pemeriksaan. Misalnya komponen yang exported=true tanpa permission bisa dipangil dari luar aplikasi. Ada juga cerita soal implicit intent, ketika aplikasi jahat mendaftar sebagai handler untuk aksi yang sama lalu menerima data yang seharusnya nggak dia terima. Tapi yang aku catat baik-baik, nggak semua exported component otomatis rentan. Semuanya tergantung apa yang dilakukan komponen itu dan data apa yang lewat. Jadi jangan langsung panik cuma karena nemu satu red flag.

Terus soal jaringan. Awalnya aku kira certificate pinning itu pengganti HTTPS. Ternyata bukan. HTTPS/TLS tetap fondasinya, sedangkan pinning itu lapisan tambahan. Aplikasi menyimpan pin sertifikat server yang sah, jadi kalau sertifikatnya beda, misalnya sertifikat proxy yang dipakai buat testing, koneksinya ditolak.

Dari situ aku baru ngerti kenapa tester perlu melewati pinning kalau mau lihat trafik aplikasi lewat Burp Suite. Di materi yang aku pelajari, caranya pakai Frida atau objection, dan ditekankan banget kalau ini cuma buat lingkungan lab atau aplikasi yang memang diizinkan untuk diuji. Satu lagi yang menurutku penting, TLS-nya sendiri nggak "dipecahkan". Enkripsinya tetap jalan, proxy cuma mengamati di tengah.

Waktu masuk ke cara mengujinya, aku kenalan sama dua pendekatan. Static analysis itu memeriksa APK tanpa menjalankan aplikasinya, mulai dari manifest, kode, resource, sampai hardcoded secrets, dengan bantuan tools seperti JADX, apktool, dan MobSF. Dynamic analysis itu mengamati aplikasi saat berjalan, seperti trafik jaringan, log, dan file yang terbentuk, pakai ADB, Burp Suite, Frida, dan objection.

Menurutku dua-duanya saling melengkapi. Static bagus buat gambaran awal yang luas, tapi banyak temuannya masih perlu dibuktikan lewat dynamic. Laporan otomatis dari MobSF juga tetap perlu dicek manual. Yang kelihatan serem di atas kertas belum tentu beneran bisa dimanfaatkan di kondisi nyata, dan itu makes sense banget buat aku.

Sekarang cara pandangku jadi agak beda. Dulu aku mikirnya "Android-nya kuat atau nggak". Ternyata masalahnya sering ada di keputusan-keputusan kecil, satu setting di manifest atau satu token yang disimpan sembarangan. Dan keamanan kayaknya bukan sesuatu yang dicek sekali lalu beres, tapi proses yang terus berulang tiap ada perubahan.