Halaman ini berisi Konten bantuan untuk penyedia SDK yang menggunakan Google Play SDK Console.
Jika Anda adalah developer aplikasi yang sedang mencari Konten bantuan Konsol Google Play, harap gunakan kotak penelusuran atau kembali ke halaman beranda.
Anda dapat menggunakan SDK Console untuk memantau potensi masalah kebijakan atau kerentanan keamanan yang memengaruhi versi SDK Anda. Anda harus terus memantau jenis masalah ini untuk menjaga keamanan Google Play, dan menghindari potensi konsekuensi negatif untuk SDK Anda. Hal ini dapat mencakup penghapusan badge pendaftaran atau akses terbatas ke fitur di Google Play SDK Console.
Versi SDK dengan potensi masalah kebijakan
Jika Anda memiliki versi SDK yang diketahui menyebabkan aplikasi yang menggunakannya melanggar kebijakan Persyaratan SDK kami atau kebijakan Program Developer Google Play lainnya, versi ini akan diberi label di SDK Console. Versi aplikasi baru yang dipublikasikan di Google Play menggunakan versi ini akan ditolak, dan developer akan diminta untuk menemukan versi yang mematuhi kebijakan sebelum mengirim ulang aplikasi mereka.
Screenshot di bawah menunjukkan contoh versi SDK dengan pelanggaran kebijakan yang ditandai:
Screenshot di bawah menunjukkan contoh versi SDK yang diperluas, yang menjelaskan masalah yang dilaporkan:
Sesuai dengan Persyaratan Layanan SDK Console, jika ada masalah kebijakan yang ditemukan di SDK Anda, Anda akan diberi tahu dan dipandu tentang cara memperbaikinya dan mengirimkan versi SDK baru untuk ditinjau. Setelah proses penegakan pada aplikasi yang sudah ada selesai, SDK Console akan memberikan label pada versi SDK yang bermasalah sebagai tidak mematuhi kebijakan, dan versi aplikasi baru yang memuatnya tidak akan dapat dirilis sampai beralih ke versi yang mematuhi kebijakan.
Potensi konsekuensi untuk pelanggaran kebijakan berulang terkait SDK
Google Play berkomitmen untuk mengembangkan ekosistem yang aman dan tepercaya bagi developer dan pengguna. Sebagai bagian dari komitmen ini, kami menerapkan pendekatan yang ditingkatkan untuk mengurangi pelanggaran berulang terhadap kebijakan Google Play yang disebabkan oleh SDK:
Bergantung pada tingkat keparahan dan frekuensi pelanggaran, konsekuensinya dapat termasuk, tetapi tidak terbatas pada:
- Penghapusan badge pendaftaran: Pelanggaran berulang dan/atau tingkat keparahan pelanggaran dapat menyebabkan penghapusan badge pendaftaran yang ditampilkan di Google Play SDK Index. Badge ini menunjukkan bahwa SDK terdaftar di Google Play SDK Console dan penyedia SDK ini telah menyetujui Persyaratan Layanan Google Play SDK Console, yang mencakup komitmen bahwa SDK mereka tidak akan menyebabkan aplikasi melanggar kebijakan Google Play.
- Akses terbatas ke fitur di Google Play SDK Console: Jika SDK menyebabkan pelanggaran kebijakan berulang oleh developer aplikasi atau tingkat keparahan pelanggaran oleh SDK, kami berhak menghapus akses ke fitur utama di SDK Console.
Catatan: Penyedia SDK tetap dapat menanyakan keputusan apa pun. Untuk mengetahui lebih lanjut, baca artikel Pusat Bantuan ini tentang menggunakan SDK dengan aman dan terlindungi serta Kebijakan Program Developer Google Play.
Versi SDK dengan potensi kerentanan keamanan
Kerentanan adalah kelemahan atau cacat dalam kode yang dapat dieksploitasi oleh pihak berniat jahat. SDK Console memberi tahu Anda tentang potensi kerentanan keamanan yang memengaruhi versi SDK Anda. Di bawah ini, Anda dapat menemukan informasi tentang kerentanan yang dapat memengaruhi SDK Anda, serta cara memperbaikinya.
Cara memperbaiki SDK yang berisi pola enkripsi yang tidak aman
SDK Anda berisi pola enkripsi yang tidak aman. Artinya, ciphertext dihasilkan bersama kunci rahasia, salt, atau initialization vector (IV) yang dikomputasi secara statis.
Jika menggunakan SDK Anda, aplikasi akan menerima pemberitahuan di Konsol Play. Untuk mencegah aplikasi yang menggunakan SDK mendapatkan pemberitahuan, Anda harus memperbaiki kerentanan di SDK.
Tinjau langkah-langkah di bawah ini untuk memperbaiki masalah di SDK Anda. Anda dapat menemukan lokasi kode enkripsi yang tidak aman di notifikasi SDK Console untuk SDK Anda.
Detail tambahan
Tinjau SDK Anda untuk melihat kunci, initialization vector, dan/atau salt yang dikomputasi secara statis yang digunakan dalam operasi enkripsi, dan pastikan nilai tersebut dibuat dengan aman. Misalnya, kode berikut menggunakan kunci rahasia dan initialization vector yang dapat dikomputasi secara statis:
// Pemberitahuan Console merujuk pada metode ini
public byte[] encryptionUtil(String key, String iv, byte[] plainText) {
Cipher cipher = Cipher.getInstance(“AES/GCM/NoPadding”);
SecretKeySpec keySpec = new SecretKeySpec(key.getBytes(), “AES”);
GCMParameterSpec paramSpec = new GCMParameterSpec(256, iv.getBytes());
cipher.init(Cipher.ENCRYPT_MODE, keySpec, paramSpec);
return cipher.doFinal(plainText);
}
// Kunci dan initialization vector yang tidak aman ada di sini dan harus diubah
byte[] cipherText = encryptionUtil(“abcdef...”, “010203040506”, plainText);
Nilai yang Dikomputasi secara Statis
Nilai yang dikomputasi secara statis adalah nilai yang sama pada setiap eksekusi fungsi. Nilai yang dikomputasi secara statis dapat diekstrak dari SDK Anda dan digunakan untuk menyerang data aplikasi yang dienkripsi. Sekalipun Anda memanipulasi kunci, initialization vector, dan salt dengan cara yang kompleks sebelum digunakan, nilai tersebut tetap tidak aman jika manipulasi yang sama digunakan untuk setiap eksekusi program.
Praktik Terbaik Android
Sebaiknya gunakan Jetpack Security untuk kriptografi simetris Jika SDK Anda mengenkripsi kunci API, informasi identitas pribadi (PII), atau data sensitif lainnya, Anda dapat menggunakan EncryptedSharedPreferences untuk menyimpan data ini dengan aman tanpa perlu mengkhawatirkan penerapan kunci rahasia, initialization vector, dan salt. Praktik terbaik dan contoh lebih lanjut tersedia di halaman ini. Untuk mengirim data ke sistem lain dengan aman, developer sebaiknya menggunakan TLS/SSL untuk mengamankan data saat pengiriman.
Jetpack Security memanfaatkan project open source Google, yang disebut Tink, untuk menangani enkripsi yang diautentikasi secara simetris. Untuk kasus penggunaan lanjutan mengenai operasi tingkat rendah, kami merekomendasikan Anda untuk langsung menggunakan Tink.
Jika praktik terbaik Android di atas tidak sesuai dengan kasus penggunaan Anda, dan Anda diwajibkan untuk mengelola kunci, initialization vector, dan salt secara eksplisit, maka kami merekomendasikan standar berikut:
- Kunci Rahasia: Kunci rahasia simetris harus benar-benar rahasia dan tidak dapat diprediksi. Untuk mengenkripsi data lokal, sebaiknya developer membuat kunci rahasia menggunakan pengacakan yang aman secara kriptografi (atau dari data buatan pengguna, jika menggunakan PBEKeySpecs) dan menyimpan kunci rahasia tersebut menggunakan AndroidKeystore.
- Initialization Vector: Initialization vector harus unik dan tidak dapat diprediksi di berbagai pesan, tetapi tidak harus rahasia. Sebaiknya developer membuat initialization vector menggunakan pengacakan yang aman secara kriptografi. Sebaiknya developer menyimpan atau mengirimkan initialization vector beserta ciphertext terkait.
- Salt: Salt harus unik dan tidak dapat diprediksi di berbagai hash, tetapi tidak harus rahasia. Sebaiknya developer membuat salt menggunakan pengacakan yang aman secara kriptografi. Sebaiknya developer menyimpan atau mengirimkan salt beserta hash terkait.
Cara memperbaiki SDK yang menggunakan mode enkripsi yang kurang aman
SDK Anda berisi enkripsi yang menggunakan mode AES/ECB yang kurang aman. Mengenkripsi konten menggunakan mode lemah ini dapat menyebabkan ciphertext yang lemah. Hal ini berpotensi membahayakan data pengguna.
Jika menggunakan SDK Anda, aplikasi akan menerima pemberitahuan di Konsol Play. Untuk mencegah aplikasi yang menggunakan SDK mendapatkan pemberitahuan, Anda harus memperbaiki kerentanan di SDK.
Tinjau langkah-langkah di bawah ini untuk memperbaiki masalah di SDK Anda. Anda dapat menemukan lokasi kode mode enkripsi yang kurang aman di notifikasi SDK Console untuk SDK Anda.
Detail tambahan
Tinjau SDK Anda untuk mengetahui tempat Cipher dijadikan instance. Mode konfigurasi berikut akan menyiratkan penggunaan AES/ECB yang tidak aman:
"AES"
"AES/ECB/NoPadding"
"AES/ECB/PKCS5Padding"
"AES/ECB/ISO10126Padding"
Misalnya, kode berikut menggunakan mode AES/ECB secara default karena "AES" diberikan:
// Pemberitahuan Console merujuk pada metode ini
public byte[] encryptionUtil(String key, String iv, byte[] plainText) {// Menggunakan mode AES/ECB secara default
Cipher cipher = Cipher.getInstance(“AES”);
SecretKeySpec keySpec = new SecretKeySpec(key.getBytes(), “AES”);
cipher.init(Cipher.ENCRYPT_MODE, keySpec, paramSpec);
cipher.init(Cipher.ENCRYPT_MODE, keySpec, paramSpec);
return cipher.doFinal(plainText);
}
Google menyarankan agar developer menggunakan “AES/GCM/NoPadding” bukan mode tidak aman yang disebutkan di atas.
Cara memperbaiki SDK yang berisi kode yang rentan terhadap Zip Path Traversal
Kode di SDK Anda berisi pola ekstrak yang tidak aman, yang dapat menyebabkan serangan Zip Path Traversal.
Jika menggunakan SDK Anda, aplikasi akan menerima pemberitahuan di Konsol Play. Untuk mencegah aplikasi yang menggunakan SDK mendapatkan pemberitahuan, Anda harus memperbaiki kerentanan di SDK.
Tinjau langkah-langkah mendetail di bawah ini untuk memperbaiki masalah di SDK Anda. Anda dapat menemukan lokasi kode pola zip yang tidak aman di notifikasi SDK Console untuk SDK Anda.
Detail tambahan
File zip dapat berisi entri (file atau direktori) yang berisi karakter path traversal (“../”) pada namanya. Jika developer mengekstrak entri file zip tersebut tanpa memvalidasi namanya, file tersebut dapat berpotensi menyebabkan serangan path traversal, yang menyebabkan penulisan dalam sembarang direktori atau bahkan menimpa file di folder pribadi aplikasi.
Sebaiknya perbaiki masalah ini di SDK Anda dengan memeriksa apakah jalur kanonis untuk file yang diekstrak berada di direktori yang diharapkan. Khususnya, sebelum menggunakan objek File yang dibuat menggunakan nilai yang ditampilkan metode getName() ZipEntry, selalu periksa apakah nilai yang ditampilkan File.GetcanonicalPath() berada di jalur direktori yang dimaksud. Contoh:
InputStream is = new InputStream(untrustedFileName);// SecurityException
ZipInputStream zis = new ZipInputStream(new BufferedInputStream(is));
while((ZipEntry ze = zis.getNextEntry()) != null) {
File f = new File(DIR, ze.getName());
String canonicalPath = f.getCanonicalPath();
if (!canonicalPath.startsWith(DIR)) {
}// Selesai mengekstrak...
}
Cara memperbaiki SDK yang berisi kerentanan PendingIntent Implisit
SDK Anda berisi masalah PendingIntent Implisit yang mungkin menyebabkan ancaman keamanan dalam bentuk denial of service, pencurian data pribadi, dan eskalasi akses.
Jika menggunakan SDK Anda, aplikasi akan menerima pemberitahuan di Konsol Play. Untuk mencegah aplikasi yang menggunakan SDK mendapatkan pemberitahuan, Anda harus memperbaiki kerentanan di SDK.
Harap tinjau langkah-langkah mendetail di bawah ini untuk memperbaiki masalah di SDK Anda. Anda dapat menemukan lokasi kode penggunaan PendingIntent Implisit dalam notifikasi SDK Console untuk SDK Anda.
Detail tambahan
Aplikasi Android mengirim pesan antar komponen menggunakan Intent. Intent dapat menentukan komponen target (Intent Eksplisit) atau mencantumkan tindakan umum dan memungkinkan sistem operasi mengirim Intent ke komponen apa pun pada perangkat yang mendaftarkan Filter Intent yang cocok dengan tindakan tersebut (Intent Implisit).
PendingIntent adalah Intent yang didelegasikan ke aplikasi lain untuk dikirim di waktu mendatang. Membuat intent implisit yang digabungkan dengan PendingIntent adalah kerentanan keamanan yang dapat menyebabkan denial-of-service, pencurian data pribadi, dan eskalasi akses.
Tinjau SDK Anda untuk mengetahui tempat dibuatnya PendingIntent. Misalnya, kode berikut membuat PendingIntent yang menggabungkan Intent implisit:
// Membuat Intent dasar implisit dan menggabungkannya dalam PendingIntent
Intent base = new Intent("ACTION_FOO");
base.setPackage("some_package");
PendingIntent pi = PendingIntent.getService(this, 0, base, 0);
Google menyarankan developer untuk memperbaiki kerentanan dengan menerapkan salah satu (atau bahkan) semua hal berikut:
- Memastikan bahwa tindakan, paket, dan kolom komponen Intent dasar telah ditetapkan;
- Memastikan bahwa PendingIntent hanya dikirim ke komponen tepercaya;
- Menggunakan FLAG_IMMUTABLE (ditambahkan di SDK 23) untuk membuat PendingIntent. Hal ini mencegah aplikasi yang menerima PendingIntent agar tidak mengisi properti yang kosong. Jika aplikasi juga berjalan di perangkat yang menjalankan SDK 22 atau yang lebih lama, sebaiknya developer menerapkan opsi sebelumnya sambil memperkuat pembuatan PendingIntent dengan pola:
if (android.os.Build.VERSION.SDK_INT >= 23) {
// Membuat PendingIntent menggunakan FLAG_IMMUTABLE
} else {
// Kode yang ada yang membuat PendingIntent
}
Cara memperbaiki SDK yang berisi kerentanan Intent Internal Implisit
SDK Anda berisi masalahIntent Internal Implisit. Intent implisit yang digunakan untuk menjangkau komponen internal memungkinkan penyerang menyadap pesan, lalu menghapus, membaca konten, atau bahkan mengganti konten pesan.
Jika menggunakan SDK Anda yang rentan, aplikasi akan menerima pemberitahuan di Konsol Play. Untuk mencegah aplikasi yang menggunakan SDK Anda mendapatkan pemberitahuan, Anda harus memperbaiki kerentanan di SDK.
Tinjau langkah-langkah mendetail di bawah ini untuk memperbaiki masalah di SDK Anda. Anda dapat menemukan lokasi penggunaan Intent Implisit di SDK Anda di notifikasi SDK Console untuk SDK Anda.
Detail tambahan
Tinjau aplikasi Anda untuk mengetahui tempat Intent Implisit digunakan. Misalnya, kode berikut menggunakan Intent Implisit untuk menjangkau komponen internal:
//Aplikasi memiliki komponen yang mendaftarkan MY_CUSTOM_ACTION, yang hanya
//didaftarkan oleh aplikasi ini, menunjukkan bahwa dev bermaksud agar Intent ini;
//dikirimkan ke komponen internal dengan aman.
Intent intent = new Intent("MY_CUSTOM_ACTION");
//Tambahkan konten yang berpotensi sensitif ke 'intent'
intent.putExtra("message", sensitive_content);
startActivity(intent);
Google menyarankan agar developer menggunakan Intent Eksplisit untuk menjangkau komponen internalnya dengan:
- Menggunakan Intent.setComponent menetapkan komponen secara eksplisit guna menangani Intent.
- Menggunakan Intent.setClass atau Intent.setClassName untuk menetapkan komponen target secara eksplisit.
- Menggunakan Intent.setPackage untuk membatasi komponen yang akan diselesaikan Intent ini.
Cara memperbaiki SDK yang berisi library JavaScript yang rentan
SDK Anda berisi satu atau beberapa library JavaScript yang memiliki masalah keamanan umum (misalnya, eksposur dan kerentanan umum — CVE). Menyertakan library yang rentan tersebut di SDK Anda dapat membahayakan pengguna aplikasi.
Jika menggunakan SDK Anda yang rentan, aplikasi akan menerima pemberitahuan di Konsol Play. Untuk mencegah aplikasi yang menggunakan SDK Anda mendapatkan pemberitahuan, Anda harus memperbaiki masalah tersebut di SDK.
Tinjau langkah-langkah mendetail di bawah ini untuk memperbaiki masalah di SDK Anda. Anda dapat menemukan daftar library tidak aman dan terdeteksi beserta versinya yang digunakan dalam SDK Anda di notifikasi SDK Console untuk SDK Anda.
Detail tambahan
Untuk mengatasi masalah ini, Anda dapat melakukan salah satu dari tiga tindakan berikut untuk setiap library yang terdeteksi tidak aman:
- Gunakan library versi terbaru: Jika SDK Anda memiliki dependensi langsung pada versi library yang terdeteksi tidak aman, dan masalah keamanan itu telah diselesaikan dalam versi terbaru library tersebut, membuat ulang SDK dengan versi terbaru akan menyelesaikan masalah.
- Hubungi developer library: Mungkin library masih dikelola, tetapi masalah keamanan belum diperbaiki. Mungkin juga SDK Anda memiliki dependensi transitif pada library yang terdeteksi tidak aman (yaitu, SDK bergantung secara langsung pada sebuah library, yang selanjutnya bergantung pada library yang tidak aman). Dalam situasi semacam ini, hubungi developer library untuk memperbaiki masalah.
- Cari alternatif: Jika library tidak aman yang memiliki satu atau beberapa masalah keamanan tidak lagi dipertahankan, cobalah mencari dan menggunakan library alternatif yang aman.
Cara memperbaiki SDK yang menggunakan WebView untuk autentikasi
SDK Anda menggunakan WebView untuk autentikasi, dan tindakan ini tidak direkomendasikan. Menggunakan WebView untuk permintaan OAuth 2.0 secara negatif memengaruhi keamanan dan kegunaan aplikasi yang menggunakan SDK Anda. Tinjau langkah-langkah di bawah ini untuk memperbaiki masalah di SDK Anda.
Jika menggunakan SDK Anda, aplikasi akan menerima pemberitahuan di Konsol Play. Untuk mencegah aplikasi yang menggunakan SDK mendapatkan pemberitahuan, Anda harus memperbaiki kerentanan di SDK.
Anda dapat menemukan lokasi kode permintaan OAuth 2.0 melalui WebView di SDK dalam notifikasi SDK Console untuk SDK Anda.
Detail tambahan
Sejak rilis Tab Khusus Chrome, Google merekomendasikan agar developer tidak menggunakan WebViews untuk autentikasi. Menggunakan OAuth untuk autentikasi di WebView dapat membuat aplikasi yang menggunakan SDK Anda rentan terhadap masalah keamanan dan membahayakan kegunaan dengan memutuskan sambungan pengguna dari sesi single sign-on. Tab Khusus Chrome mencegah masalah ini.
- Tinjau SDK Anda untuk mengetahui tempat permintaan OAuth 2.0 dilakukan melalui WebView.
- Google merekomendasikan agar developer mengganti WebView ini dengan Tab Khusus Chrome. Ikuti langkah-langkah dalam panduan penerapan Tab Khusus Chrome untuk menambahkan Tab Khusus Chrome ke SDK Anda.
- Gunakan Tab Khusus Chrome yang ditambahkan untuk menjalankan permintaan OAuth 2.0.
Cara memperbaiki SDK yang membocorkan kunci API GCP
SDK Anda berisi kunci API Google Cloud Platform (GCP) yang terekspos. Jika menyematkan kunci API GCP pada SDK Anda, kunci tersebut akan tersedia secara publik. Tereksposnya kunci API ini dapat mengakibatkan tagihan dan perubahan kuota yang tidak terduga pada akun GCP SDK Anda.
Jika menggunakan SDK Anda yang rentan, aplikasi akan menerima pemberitahuan di Konsol Play. Untuk mencegah aplikasi yang menggunakan SDK mendapatkan pemberitahuan, Anda harus memperbaiki kerentanan di SDK.
Tinjau langkah-langkah mendetail di bawah ini untuk memperbaiki masalah di SDK Anda. Anda dapat menemukan lokasi kunci API GCP yang terekspos di SDK dalam notifikasi SDK Console untuk SDK Anda.
Detail Tambahan
Sebaiknya perbaiki masalah ini di SDK Anda menggunakan salah satu cara berikut:
- Jika memungkinkan, gunakan akun layanan GCP sebagai pengganti kunci API GCP untuk mengautentikasi aplikasi Anda. Akun layanan GCP adalah Akun Google yang terkait dengan project GCP Anda. Detail selengkapnya tentang membuat dan menggunakan akun layanan dapat ditemukan di sini.
- Tambahkan batasan ke kunci API Anda sehingga hanya SDK/aplikasi Anda yang diizinkan menggunakan kunci API tersebut. Detail selengkapnya tentang menambahkan batasan ke kunci API dapat ditemukan di sini. (Harap Diperhatikan: Jika Anda telah menambahkan batasan pada kunci API, Anda dapat mengabaikan peringatan ini.)