lightbulb_outline Please take our October 2018 developer survey. Start survey

Tip Keamanan

Android memiliki fitur keamanan yang dibangun ke dalam sistem operasi yang secara signifikan mengurangi frekuensi dan dampak masalah keamanan aplikasi. Sistem ini didesain agar Anda bisa seperti biasa membangun aplikasi dengan sistem default dan izin file serta terhindar dari keputusan sulit tentang keamanan.

Beberapa fitur keamanan inti yang membantu Anda membangun aplikasi yang aman meliputi:

  • Android Application Sandbox, yang memisahkan data aplikasi dan eksekusi kode dari aplikasi lainnya.
  • Kerangka kerja aplikasi dengan implementasi fungsionalitas keamanan umum yang kuat seperti kriptografi, izin, dan IPC yang aman.
  • Teknologi seperti ASLR, NX, ProPolice, safe_iop, OpenBSD dlmalloc, OpenBSD calloc, dan Linux mmap_min_addr mengurangi risiko yang berkaitan dengan kesalahan manajemen memori umum.
  • Sistem file terenkripsi yang bisa diaktifkan untuk melindungi data pada perangkat yang hilang atau dicuri.
  • Izin yang diberikan pengguna untuk membatasi akses ke fitur sistem dan data pengguna.
  • Izin yang didefinisikan aplikasi untuk mengontrol data aplikasi pada basis per-aplikasi.

Meskipun demikian, Anda harus familier dengan praktik terbaik keamanan Android dalam dokumen ini. Mematuhi praktik ini sebagai kebiasaan pengkodean umum akan mengurangi kemungkinan terjadinya munculnya masalah keamanan tanpa disengaja yang akan memengaruhi pengguna.

Menyimpan Data

Kekhawatiran keamanan yang paling umum untuk aplikasi pada Android adalah apakah data yang Anda simpan di perangkat bisa diakses oleh aplikasi lain. Ada tiga cara mendasar untuk menyimpan data pada perangkat:

Menggunakan storage internal

Secara default, file yang Anda buat pada storage internal hanya bisa diakses oleh aplikasi Anda. Perlindungan ini diimplementasikan oleh Android dan mencukupi untuk sebagian besar aplikasi.

Anda sebaiknya menghindari penggunaan mode MODE_WORLD_WRITEABLE atau mode MODE_WORLD_READABLE untuk file IPC yang aman karena mereka tidak memberikan kemampuan untuk membatasi akses data ke aplikasi tertentu, juga tidak memberikan kontrol apa pun pada format data. Jika Anda ingin berbagi data dengan proses aplikasi lainnya, Anda mungkin bisa mempertimbangkan penggunaan penyedia materi, yang menawarkan izin baca dan tulis untuk aplikasi lainnya serta dapat memberikan izin dinamis berdasarkan kasus-per-kasus.

Untuk memberikan perlindungan tambahan bagi data sensitif, Anda bisa memilih untuk mengenkripsi file lokal dengan menggunakan kunci yang tidak dapat diakses secara langsung oleh aplikasi. Misalnya, kunci bisa ditempatkan dalam KeyStore dan dilindungi dengan sandi pengguna yang tidak tersimpan pada perangkat. Meskipun ini tidak melindungi data dari kerentanan tingkat akar yang bisa memantau pengguna saat memasukkan sandi, ini dapat memberikan perlindungan bagi perangkat yang hilang tanpa enkripsi sistem file.

Menggunakan storage eksternal

File yang dibuat pada storage eksternal, seperti Kartu SD, secara global dapat dibaca dan ditulis. Karena storage eksternal bisa dilepas oleh pengguna dan juga dimodifikasi oleh semua aplikasi, Anda sebaiknya tidak menyimpan informasi sensitif menggunakan storage eksternal.

Sebagaimana dengan data dari sumber yang tidak tepercaya, Anda sebaiknya melakukan validasi masukan saat menangani data dari storage eksternal. Kami sangat menyarankan agar Anda tidak menyimpan file yang dapat dieksekusi atau file kelas pada storage eksternal sebelum pemuatan dinamis. Jika aplikasi Anda tidak mengambil file yang dapat dieksekusi dari storage eksternal, file seharusnya ditandatangani dan secara kriptografi diverifikasi sebelum pemuatan dinamis.

Menggunakan penyedia materi

Penyedia materi menawarkan mekanisme storage terstruktur yang bisa dibatasi hanya untuk aplikasi Anda sendiri atau diekspor untuk mengizinkan akses oleh aplikasi lainnya. Jika Anda tidak berniat untuk memberikan aplikasi lain akses ke ContentProvider, tandai mereka sebagai android:exported=false dalam manifes aplikasi. Jika tidak, setel atribut android:exported ke "true" untuk mengizinkan aplikasi lain mengakses data yang tersimpan.

Saat membuat ContentProvider yang akan diekspor untuk digunakan oleh aplikasi lain, Anda bisa menetapkan izin tunggal untuk membaca dan menulis, atau izin yang berbeda untuk membaca dan menulis dalam manifes. Kami menyarankan agar Anda membatasi izin hanya dengan yang dibutuhkan untuk menyelesaikan tugas yang dikerjakan. Harap diingat bahwa biasanya lebih mudah untuk menambahkan izin belakangan untuk mengekspos fungsionalitas baru dibandingkan membawanya dan memecah pengguna yang ada.

Jika Anda menggunakan penyedia materi untuk berbagi data hanya dalam aplikasi Anda sendiri, lebih baik menggunakan atribut android:protectionLevel disetel ke perlindungan "signature". Izin tanda tangan tidak memerlukan konfirmasi pengguna, sehingga mereka memberikan pengalaman pengguna yang lebih baik dan akses lebih terkontrol ke data penyedia materi ketika aplikasi mengakses data yang ditandatangani dengan tombol yang sama.

Penyedia materi juga bisa memberikan akses lebih terperinci dengan mendeklarasikan atribut android:grantUriPermissions serta menggunakan flag FLAG_GRANT_READ_URI_PERMISSION dan FLAG_GRANT_WRITE_URI_PERMISSION di objek Intent yang mengaktifkan komponen. Cakupan izin ini bisa dibatasi lebih jauh oleh <grant-uri-permission element>.

Ketika mengakses penyedia materi, gunakan metode kueri berparameter seperti query(), update(), dan delete() untuk menghindari potensi injeksi SQL dari sumber tak terpercaya. Perhatikan bahwa menggunakan metode berparameter tidak cukup jika argumen selection dibangun dengan menggabungkan data pengguna sebelum mengirimkannya ke metode.

Jangan ada rasa aman semu dalam izin tulis. Pertimbangkan bahwa izin tulis membolehkan pernyataan SQL yang memungkinkan beberapa data dikonfirmasi menggunakan klausa WHERE kreatif dan mengurai hasilnya. Misalnya, penyerang mungkin mengorek keberadaan nomor telepon tertentu dalam log-panggilan dengan memodifikasi baris hanya jika nomor telepon tersebut sudah ada. Jika data penyedia materi memiliki struktur yang bisa diprediksi, izin tulis mungkin setara dengan menyediakan izin membaca dan menulis.

Menggunakan Izin

Karena Android melakukan sandbox aplikasi satu dengan lainnya, aplikasi harus secara eksplisit berbagi sumber daya dan data. Mereka melakukannya dengan mendeklarasikan izin yang dibutuhkan untuk menambahkan kemampuan yang tidak disediakan oleh kotak pasir dasar, termasuk akses ke fitur perangkat seperti kamera.

Meminta Izin

Kami menyarankan untuk meminimalkan jumlah izin yang diminta aplikasi Anda. Tidak memiliki akses ke izin sensitif akan mengurangi risiko penyalahgunaan izin tanpa disengaja, bisa meningkatkan penerimaan pengguna, dan membuat aplikasi Anda lebih tahan dari serangan. Secara umum, jika suatu izin tidak diperlukan oleh aplikasi untuk bisa berfungsi, jangan memintanya.

Jika dimungkinkan untuk mendesain aplikasi dengan cara yang tidak memerlukan izin apa pun, itu lebih baik. Misalnya, daripada meminta akses ke informasi perangkat untuk membuat identifier unik, buatlah GUID untuk aplikasi Anda (lihat bagian tentang Menangani Data Pengguna). Atau, daripada menggunakan storage eksternal (yang memerlukan izin), simpan data pada storage internal.

Selain meminta izin, aplikasi Anda bisa menggunakan <permissions> untuk melindungi IPC yang sensitif-keamanan dan akan terekspos ke aplikasi lain, seperti ContentProvider. Biasanya, kami menyarankan penggunaan kontrol akses selain izin yang dikonfirmasi pengguna bila memungkinkan karena izin bisa membingungkan pengguna. Misalnya, pertimbangkan untuk menggunakan tingkat perlindungan tanda tangan pada izin untuk komunikasi IPC antar aplikasi yang disediakan oleh developer tunggal.

Jangan bocorkan data yang dilindungi-izin. Hal ini terjadi bila aplikasi Anda mengekspos data melalui IPC yang tersedia hanya karena aplikasi memiliki izin untuk mengakses data tersebut. Klien antarmuka IPC aplikasi Anda mungkin tidak memiliki izin akses data yang sama. Detail selengkapnya tentang efek potensial dan frekuensi dari masalah, muncul dalam makalah penelitian ini, yang dipublikasikan di USENIX.

Membuat Izin

Biasanya, Anda harus berusaha untuk mendefinisikan izin seminimal mungkin sambil memenuhi persyaratan keamanan. Membuat izin baru bukanlah hal biasa untuk sebagian besar aplikasi, karena izin yang didefinisikan-sistem mencakup banyak situasi. Ketika memungkinkan, lakukan pemeriksaan akses menggunakan izin yang ada.

Jika Anda harus membuat izin baru, pertimbangkan apakah Anda bisa menyelesaikan tugas dengan tingkat perlindungan "tanda tangan". Izin tanda tangan harus transparan kepada pengguna dan hanya mengizinkan akses oleh aplikasi yang ditandatangani oleh developer yang sama ketika aplikasi melakukan pemeriksaan izin.

Jika Anda membuat izin dengan tingkat perlindungan "berbahaya", ada sejumlah kompleksitas yang perlu Anda pertimbangkan:

  • Izin harus memiliki string yang secara singkat menyatakan kepada pengguna tentang keputusan keamanan yang harus mereka buat.
  • String izin harus diterjemahkan ke berbagai bahasa.
  • Pengguna mungkin memilih untuk tidak memasang aplikasi karena suatu izin membingungkan atau dianggap berisiko.
  • Aplikasi bisa meminta izin ketika pembuat izin belum dipasang.

Masing-masing memberikan tantangan non-teknis yang besar untuk Anda sebagai developer sekaligus juga membingungkan pengguna, itulah sebabnya mengapa kami tidak menyarankan penggunaan tingkat izin "berbahaya".

Menggunakan Jaringan

Transaksi jaringan berisiko untuk keamanan, karena berpotensi melibatkan transmisi data yang bersifat pribadi bagi pengguna. Orang semakin sadar akan masalah privasi pada perangkat seluler, terutama ketika perangkat melakukan transaksi jaringan, sehingga sangat penting bahwa aplikasi Anda mengimplementasikan semua praktik terbaik menjaga keamanan data pengguna setiap saat.

Menggunakan Jaringan IP

Jaringan pada Android tidak berbeda secara signifikan dari lingkungan Linux lainnya. Pertimbangan utamanya adalah memastikan bahwa protokol yang tepat digunakan untuk data sensitif, seperti HttpsURLConnection untuk lalu lintas web yang aman. Kami lebih suka menggunakan HTTPS dibandingkan HTTP setiap kali HTTPS didukung pada server, karena perangkat seluler sering terhubung pada jaringan yang tidak aman, seperti hotspot Wi-Fi publik.

Komunikasi tingkat soket dienkripsi dan terautentikasi bisa dengan mudah diimplementasikan menggunakan kelas SSLSocket. Mengingat seringnya perangkat Android terhubung ke jaringan nirkabel tidak aman menggunakan Wi-Fi, penggunaan jaringan aman sangat dianjurkan untuk semua aplikasi yang berkomunikasi melalui jaringan.

Kami telah melihat beberapa aplikasi menggunakan porta jaringan localhost untuk menangani IPC sensitif. Kami tidak menyarankan pendekatan ini karena antarmuka tersebut bisa diakses oleh aplikasi lain pada perangkat. Sebagai gantinya, Anda harus menggunakan mekanisme IPC Android bila autentikasi memungkinkan, sebagaimana dengan Service. (Yang lebih buruk daripada menggunakan loopback adalah dengan terikat ke INADDR_ANY karena aplikasi Anda bisa menerima permintaan dari mana saja.)

Juga, satu masalah umum yang menjamin pengulangan adalah memastikan bahwa Anda tidak memercayai data yang diunduh dari HTTP atau protokol tidak aman lainnya. Ini termasuk validasi masukan dalam WebView dan respons untuk maksud yang dikeluarkan terhadap HTTP.

Menggunakan Jaringan Telepon

Protokol SMS utamanya didesain untuk komunikasi pengguna ke pengguna dan tidak cocok untuk aplikasi yang melakukan transfer data. Karena keterbatasan SMS, kami sangat menyarankan penggunaan Google Cloud Messaging (GCM) dan jaringan IP untuk mengirim pesan data dari server web ke aplikasi Anda pada perangkat pengguna.

Berhati-hatilah karena SMS tidak dienkripsi dan tidak diautentikasi dengan baik di jaringan atau perangkat. Misalnya, setiap penerima SMS harus waspada bahwa orang jahat mungkin telah mengirim SMS ke aplikasi Anda—Jangan mengandalkan data SMS yang tidak terautentikasi untuk melakukan perintah sensitif. Anda juga harus tahu bahwa SMS bisa menjadi objek spoofing dan/atau cegatan pada jaringan. Pada perangkat Android, pesan SMS dikirim sebagai maksud siaran, sehingga mereka dapat dibaca atau direkam oleh aplikasi lain yang memiliki izin READ_SMS.

Melakukan Validasi Masukan

Validasi masukan yang tidak memadai adalah salah satu masalah keamanan paling umum yang memengaruhi aplikasi, terlepas dari platform yang mereka gunakan. Android memiliki penanggulangan tingkat-platform yang mengurangi ekspos aplikasi dari masalah validasi masukan dan Anda harus menggunakan fitur tersebut bila memungkinkan. Perhatikan juga bahwa pemilihan bahasa tipe-aman cenderung mengurangi kemungkinan masalah validasi masukan.

Jika Anda menggunakan kode asli, maka semua data yang dibaca dari file, diterima melalui jaringan, atau diterima dari IPC memiliki potensi untuk memunculkan masalah keamanan. Masalah yang paling umum adalah luapan buffer, use after free, dan off-by-one error. Android menyediakan sejumlah teknologi seperti ASLR dan DEP yang mengurangi tingkat eksploitasi kesalahan ini, namun mereka tidak memecahkan masalah pokoknya. Anda bisa menghindari celah keamanan ini dengan berhati-hati menangani pointer dan mengelola penyanggaan.

Bahasa berbasis string serta dinamis seperti JavaScript dan SQL juga terkena masalah validasi masukan karena karakter escape dan injeksi skrip.

Jika Anda menggunakan data dalam kueri yang diserahkan ke database SQL atau penyedia materi, injeksi SQL mungkin akan menjadi masalah. Pertahanan terbaik adalah dengan menggunakan kueri parameter, seperti yang dibahas pada bagian atas tentang penyedia materi. Membatasi izin ke hanya-baca atau hanya-tulis juga bisa mengurangi potensi bahaya yang berhubungan dengan injeksi SQL.

Jika Anda tidak bisa menggunakan fitur keamanan di atas, kami sangat menyarankan penggunaan format data yang terstruktur dengan baik dan memverifikasi bahwa data sesuai dengan format yang diharapkan. Meskipun membuat daftar hitam karakter atau karakter-pengganti bisa menjadi strategi efektif, teknik ini rawan kesalahan dalam praktiknya dan harus dihindari bila memungkinkan.

Menangani Data Pengguna

Secara umum, pendekatan terbaik untuk keamanan data pengguna adalah dengan meminimalkan penggunaan API yang mengakses data pengguna rahasia atau pribadi. Jika Anda memiliki akses ke data pengguna dan bisa menghindari menyimpan atau mengirimkan informasi, jangan simpan atau kirimkan data tersebut. Yang terakhir, pertimbangkan jika ada suatu cara sehingga logika aplikasi Anda bisa diimplementasikan dengan menggunakan hash atau bentuk data non-reversibel. Misalnya, aplikasi Anda mungkin menggunakan hash alamat email sebagai kunci utama, untuk menghindari pengiriman atau storage alamat email. Hal ini mengurangi kemungkinan data secara tidak sengaja terpapar, dan juga mengurangi kemungkinan penyerang mencoba untuk mengeksploitasi aplikasi Anda.

Jika aplikasi Anda mengakses informasi pribadi seperti sandi atau nama pengguna, harap ingat bahwa beberapa yurisdiksi mengharuskan Anda untuk memberikan kebijakan privasi yang menjelaskan penggunaan dan storage data tersebut. Jadi mengikuti praktik terbaik keamanan untuk meminimalkan akses ke data pengguna juga dapat menyederhanakan kepatuhan.

Anda juga harus mempertimbangkan apakah aplikasi mungkin secara tidak sengaja mengekspos informasi pribadi kepada pihak lain seperti komponen pihak ketiga untuk iklan atau layanan pihak ketiga yang digunakan oleh aplikasi Anda. Jika Anda tidak tahu mengapa komponen atau layanan membutuhkan informasi pribadi, jangan memberikannya. Secara umum, mengurangi akses aplikasi ke informasi pribadi akan mengurangi potensi masalah di area ini.

Jika diperlukan akses ke data sensitif, pertimbangkan apakah informasi tersebut harus dikirimkan ke server, atau apakah operasi dapat dilakukan pada klien. Pertimbangkan menjalankan semua kode menggunakan data sensitif pada klien untuk menghindari mengirimkan data pengguna.

Juga, pastikan bahwa Anda tidak secara sengaja mengekspos data pengguna ke aplikasi lain pada perangkat melalui IPC yang terlalu permisif, file dapat ditulis publik, atau soket jaringan. Ini adalah kasus khusus dari membocorkan data yang dilindungi-izin, dibahas di bagian Meminta Izin.

Jika GUID diperlukan, buat nomor besar yang unik dan simpanlah. Jangan gunakan identifier ponsel seperti nomor telepon atau IMEI yang mungkin terkait dengan informasi pribadi. Topik ini dibahas secara lebih rinci dalam Android Developer Blog.

Hati-hati saat menulis ke log pada-perangkat. Di Android, log adalah sumber daya bersama, dan tersedia untuk aplikasi dengan izin READ_LOGS. Meskipun data log ponsel bersifat temporer dan terhapus saat boot ulang, pembuatan log yang tidak benar mengenai informasi pengguna bisa secara tidak sengaja membocorkan data pengguna ke aplikasi lain.

Menggunakan WebView

Karena WebView memakai materi web yang bisa berisi HTML dan JavaScript, kesalahan dalam penggunaan bisa memunculkan masalah keamanan web umum seperti cross-site-scripting (injeksi JavaScript). Android mencakup sejumlah mekanisme untuk mengurangi cakupan masalah potensial ini dengan membatasi kemampuan WebView dengan fungsionalitas minimum yang diperlukan oleh aplikasi Anda.

Jika aplikasi Anda tidak secara langsung menggunakan JavaScript dalam WebView, jangan panggil setJavaScriptEnabled(). Beberapa kode contoh menggunakan metode ini, yang mungkin Anda gunakan kembali dalam aplikasi produksi, karena itu buanglah panggilan metode ini bila tidak diperlukan. Secara default, WebView tidak mengeksekusi JavaScript sehingga cross-site-scripting tidak mungkin dilakukan.

Gunakan addJavaScriptInterface() dengan penanganan khusus karena itu mengizinkan JavaScript untuk memanggil operasi yang biasanya disediakan untuk aplikasi Android. Jika Anda menggunakannya, eksposlah addJavaScriptInterface() hanya ke laman web dengan semua masukan dapat dipercaya. Jika masukan tak-tepercaya diperbolehkan, JavaScript tak-tepercaya mungkin bisa memanggil metode Android dalam aplikasi Anda. Secara umum, kami menyarankan mengekspos addJavaScriptInterface() hanya untuk JavaScript yang terkandung dalam APK aplikasi Anda.

Jika aplikasi Anda mengakses data sensitif dengan WebView, Anda mungkin ingin menggunakan metode clearCache() untuk menghapus file yang disimpan secara lokal. Header sisi server seperti no-cache juga bisa digunakan untuk menunjukkan bahwa aplikasi sebaiknya tidak meng-cache materi tertentu.

Perangkat yang menjalankan platform lebih lama dari Android 4.4 (API level 19) menggunakan versi webkit yang memiliki sejumlah masalah keamanan. Sebagai solusinya, jika aplikasi Anda berjalan pada perangkat ini, itu harus mengkonfirmasi bahwa objek WebView hanya menampilkan materi tepercaya. Anda sebaiknya juga menggunakan objek Provider keamanan yang bisa diperbarui untuk memastikan aplikasi Anda tidak mengalami kerentanan potensial dalam SSL, seperti yang dijelaskan dalam Memperbarui Penyedia Keamanan Agar Terlindung Dari Eksploitasi SSL. Jika aplikasi Anda harus me-render materi dari web terbuka, pertimbangkan untuk menyediakan renderer sendiri sehingga Anda bisa selalu memperbaruinya dengan patch keamanan terbaru.

Menangani Kredensial

Secara umum, kami menyarankan meminimalkan frekuensi permintaan kredensial pengguna—agar serangan phishing lebih terlihat, dan kemungkinan besar tidak berhasil. Sebagai gantinya gunakan token otorisasi dan segarkan.

Bila memungkinkan, nama pengguna dan sandi sebaiknya tidak disimpan pada perangkat. Sebagai gantinya, lakukan autentikasi awal menggunakan nama pengguna dan sandi yang diberikan oleh pengguna, dan kemudian menggunakan token otorisasi khusus layanan berjangka-pendek.

Layanan yang bisa diakses oleh beberapa aplikasi harus diakses menggunakan AccountManager. Jika memungkinkan, gunakan kelas AccountManager untuk meminta layanan berbasis awan dan jangan menyimpan sandi pada perangkat.

Setelah menggunakan AccountManager untuk mengambil Account, CREATOR sebelum meneruskan kredensial apa pun, sehingga Anda tidak meneruskan kredensial ke aplikasi yang salah tanpa disengaja.

Jika kredensial hanya akan digunakan oleh aplikasi yang Anda buat, maka Anda bisa memverifikasi aplikasi yang mengakses AccountManager menggunakan checkSignature(). Atau, jika hanya satu aplikasi yang akan menggunakan kredensial, Anda bisa menggunakan KeyStore untuk storage.

Menggunakan Kriptografi

Selain menyediakan isolasi data, mendukung enkripsi sistem file penuh, dan menyediakan saluran komunikasi yang aman, Android menyediakan beragam algoritme untuk melindungi data menggunakan kriptografi.

Secara umum, cobalah untuk menggunakan tingkat tertinggi implementasi kerangka kerja yang sudah ada sebelumnya yang bisa mendukung kasus penggunaan Anda. Jika Anda perlu untuk secara aman mengambil file dari lokasi yang dikenal, HTTPS URI sederhana mungkin mencukupi dan tidak memerlukan pengetahuan tentang kriptografi. Jika Anda membutuhkan saluran aman, pertimbangkan untuk menggunakan HttpsURLConnection atau SSLSocket, daripada menulis protokol sendiri.

Jika Anda merasa perlu untuk mengimplementasikan protokol sendiri, kami sangat menyarankan agar Anda tidak mengimplementasikan algoritme kriptografik sendiri. Gunakan algoritme kriptografik seperti yang ada dalam implementasi AES atau RSA yang tersedia di kelas Cipher.

Gunakan pembuat nomor acak yang aman, SecureRandom, untuk melakukan inisialiasi setiap kunci kriptografik, KeyGenerator. Penggunaan kunci yang tidak dibuat dengan pembuat nomor acak yang aman secara signifikan melemahkan kekuatan algoritme, dan memungkinkan serangan offline.

Jika Anda perlu menyimpan kunci untuk penggunaan berulang, gunakan mekanisme seperti KeyStore yang menyediakan mekanisme untuk storage jangka panjang dan pengambilan kunci kriptografik.

Menggunakan Komunikasi Antarproses

Beberapa aplikasi mencoba untuk mengimplementasikan IPC menggunakan teknik Linux tradisional seperti soket jaringan dan file bersama. Kami sangat menganjurkan agar Anda menggunakan fungsionalitas sistem Android untuk IPC seperti Intent, Binder atau Messenger dengan Service, dan BroadcastReceiver. Mekanisme Android IPC memungkinkan Anda untuk memverifikasi identitas aplikasi yang terhubung ke IPC Anda dan menyetel kebijakan keamanan untuk setiap mekanisme IPC.

Banyak elemen keamanan dibagikan bersama dalam mekanisme IPC. Jika mekanisme IPC Anda tidak dimaksudkan untuk digunakan oleh aplikasi lain, atur atribut android:exported ke "false" dalam elemen manifes komponen, seperti untuk elemen <service>. Hal ini berguna untuk aplikasi yang terdiri dari beberapa proses dalam UID yang sama, atau jika Anda memutuskan di akhir-akhir development bahwa Anda sebenarnya tidak ingin mengekspos fungsionalitas sebagai IPC namun Anda tidak ingin menulis ulang kode.

Jika IPC Anda dimaksudkan untuk dapat diakses aplikasi lain, Anda bisa menerapkan kebijakan keamanan dengan menggunakan elemen <permission>. Jika IPC berada di antara aplikasi terpisah Anda sendiri yang ditandatangani dengan kunci yang sama, lebih baik untuk menggunakan izin tingkat "signature" di android:protectionLevel.

Menggunakan maksud

Maksud adalah mekanisme yang lebih disukai untuk IPC asinkron di Android. Bergantung pada persyaratan aplikasi, Anda mungkin menggunakan sendBroadcast(), sendOrderedBroadcast(), atau maksud eksplisit untuk komponen aplikasi tertentu.

Perhatikan siaran yang dipesan bisa "dipakai" oleh penerima, sehingga mereka tidak dapat dikirimkan ke semua aplikasi. Jika Anda mengirim maksud yang harus disampaikan ke penerima tertentu, maka Anda harus menggunakan maksud eksplisit yang mendeklarasikan penerima berdasar nama maksud.

Pengirim maksud dapat memverifikasi bahwa penerima memiliki izin yang menetapkan izin non-Null dengan panggilan metode. Hanya aplikasi dengan izin tersebut yang akan menerima maksud. Jika data dalam maksud siaran mungkin sensitif, Anda harus mempertimbangkan menerapkan izin untuk memastikan bahwa aplikasi berbahaya tidak dapat mendaftar untuk menerima pesan tersebut tanpa izin yang sesuai. Dalam situasi seperti itu, Anda juga dapat mempertimbangkan memanggil penerima secara langsung, daripada menaikkan siaran.

Catatan: Filter maksud seharusnya tidak dianggap sebagai fitur keamanan—komponen bisa dipanggil dengan maksud eksplisit dan mungkin tidak memiliki data yang sesuai dengan filter maksud. Anda harus melakukan validasi masukan dalam penerima maksud untuk mengkonfirmasi bahwa itu diformat dengan benar untuk penerima, layanan, atau aktivitas yang dipanggil.

Menggunakan layanan

Sebuah Service sering digunakan untuk memasok fungsionalitas yang akan digunakan aplikasi lain. Setiap kelas layanan harus memiliki deklarasi <service> yang sesuai di file manifesnya.

Secara default, layanan tidak diekspor dan tidak bisa dipanggil oleh aplikasi lainnya. Akan tetapi, jika Anda menambahkan filter maksud untuk deklarasi layanan, maka itu diekspor secara default. Sangat baik jika Anda secara eksplisit mendeklarasikan atribut android:exported untuk memastikan perilakunya seperti yang Anda inginkan. Layanan juga bisa dilindungi dengan menggunakan atribut android:permission. Dengan demikian, aplikasi lain perlu mendeklarasikan elemen <uses-permission> yang sesuai dalam manifesnya sendiri untuk dapat memulai, menghentikan, atau mengikat ke layanan.

Sebuah layanan bisa melindungi panggilan IPC individual ke dalamnya dengan izin, dengan memanggil checkCallingPermission() sebelum menjalankan implementasi panggilan tersebut. Kami biasanya menyarankan untuk menggunakan izin deklaratif dalam manifes, karena mengurangi kerawanan terhadap kesalahan.

Menggunakan antarmuka pengikat dan messenger

Menggunakan Binder atau Messenger adalah mekanisme yang dipilih untuk IPC model-PPK di Android. Mereka menyediakan antarmuka yang didefinisikan dengan baik yang memungkinkan autentikasi endpoint saling menguntungkan, jika diperlukan.

Kami sangat menyarankan untuk mendesain antarmuka dengan cara yang tidak memerlukan pemeriksaan izin khusus antarmuka. Objek Binder dan Messenger tidak dideklarasikan dalam manifes aplikasi, sehingga Anda tidak bisa menerapkan izin deklaratif secara langsung kepada mereka. Mereka biasanya mewarisi izin yang dideklarasikan dalam manifes aplikasi untuk Service atau Activity tempat mereka diimplementasikan. Jika Anda membuat sebuah antarmuka yang memerlukan autentikasi dan/atau kontrol akses, kontrol tersebut harus secara eksplisit ditambahkan sebagai kode di antarmuka Binder atau Messenger.

Jika menyediakan antarmuka yang memerlukan kontrol akses, gunakan checkCallingPermission() untuk memverifikasi apakah pemanggil memiliki izin yang diperlukan. Hal ini terutama sangat penting sebelum mengakses layanan atas nama pemanggil, karena pengenal aplikasi Anda akan diteruskan ke antarmuka lainnya. Jika permintaan sebuah antarmuka disediakan oleh Service, permintaan bindService() mungkin gagal jika Anda tidak memiliki izin untuk mengakses layanan yang diberikan. Jika memanggil antarmuka yang disediakan secara lokal oleh aplikasi Anda sendiri, ada baiknya untuk menggunakan clearCallingIdentity() untuk memenuhi pemeriksaan keamanan internal.

Untuk informasi selengkapnya tentang melakukan IPC dengan layanan, lihat Layanan Terikat.

Menggunakan penerima siaran

Sebuah BroadcastReceiver menangani permintaan asinkron yang diinisiasi oleh Intent.

Secara default, penerima diekspor dan dapat dipanggil oleh aplikasi lainnya. Jika BroadcastReceiver Anda dimaksudkan untuk digunakan oleh aplikasi lain, Anda mungkin ingin menerapkan izin keamanan untuk penerima menggunakan elemen <receiver> dalam manifes aplikasi. Ini akan mencegah aplikasi tanpa izin yang sesuai dari mengirim maksud ke BroadcastReceiver.

Secara Dinamis Memuat Kode

Kami sangat tidak menyarankan memuat kode selain APK aplikasi Anda. Melakukan ini akan secara signifikan meningkatkan kemungkinan kerentanan aplikasi karena injeksi kode atau sabotase kode. Hal ini juga menambah kompleksitas di sekitar manajemen versi dan pengujian aplikasi. Yang terakhir, hal itu dapat membuat verifikasi perilaku aplikasi tidak mungkin dilakukan, sehingga di beberapa lingkungan mungkin dilarang.

Jika aplikasi Anda tidak secara dinamis memuat kode, hal yang paling penting untuk diingat mengenai kode yang dimuat secara dinamis adalah bahwa kode berjalan dengan izin keamanan yang sama dengan APK aplikasi. Pengguna membuat keputusan untuk memasang aplikasi berdasarkan identitas Anda, dan mereka mengharapkan Anda memberikan semua kode yang berjalan dalam aplikasi, termasuk kode yang dimuat secara dinamis.

Risiko keamanan utama yang terkait dengan pemuatan kode secara dinamis adalah bahwa kode harus datang dari sumber yang dapat diverifikasi. Jika modul disertakan langsung dalam APK Anda, maka mereka tidak dapat diubah oleh aplikasi lain. Hal ini berlaku baik bila kodenya adalah pustaka asli atau pun kelas yang dimuat menggunakan DexClassLoader. Kami telah melihat banyak instance aplikasi mencoba untuk memuat kode dari lokasi yang tidak aman, seperti diunduh dari jaringan melalui protokol tak terenkripsi atau dari lokasi yang bisa ditulisi publik seperti storage eksternal. Lokasi ini bisa memungkinkan seseorang pada jaringan untuk memodifikasi materi dalam pengiriman, atau aplikasi lain pada perangkat pengguna untuk memodifikasi materi pada perangkat.

Keamanan dalam Mesin Virtual

Dalvik adalah mesin virtual (VM) waktu proses Android. Dalvik dibangun khusus untuk Android, namun banyak kekhawatiran mengenai kode keamanan di mesin virtual lainnya juga berlaku pada Android. Biasanya, Anda tidak perlu mengkhawatirkan masalah keamanan yang berkaitan dengan mesin virtual. Aplikasi Anda berjalan di lingkungan kotak pasir aman, sehingga proses lain pada sistem tidak bisa mengakses kode atau data privat.

Jika Anda tertarik untuk lebih mendalami masalah keamanan mesin virtual, kami menyarankan agar Anda mempelajari beberapa literatur tentang masalah tersebut. Dua dari referensi yang populer adalah:

Dokumen ini berfokus pada area khusus Android atau berbeda dari lingkungan VM lainnya. Untuk developer yang berpengalaman dengan pemrograman VM di lingkungan lain, ada dua persoalan umum yang mungkin berbeda tentang penulisan aplikasi untuk Android:

  • Beberapa mesin virtual, seperti waktu proses JVM atau .net, bertindak sebagai batasan keamanan, memisahkan kode dari kemampuan sistem operasi yang mendasarinya. Pada Android, Dalvik VM bukanlan batasan keamanan—aplikasi kotak pasir diimplementasikan di tingkat OS, sehingga Dalvik bisa antaroperasi dengan kode asli di aplikasi yang sama tanpa kendala keamanan.
  • Mengingat storage yang terbatas pada perangkat seluler, hal biasa bagi developer saat ingin membangun aplikasi modular dan menggunakan pemuatan kelas dinamis. Bila melakukannya, pertimbangkan kedua sumber tempat Anda mengambil logika aplikasi dan tempat Anda menyimpannya secara lokal. Jangan gunakan pemuatan kelas dinamis dari sumber yang tidak diverifikasi, seperti sumber jaringan yang tidak aman atau storage eksternal, karena kode mungkin dimodifikasi untuk menyertakan perilaku berbahaya.

Keamanan dalam Kode Asli

Biasanya, kami mendorong developer untuk menggunakan Android SDK untuk development aplikasi, daripada menggunakan kode asli dengan Android NDK. Aplikasi yang dibangun dengan kode asli lebih kompleks, kurang ringkas, dan lebih sering berisi kesalahan korupsi memori umum seperti luapan buffer.

Android dibangun menggunakan kernel Linux dan familier dengan praktik terbaik keamanan development Linux akan sangat berguna jika Anda menggunakan kode asli. Praktik keamanan Linux berada di luar cakupan dokumen ini, namun salah satu referensi yang paling populer adalah “Secure Programming for Linux and Unix HOWTO”, yang tersedia di http://www.dwheeler.com/secure-programs.

Perbedaan besar antara Android dan kebanyakan lingkungan Linux adalah Kotak Pasir Aplikasi. Pada Android, semua aplikasi berjalan di Aplikas Kotak Pasir, termasuk yang ditulis dengan kode asli. Pada tingkat yang paling dasar, cara pikir yang baik untuk developer yang memahami Linux adalah mengetahui bahwa setiap aplikasi diberikan UID unik dengan izin sangat terbatas. Ini dibahas lebih detail dalam Ringkasan Keamanan Android dan Anda harus familier dengan izin aplikasi bahkan jika Anda menggunakan kode asli.