Melihat versi SDK dengan potensi masalah kebijakan atau kerentanan

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) {
    Cipher cipher = Cipher.getInstance(“AES”);  // Menggunakan mode AES/ECB secara default
    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);
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)) {
    // SecurityException
  }
  // Selesai mengekstrak...
}