Memeriksa penyimpanan data aplikasi mobile

Apa yang diperiksa pada penyimpanan mobile?

Periksa data yang benar-benar disimpan, alasan penyimpanannya, dan apa yang tertinggal setelah keluar akun. Tampilan yang kembali ke layar login belum membuktikan data lokal atau token lama sudah dibersihkan.

Mulai dari lingkup keamanan aplikasi mobile untuk daftar perangkat, izin dan SDK. Halaman ini memperdalam satu pekerjaan: memeriksa dua lokasi penyimpanan dan log pada aplikasi Android buatan untuk lab.

Tetapkan data dan keadaan yang diharapkan

Daftarkan token, dokumen, data pelanggan, database, cache, file unduhan dan log yang mungkin dibuat aplikasi. Tentukan mana yang boleh tetap tersimpan, kapan harus dihapus, serta perlindungan yang dibutuhkan. Kebutuhan offline dapat berbeda dari aplikasi yang selalu tersambung.

Catat keadaan awal, sesudah masuk akun, sesudah menggunakan fitur, sesudah logout dan sesudah aplikasi dibuka kembali. Periksa juga pergantian akun agar data akun lama tidak ditampilkan kepada akun baru.

MASTG-TEST-0207 memberi pendekatan pemeriksaan isi penyimpanan Android. MASWE-0005 membahas data sensitif di log; MASWE-0024 membahas data yang masih dapat diakses setelah sesi berakhir. Gunakan rujukan itu untuk memilih pemeriksaan, tanpa menganggap satu pencarian teks sudah menutup semuanya.

Lingkungan contoh yang dijalankan

Unduh source dan hasil lab verifikasi 1.0. Jalankan pada emulator khusus lab tanpa akun pribadi. README menjelaskan build, perintah, hasil asli dan uji ulang. Semua penanda data bersifat buatan.

Contoh dijalankan 1 Oktober 2026 pada emulator arm64-v8a: Android 17, API 37, build CP31.260623.009. Aplikasi menargetkan API 36, dibuat dengan SDK/Build Tools 36 dan JDK 17.0.20; emulator 37.1.11.0, ADB 1.0.41/37.0.1. Rujukan: MASVS 2.1.0 dan halaman MASTG yang diperiksa pada tanggal tersebut.

Package id.kompli.verificationlab memiliki build bad dan fixed. Build lab mengizinkan debug agar file dapat diperiksa dengan run-as. Ini bukan konfigurasi rilis dan bukan laporan aplikasi pelanggan. Perintah memulai proses baru untuk tiap kasus; yang diuji adalah fungsi fixture, bukan klik UI logout atau sesi backend.

Jalankan alur, lalu baca bukti

Setelah membangun dan memasang bad.apk, jalankan kasus login melalui ADB seperti petunjuk paket. Periksa file buatan dan lognya:

adb -s emulator-5580 shell run-as id.kompli.verificationlab cat shared_prefs/session.xml
adb -s emulator-5580 shell run-as id.kompli.verificationlab cat cache/customer.txt
adb -s emulator-5580 logcat -d -v brief KompliLab:I '*:S'

Serial tersebut milik lab yang dijalankan; ganti dengan serial emulator uji Anda. Jalankan kasus logout, lalu baca lokasi yang sama. Pasang fixed.apk sebagai pembaruan, jalankan logout untuk membersihkan data lama, kemudian ulangi login, logout dan inspect.

Hasil sebelum dan sesudah perbaikan

Bukti	Hasil yang tercatat
Token bad	Setelah logout, SESSION_BAD_DEMO masih ada pada session.xml. Harapan token lokal dibersihkan belum terpenuhi.
Cache bad	Setelah logout, CUSTOMER_BAD_DEMO masih dapat dibaca dari customer.txt.
Log bad	Terdapat token=SESSION_BAD_DEMO; ini penulisan data rahasia buatan yang sengaja dibuat salah.
Data fixed	Preferences menjadi <map />; cache contoh dihapus. Login fixed tidak menyimpan token ke file.
Uji ulang fixed	Sesudah dibuka ulang: persistedToken=false customerCache=false; pemeriksaan ulang dua file juga tidak menemukan penanda tadi.

Perbaikan fixture berhenti menulis token ke preferences/log dan menghapus cache contoh saat logout. Token fixed hanya dipakai di memori selama proses; kebutuhan penyimpanan sesi aplikasi nyata tetap perlu dirancang sendiri.

Log lama masih mengandung SESSION_BAD_DEMO setelah aplikasi diperbarui. Build fixed tidak menulis SESSION_FIXED_DEMO. Jangan menghapus buffer log untuk menghasilkan bukti seolah kebocoran lama tidak pernah terjadi. Jika data nyata telanjur tercatat, tangani akses dan retensinya serta periksa sesi dan token yang perlu dicabut.

Apa yang belum dibuktikan?

Pemeriksaan ini hanya membaca dua path dan log fixture. Tidak mencakup semua file, database, backup, WebView, keyboard, screenshot, KeyStore, memori atau pemulihan forensik. Penghapusan file tidak membuktikan byte tidak bisa dipulihkan. Pembatasan run-as pada aplikasi rilis juga tidak membuktikan tidak ada data tersimpan.

Hasil Android ini belum diuji pada perangkat fisik atau versi Android lain. Contoh iOS tersendiri ada di bagian berikut; hasil Android tidak dianggap mewakili iOS. Penghapusan lokal tidak mencabut token pada server. Untuk aplikasi nyata, ulangi snapshot seluruh penyimpanan yang masuk lingkup dan pemeriksaan alur akun; periksa data yang diubah bentuknya atau dikompresi, bukan hanya teks penanda.

Catat versi/build, path, kondisi awal, langkah, hasil, bukti, batas dan uji ulang pada lembar verifikasi. Lanjutkan ke pemeriksaan komunikasi jaringan untuk data yang keluar dari perangkat.

Penjelasan metode dan kelemahan diringkas dari OWASP MAS dengan perubahan bahasa; bagian adaptasi mengikuti CC BY-SA 4.0. Source dan hasil lab orisinal tersedia dalam paket unduhan.

Contoh iOS: nilai API berbeda dari snapshot file

Lab keamanan aplikasi 1.0 menambahkan fixture iOS, bukan build Android yang dipindahkan tanpa pengujian. Dijalankan 2 Oktober 2026 pada iPhone 17 simulator, iOS 26.5 (23F77), arm64, dengan Xcode 27.0 (27A266a). Tidak ada iPhone fisik yang tersambung. Runner membuat simulator baru lalu menghapusnya; data pribadi dan simulator lama tidak digunakan.

python3 run-ios.py --out ./out-ios --confirm-disposable-simulator

App bad menaruh token penanda SESSION_IOS_BAD_DEMO di UserDefaults dan satu berkas customer-demo.txt di cache. Mode fixed berhenti menulis token ke preferences dan menjalankan penghapusan key serta cache ketika logout. Tiap kasus dimulai sebagai proses baru; yang diuji adalah fungsi fixture, bukan klik tombol atau pencabutan sesi server.

Bukti	Hasil dan cara membacanya
Logout bad	API masih mengembalikan token; token ada pada plist preferences dan cache masih ada.
Logout fixed	API tidak lagi mengembalikan token dan cache hilang. Snapshot plist dicatat terpisah; perubahan API saja belum membuktikan semua salinan disk sudah hilang.
Baseline sebelum perbaikan kebijakan jaringan	Setelah logout fixed, token masih terbaca pada file preferences walaupun API melaporkan tidak ada token. Saat retest berikutnya token tidak lagi muncul dalam snapshot yang diperiksa.
Run terakhir fixed/retest	Token lama tetap ada pada snapshot plist sesudah logout; kriteria pembersihan disk masih gagal. Pada proses login retest, API kembali membaca token lama. Nama fixed menandai perubahan kode, bukan semua pemeriksaan lulus.
Bukti paket	observed-ios-baseline.json dan observed-ios.json menyimpan keadaan API/file setiap langkah, termasuk hasil yang belum bersih.

Baca plist sebagai struktur data; pencarian byte mentah saja tidak cukup menjelaskan nilai yang masih tersimpan. Jangan hanya menunggu snapshot bersih lalu menghapus bukti sebelumnya. Hasil awal dan run terakhir menunjukkan mengapa kriteria penghapusan perlu memeriksa lokasi file dan waktu pengamatan, bukan tampilan logout atau API saja. Temuan sisa token perlu ditindaklanjuti; jangan menutup kasus sebagai lulus. Contoh ini belum memberikan perbaikan tuntas untuk penghapusan preferences.

Rujukan iOS MASTG-TEST-0302, diperiksa 2 Oktober 2026, mencakup pemeriksaan perubahan file dan Keychain. Lab hanya mengambil snapshot satu plist/cache; Keychain, seluruh snapshot penyimpanan, backup, kelas Data Protection, log iOS dan penghapusan forensik belum diperiksa. Penghapusan key tidak dijadikan bukti secure erasure atau pelindungan hardware. Gunakan catatan verifikasi untuk mencatat temuan tersisa.

Penjelasan metode iOS diringkas dari OWASP MAS dengan perubahan bahasa; halaman yang ditinjau mencantumkan CC BY 4.0. Kode dan hasil iOS orisinal Kompli memakai CC0 1.0.