本頁說明內容專供使用 Google Play SDK Console 的 SDK 供應商參考。
如果您是要查看 Google Play 管理中心說明內容的應用程式開發人員，請使用搜尋列或返回首頁。
您可以運用 SDK 管理中心，掌握可能影響 SDK 版本的政策問題或安全漏洞。為了確保 Google Play 安全無虞，並避免 SDK 遭受負面影響，確實掌握這類問題非常重要。負面影響可能包括移除註冊標記，或限制存取 Google Play SDK 管理中心的功能。
可能存在政策問題的 SDK 版本
如果根據已知資訊，您的 SDK 版本會導致應用程式違反「SDK 規定」政策或其他《Google Play 開發人員計畫政策》，SDK 管理中心就會標出這些版本有此情形。若應用程式的新版本使用這些 SDK 版本，在 Google Play 發布時就會遭到拒絕；發生這種情況時，系統會指示開發人員先找出符合規定的版本，再重新提交應用程式。
下方螢幕截圖顯示「SDK 版本」專區示例，且特別標示違反政策事項：
下方螢幕截圖顯示展開的「SDK 版本」專區示例，詳細說明回報的問題：
根據《SDK 管理中心服務條款》，如果 SDK 有政策問題，系統會發送通知，說明修正問題的方式，以及如何將新版 SDK 送審。完成對現有應用程式的違規處置流程後，SDK 管理中心會將有問題的 SDK 版本標示為違反政策；若新應用程式版本採用這類 SDK 版本，必須改用符合規定的版本才能發布。
屢次違反 SDK 相關政策的可能後果
Google Play 致力於為開發人員和使用者打造安全可靠的生態系統。為履行這項承諾，我們會實施更嚴謹的做法，減少開發人員因 SDK 而屢次違反 Google Play 政策的情形：
視違規情節的嚴重程度和頻率而定，後續處置可能包括但不限於：
- 移除註冊標記：如果屢次違規和/或違規情節重大，Google Play SDK 索引就可能移除相應的註冊標記。註冊標記是用於標示 SDK 已在 Google Play SDK 管理中心註冊，其供應商也已接受《Google Play SDK 管理中心服務條款》，承諾自家 SDK 不會導致應用程式違反 Google Play 政策。
- 限制 Google Play SDK 管理中心功能存取權：如果 SDK 導致應用程式開發人員屢次違反政策，或 SDK 違規情節重大，我們有權撤銷相應帳戶存取 SDK 管理中心重要功能的權限。
注意：SDK 供應商仍能針對任何裁決提出申訴。如需更多資訊，請參閱這篇介紹如何安全使用 SDK 的說明中心文章，以及 Google Play 的《開發人員計畫政策》。
可能存在安全漏洞的 SDK 版本
安全漏洞是指程式碼中可能遭到惡意行為人濫用的弱點或缺陷。SDK 管理中心會通知您留意可能影響 SDK 版本的安全漏洞。以下說明這類安全漏洞，以及修正方式。
如何修正採用不安全加密模式的 SDK
您的 SDK 使用不安全的加密模式，也就是由靜態計算的密鑰、鹽或初始向量 (IV) 所產生的密文。
如果應用程式使用這個 SDK，會在 Play 管理中心收到快訊。如要避免這種狀況，就必須修正 SDK 中的安全漏洞。
請按照下列步驟解決 SDK 中的問題。您可以查看 SDK 管理中心的 SDK 通知，瞭解哪些位置的程式碼採用不安全的加密模式。
其他詳細資訊
請檢查 SDK 是否有用於加密作業的靜態計算金鑰、初始向量和/或鹽，並確保這些值的組成安全無虞。舉例來說，下列程式碼就是使用可靜態計算的密鑰和初始向量：
// 管理中心快訊是指這個方法
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);
}
// 以下是不安全的金鑰和初始向量，應做出變更
byte[] cipherText = encryptionUtil(“abcdef...”, “010203040506”, plainText);
靜態計算值
靜態計算值是指每次執行函式時均相同的值。惡意人士可能會從 SDK 擷取靜態計算值，用於攻擊應用程式的已加密資料。即使您在使用前先以複雜的方式處理金鑰、初始向量和鹽，但如果每次執行程式時的處理程序都相同，這些值仍然不安全。
Android 最佳做法
建議使用 Jetpack Security 執行對稱加密。如果您的 SDK 會加密 API 金鑰、個人識別資訊 (PII) 或其他私密資料，即可利用 EncryptedSharedPreferences 安全地儲存這些資料，不必擔心密鑰、初始向量和鹽的實作方式。如需更多最佳做法及示例，請參閱這個頁面。如要將資料安全地傳輸至其他系統，開發人員應使用 TLS/SSL，確保傳輸中的資料安全無虞。
Jetpack Security 利用 Google 開放原始碼專案 Tink 處理對稱驗證加密。如有關於較低層級作業的進階用途需求，建議直接使用 Tink。
如果上述 Android 最佳做法不符合您的用途，而且您必須明確管理金鑰、初始向量和鹽，則建議遵循下列標準：
- 密鑰：對稱密鑰必須保密且無法預測。如果是加密本機資料，開發人員應以安全性隨機加密方式 (如使用 PBEKeySpecs 則透過使用者產生的資料) 建立密鑰，並利用 AndroidKeystore 儲存這些密鑰。
- 初始向量：初始向量必須在多則訊息中不重複且無法預測，但毋須保密。開發人員應以安全性隨機加密的方式建立初始化向量，並將初始化向量與相關密文一併儲存或傳輸。
- 鹽：鹽必須是多個雜湊值中獨一無二且無法預測的，但毋須保密。開發人員應以安全性隨機加密的方式建立鹽，且一併儲存或傳輸鹽與相關雜湊。
如何修正採用低安全性加密模式的 SDK
您的 SDK 使用低安全性 AES/ECB 加密模式。採取這種較不安全的模式加密內容，可能會降低密文的安全性，並導致使用者資料暴露在風險中。
如果應用程式使用這個 SDK，會在 Play 管理中心收到快訊。如要避免這種狀況，就必須修正 SDK 中的安全漏洞。
請按照下列步驟解決 SDK 中的問題。您可以在 SDK 管理中心針對 SDK 發出的通知中，查看哪些位置的程式碼採用低安全性加密模式。
其他詳細資訊
請檢查 SDK，找出 Cipher 例項化的位置。如果發現下列設定模式，就表示使用不安全的 AES/ECB：
"AES"
"AES/ECB/NoPadding"
"AES/ECB/PKCS5Padding"
"AES/ECB/ISO10126Padding"
舉例來說，下列程式碼含有 "AES"，表示預設使用 AES/ECB 模式：
// 管理中心快訊是指這個方法
public byte[] encryptionUtil(String key, String iv, byte[] plainText) {// 預設使用 AES/ECB 模式
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 建議開發人員使用 “AES/GCM/NoPadding” 取代上述不安全的模式。
如果 SDK 含有容易遭受壓縮路徑遍歷攻擊的程式碼，該如何修正
SDK 中的程式碼使用不安全的解壓縮模式，可能因此遭到壓縮路徑遍歷攻擊。
如果應用程式使用這個 SDK，會在 Play 管理中心收到快訊。如要避免這種狀況，就必須修正 SDK 中的安全漏洞。
請按照下列詳細步驟解決 SDK 中的問題。您可以查看 SDK 管理中心的 SDK 通知，瞭解哪些位置的程式碼採用不安全的解壓縮模式。
其他詳細資訊
ZIP 檔案可以包含名稱中有路徑遍歷字元 (「../」) 的項目，例如檔案或目錄。如果開發人員解壓縮這類 ZIP 檔案項目時未驗證名稱，就可能遭受路徑遍歷攻擊，導致在任意目錄中寫入資料，甚至覆寫應用程式私人資料夾中的檔案。
如要修正這項 SDK 問題，建議檢查解壓縮檔案的標準路徑是否在預期的目錄底下。具體來說，如果是以 ZipEntry 的 getName() 方法傳回的值建立 File 物件，使用該物件前一律必須檢查 File.GetCanonicalPath() 傳回的值是否位於預期的目錄路徑。例如：
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)) {
}// 完成解壓縮...
}
如何修正具有隱含 PendingIntent 安全漏洞的 SDK
您的 SDK 具有隱含 PendingIntent 問題，可能導致安全威脅，惡意人士會藉此發動阻斷服務攻擊、竊取私人資料及提升權限。
如果應用程式使用這個 SDK，會在 Play 管理中心收到快訊。如要避免這種狀況，就必須修正 SDK 中的安全漏洞。
請按照下列詳細步驟解決 SDK 中的問題。您可以查看 SDK 管理中心的 SDK 通知，瞭解哪些位置的程式碼採用隱含 PendingIntent。
其他詳細資訊
Android 應用程式會利用意圖，在元件之間傳送訊息。意圖可以指定目標元件 (明確意圖)，或是列出一般動作，讓作業系統根據該動作，將意圖傳送至裝置上註冊相符意圖篩選器的所有元件 (隱含意圖)。
PendingIntent 是委派給其他應用程式的意圖，將於未來某個時間點提交。建立隱含意圖並納入 PendingIntent 會產生安全漏洞，惡意人士可能藉此發動阻斷服務攻擊、竊取私人資料及提升權限。
請檢查 SDK，找出建立 PendingIntent 的位置。舉例來說，以下程式碼會建立 PendingIntent 並將隱含意圖納入其中：
// 建立基本隱含意圖並納入 PendingIntent
Intent base = new Intent("ACTION_FOO");
base.setPackage("some_package");
PendingIntent pi = PendingIntent.getService(this, 0, base, 0);
Google 建議開發人員採用下列任何做法 (最好全部採用) 修正安全漏洞：
- 確認已設定基本意圖的動作、套件和元件欄位。
- 確保 PendingIntent 只傳遞給信任的元件。
- 使用 FLAG_IMMUTABLE (在 SDK 23 中加入) 建立 PendingIntent。這樣可以防止收到 PendingIntent 的應用程式填入尚未填寫的屬性。如果應用程式也會在搭載 SDK 22 以下版本的裝置上執行，我們建議開發人員除了採用上述做法外，也可以使用下列格式強化 PendingIntent 建立程序：
if (android.os.Build.VERSION.SDK_INT >= 23) {
// 使用 FLAG_IMMUTABLE 建立 PendingIntent
} else {
// 會建立 PendingIntent 的現有程式碼
}
如何修正具有內部隱含意圖安全漏洞的 SDK
您的 SDK 有內部隱含意圖問題。若應用程式利用隱含意圖與內部元件通訊，攻擊者可以從中攔截並捨棄訊息、讀取訊息內容，或甚至竄改訊息內容。
如果應用程式使用這個含有安全漏洞的 SDK，會在 Play 管理中心收到快訊。如要避免這種狀況，就必須修正 SDK 中的安全漏洞。
請按照下列詳細步驟解決 SDK 中的問題。您可以查看 SDK 管理中心的 SDK 通知，瞭解 SDK 中的哪些位置採用隱含意圖。
其他詳細資訊
請檢查 SDK，找出使用隱含意圖的位置。舉例來說，下列程式碼就是利用隱含意圖與內部元件通訊：
// 應用程式有註冊 MY_CUSTOM_ACTION 的元件
// 這項意圖僅由這個應用程式註冊，表示開發人員希望將該意圖
// 安全傳送至內部元件
Intent intent = new Intent("MY_CUSTOM_ACTION");
// 在「intent」中加入可能具有私密性的內容
intent.putExtra("message", sensitive_content);
startActivity(intent);
Google 建議開發人員使用顯式 Intent 與內部元件通訊，可行做法如下：
- 使用 Intent.setComponent 明確設定要處理意圖的元件。
- 使用 Intent.setClass 或 Intent.setClassName 明確設定目標元件。
- 使用 Intent.setPackage 限制這個 Intent 所解析至的元件。
如果 SDK 採用有安全漏洞的 JavaScript 程式庫，該如何修正
您 SDK 使用的一或多個 JavaScript 程式庫已知有安全問題，例如常見安全漏洞與弱點 (簡稱 CVE)。將這類有安全漏洞的程式庫加入 SDK，可能導致應用程式使用者暴露在風險中。
如果應用程式使用這個含有安全漏洞的 SDK，會在 Play 管理中心收到快訊。如要避免這種狀況，就必須修正 SDK 中的問題。
請按照下列詳細步驟解決 SDK 中的問題。您可以查看 SDK 管理中心的 SDK 通知，瞭解系統偵測到 SDK 中使用哪些不安全的程式庫和相關版本。
其他詳細資訊
如要解決這項問題，請分別針對系統偵測到的不安全程式庫，採取下列任一做法：
- 使用最新版程式庫：如果 SDK 直接依附於系統偵測到的不安全程式庫版本，而且這個程式庫的最新版本已解決安全問題，請使用最新版程式庫重新建構 SDK，即可解決問題。
- 與程式庫開發人員聯絡：程式庫可能仍有專人維護，只是尚未修正安全問題。此外，SDK 可能是間接依附於系統偵測到的不安全程式庫，也就是先直接依附到另一個程式庫，再依附至不安全的程式庫。如為這兩種情況，請通知程式庫開發人員修正問題。
- 尋找替代程式庫：如果程式庫包含一或多個安全問題，而且已沒有專人維護，請尋找並使用安全的替代程式庫。
如何修正採用 WebView 執行驗證的 SDK
您的 SDK 使用 WebView 執行驗證，但我們不建議這麼做。以 WebView 處理 OAuth 2.0 要求，會對採用該 SDK 的應用程式產生負面影響，降低安全性和可用性。請按照下列步驟解決 SDK 中的問題。
如果應用程式使用這個 SDK，會在 Play 管理中心收到快訊。如要避免這種狀況，就必須修正 SDK 中的安全漏洞。
您可以查看 SDK 管理中心的 SDK 通知，瞭解 SDK 中哪些位置的程式碼透過 WebView 處理 OAuth 2.0 要求。
其他詳細資訊
自 Chrome 自訂分頁推出以來，Google 就建議開發人員不要再使用 WebViews 執行驗證。如果在 WebView 中運用 OAuth 執行驗證，可能造成使用者的單一登入工作階段中斷連線，導致採用您 SDK 的應用程式容易發生安全問題，並損害可用性。Chrome 自訂分頁可以緩解這類問題。
- 檢查 SDK，找出透過 WebView 處理 OAuth 2.0 要求的位置。
- Google 建議開發人員使用 Chrome 自訂分頁取代 WebView。請按照 Chrome 自訂分頁實作指南中的步驟，將 Chrome 自訂分頁加入 SDK。
- 使用新增的 Chrome 自訂分頁執行 OAuth 2.0 要求。
如何修正洩漏 GCP API 金鑰的 SDK
您的 SDK 使用的 Google Cloud Platform (GCP) API 金鑰外洩。已嵌入 SDK 的 GCP API 金鑰將公開顯示。API 金鑰曝光可能導致 SDK 的 GCP 帳戶產生非預期費用及變更配額。
如果應用程式使用這個含有安全漏洞的 SDK，會在 Play 管理中心收到快訊。如要避免這種狀況，就必須修正 SDK 中的安全漏洞。
請按照下列詳細步驟解決 SDK 中的問題。您可以查看 SDK 管理中心的 SDK 通知，瞭解 SDK 中哪些位置的 GCP API 金鑰已曝光。
其他詳細資訊
如要修正這項 SDK 問題，建議採取下列任一做法：
- 盡可能避免使用 GCP API 金鑰驗證應用程式，而是改用 GCP 服務帳戶，也就是與 GCP 專案相關聯的 Google 帳戶。如要進一步瞭解如何建立及使用服務帳戶，請參閱這篇文章。
- 為 API 金鑰增設限制，僅允許自家 SDK/應用程式使用該金鑰。如要進一步瞭解如何增設 API 金鑰限制，請參閱這篇文章。請注意，如果已完成這項操作，即可忽略這則警告。