Diese Seite enthält Hilfeinhalte für SDK-Anbieter, die die Google Play SDK Console verwenden.
Wenn Sie als App-Entwickler nach Hilfeinhalten zur Google Play Console suchen, verwenden Sie bitte die Suchleiste oder kehren Sie zur Startseite zurück.
Mithilfe der SDK Console können Sie potenzielle Richtlinienprobleme oder Sicherheitslücken im Zusammenhang mit Ihren SDK-Versionen im Blick behalten. Es ist wichtig, über diese Art von Problemen auf dem Laufenden zu bleiben, um Google Play zu schützen und potenzielle negative Folgen für Ihre SDKs zu vermeiden. Dazu kann das Entfernen des Registrierungslogos oder der eingeschränkte Zugriff auf Funktionen in der Google Play SDK Console gehören.
SDK-Versionen mit potenziellen Richtlinienproblemen
Wenn Sie SDK-Versionen haben, die bekanntermaßen dazu führen, dass Apps, die sie verwenden, gegen unsere Richtlinie zu Anforderungen an SDKs oder andere Google Play-Programmrichtlinien für Entwickler verstoßen, werden diese Versionen in der SDK Console gekennzeichnet. Neue App-Versionen, die mit diesen Versionen bei Google Play veröffentlicht werden, werden abgelehnt. Entwickler werden dann aufgefordert, eine richtlinienkonforme Version zu finden, bevor sie ihre App noch einmal einreichen.
Im folgenden Screenshot sehen Sie ein Beispiel für eine SDK‑Version mit einem hervorgehobenen Richtlinienverstoß:
Im folgenden Screenshot sehen Sie ein Beispiel für die maximierte SDK‑Version mit Details zum gemeldeten Problem:
Gemäß den Nutzungsbedingungen für die SDK Console werden Sie, falls bei Ihrem SDK ein Richtlinienproblem festgestellt wird, benachrichtigt. Außerdem erhalten Sie eine Anleitung dazu, wie Sie das Problem beheben und eine neue SDK-Version zur Überprüfung einreichen können. Sobald der Durchsetzungsprozess für bestehende Apps abgeschlossen ist, werden die problematischen SDK-Versionen in der SDK Console als nicht richtlinienkonform gekennzeichnet. Neue App-Versionen, die diese SDK-Versionen enthalten, können erst wieder veröffentlicht werden, wenn sie auf eine richtlinienkonforme Version umgestellt wurden.
Potenzielle Folgen wiederholter SDK‑bezogener Richtlinienverstöße
Google Play ist bestrebt, sowohl Entwicklern als auch Nutzern eine sichere und vertrauenswürdige Umgebung zu bieten. Im Rahmen dieser Verpflichtung werden verbesserte Prozesse eingeführt, um wiederholte Verstöße gegen die Google Play-Richtlinien durch SDKs einzudämmen:
Je nach Schwere und Häufigkeit der Verstöße können zu den Folgen unter anderem diese gehören:
- Entfernen des Registrierungslogos: Wiederholte Verstöße und/oder der Schweregrad des Verstoßes können zum Entfernen des Registrierungslogos im Google Play SDK Index führen. Das Logo gibt an, dass das SDK in der Google Play SDK Console registriert ist und der Anbieter dieses SDKs die Nutzungsbedingungen der Google Play SDK Console akzeptiert hat. Dazu gehört auch die Verpflichtung, dass seine SDKs nicht zum Verstoß von Apps gegen die Google Play-Richtlinien führen.
- Eingeschränkter Zugriff auf Funktionen in der Google Play SDK Console: Wenn SDKs wiederholt zu Richtlinienverstößen durch App-Entwickler führen oder im Falle eines schwerwiegenden Verstoßes durch das SDK, behalten wir uns das Recht vor, den Zugriff auf wichtige Funktionen in der SDK Console zu entfernen.
Hinweis: SDK-Anbieter können sich weiterhin über alle Entscheidungen informieren. Weitere Informationen finden Sie in diesem Hilfeartikel zur sicheren Verwendung von SDKs und in den Google Play-Programmrichtlinien für Entwickler.
SDK-Versionen mit potenziellen Sicherheitslücken
Eine Sicherheitslücke ist eine Schwachstelle im Code, die von einem böswilligen Akteur ausgenutzt werden könnte. Die SDK Console informiert Sie über potenzielle Sicherheitslücken in Ihren SDK-Versionen. Unten finden Sie Informationen zu Sicherheitslücken, die Ihr SDK betreffen könnten, und wie Sie sie beheben können.
Probleme bei SDKs mit unsicheren Verschlüsselungsmustern beheben
Ihr SDK enthält unsichere Verschlüsselungsmuster. Das bedeutet, dass ein Geheimtext mit einem statisch berechneten Geheimschlüssel, Salt oder Initialisierungsvektor (IV) generiert wird.
Wenn eine App Ihr SDK verwendet, erhält sie eine Benachrichtigung in der Play Console. Damit Apps, die Ihr SDK verwenden, keine Benachrichtigungen erhalten, müssen Sie die Sicherheitslücke in Ihrem SDK beheben.
Sehen Sie sich die folgenden Schritte an, um das Problem in Ihrem SDK zu beheben. Wo sich der unsichere Verschlüsselungscode befindet, können Sie der SDK Console-Benachrichtigung für Ihr SDK entnehmen.
Weitere Details
Überprüfen Sie Ihr SDK auf statisch berechnete Schlüssel, Initialisierungsvektoren und/oder Salts, die bei Verschlüsselungsvorgängen verwendet werden. Sorgen Sie dafür, dass diese Werte auf sichere Weise berechnet werden. Im folgenden Code werden beispielsweise ein statisch berechneter Geheimschlüssel und ein statisch berechneter Initialisierungsvektor verwendet:
// Die Console-Benachrichtigung bezieht sich auf folgende Methode
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);
}
// Der unsichere Schlüssel und Initialisierungsvektor befinden sich hier und müssen geändert werden
byte[] cipherText = encryptionUtil(“abcdef...”, “010203040506”, plainText);
Statisch berechnete Werte
Ein statisch berechneter Wert ist ein Wert, der bei jeder Ausführung einer Funktion gleich ist. Statisch berechnete Werte können aus Ihrem SDK extrahiert und verwendet werden, um die verschlüsselten Daten einer App anzugreifen. Selbst wenn Schlüssel, Initialisierungsvektoren und Salts vor der Verwendung komplex manipuliert werden, bleiben sie unsicher, wenn diese Manipulationen bei jeder Programmausführung gleich sind.
Best Practices für Android
Wir empfehlen für symmetrische Kryptografie die Verwendung von Jetpack Security. Wenn Ihr SDK API-Schlüssel, personenidentifizierbare Informationen oder andere sensible Daten verschlüsselt, können Sie EncryptedSharedPreferences verwenden, um diese Daten sicher zu speichern. Sie müssen sich dann nicht um die Implementierung von Geheimschlüsseln, Initialisierungsvektoren und Salts kümmern. Weitere Best Practices und Beispiele finden Sie auf dieser Seite. Zur sicheren Übertragung von Daten an andere Systeme sollten Entwickler TLS/SSL nutzen.
Jetpack Security nutzt das Open-Source-Projekt Tink von Google, um eine symmetrische, authentifizierte Verschlüsselung zu ermöglichen. Für besondere Anwendungsfälle mit untergeordneten Vorgängen empfehlen wir, Tink direkt zu verwenden.
Wenn die oben genannten Best Practices von Android bei Ihrem Anwendungsfall nicht möglich sind und Sie Schlüssel, Initialisierungsvektoren und Salts explizit verwalten müssen, empfehlen wir folgende Standards:
- Geheimschlüssel: Symmetrische Geheimschlüssel müssen unberechenbar und geheim sein. Zum Verschlüsseln lokaler Daten sollten Entwickler Geheimschlüssel mithilfe von kryptografisch sicherer Zufälligkeit berechnen (oder aus nutzergenerierten Daten, wenn PBEKeySpecs verwendet wird) und die Geheimschlüssel mit AndroidKeystore speichern.
- Initialisierungsvektoren: Initialisierungsvektoren müssen für mehrere Nachrichten eindeutig und unvorhersehbar, aber nicht geheim sein. Entwickler sollten Initialisierungsvektoren mithilfe von kryptografisch sicherer Zufälligkeit berechnen. Die Initialisierungsvektoren sollten zusammen mit dem zugehörigen Geheimtext gespeichert oder übertragen werden.
- Salts: Salts müssen für mehrere Hashes eindeutig und unvorhersehbar sein, aber nicht geheim sein. Entwickler sollten Salts mithilfe von kryptografisch sicherer Zufälligkeit berechnen. Salts sollten zusammen mit den zugehörigen Hashes gespeichert oder übertragen werden.
Probleme mit SDKs beheben, die weniger sichere Verschlüsselungsmodi verwenden
Ihr SDK enthält eine Verschlüsselung mit dem weniger sicheren AES/ECB-Modus. Das Verschlüsseln von Inhalten mit diesem Modus kann zu weniger sicheren Geheimtexten führen und die Vertraulichkeit von Nutzerdaten gefährden.
Wenn eine App Ihr SDK verwendet, erhält sie eine Benachrichtigung in der Play Console. Damit Apps, die Ihr SDK verwenden, keine Benachrichtigungen erhalten, müssen Sie die Sicherheitslücke in Ihrem SDK beheben.
Sehen Sie sich die folgenden Schritte an, um das Problem in Ihrem SDK zu beheben. Wo sich die Codes der weniger sicheren Verschlüsselungsmodi befinden, können Sie der SDK Console-Benachrichtigung für Ihr SDK entnehmen.
Weitere Details
Überprüfen Sie, an welcher Stelle in Ihrem SDK ein Cipher instanziiert wird. Die folgenden Konfigurationsmodi deuten auf die Verwendung von unsicherem AES/ECB hin:
„AES“
„AES/ECB/NoPadding“
„AES/ECB/PKCS5Padding“
„AES/ECB/ISO10126Padding“
Im folgenden Code wird standardmäßig der AES/ECB-Modus verwendet, weil „AES“ angegeben wurde:
// Die Console-Benachrichtigung bezieht sich auf folgende Methode
public byte[] encryptionUtil(String key, String iv, byte[] plainText) {// Nutzt standardmäßig den AES-/ECB-Modus
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 empfiehlt Entwicklern, AES/GCM/NoPadding anstelle des zuvor erwähnten unsicheren Modus zu verwenden.
Probleme bei SDKs mit Code beheben, der für die „Zip Path Traversal“-Sicherheitslücke anfällig ist
Der Code in Ihrem SDK enthält unsichere Entpackungsmuster, die zu einem „Zip Path Traversal“-Angriff führen können.
Wenn eine App Ihr SDK verwendet, erhält sie eine Benachrichtigung in der Play Console. Damit Apps, die Ihr SDK verwenden, keine Benachrichtigungen erhalten, müssen Sie die Sicherheitslücke in Ihrem SDK beheben.
Sehen Sie sich die folgenden Schritte an, um das Problem in Ihrem SDK zu beheben. Wo sich der unsichere Entpackungsmustercode befindet, können Sie der SDK Console-Benachrichtigung für Ihr SDK entnehmen.
Weitere Details
ZIP-Dateien können einen Eintrag (Datei oder Verzeichnis) mit „Path Traversal“-Zeichen („../“) im Namen enthalten. Wenn Entwickler solche ZIP-Dateieinträge entpacken, ohne deren Namen zu validieren, verursacht dies möglicherweise einen „Path Traversal“-Angriff. Solche Angriffe können dann zu Schreibvorgängen in beliebigen Verzeichnissen oder sogar zum Überschreiben von Dateien in den privaten Ordnern einer App führen.
Wir empfehlen Ihnen, dieses Problem in Ihrem SDK so zu beheben: Prüfen Sie, ob kanonische Pfade zu entpackten Dateien unter einem erwarteten Verzeichnis liegen. Bevor Sie ein File-Objekt verwenden, das mit dem Rückgabewert der Methode getName() von ZipEntry erstellt wurde, prüfen Sie immer, ob der Rückgabewert von File.GetcanonicalPath() zum gewünschten Verzeichnispfad gehört. Hier einige Beispiele:
InputStream is = new InputStream(untrustedFileName);// Sicherheitsausnahme
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)) {
}// Entpacken beenden…
}
Probleme mit SDKs beheben, die eine Sicherheitslücke des Typs „Implicit PendingIntent“ enthalten
Ihr SDK enthält ein Problem des Typs „Implicit PendingIntent“, das Sicherheitsbedrohungen in Form von Denial of Service, Diebstahl privater Daten und Rechteausweitung verursachen kann.
Wenn eine App Ihr SDK verwendet, erhält sie eine Benachrichtigung in der Play Console. Damit Apps, die Ihr SDK verwenden, keine Benachrichtigungen erhalten, müssen Sie die Sicherheitslücke in Ihrem SDK beheben.
Unten finden Sie detaillierte Schritte, um das Problem in Ihrem SDK zu beheben. Die Stellen mit „Implicit PendingIntent“-Code finden Sie in der SDK Console-Benachrichtigung für Ihr SDK.
Weitere Details
Android-Apps senden Nachrichten zwischen Komponenten mithilfe von Intents. Intents können entweder die Zielkomponente (expliziter Intent) angeben oder eine allgemeine Aktion auflisten und es dem Betriebssystem überlassen, den Intent an Komponenten auf dem Gerät zu senden, die einen mit dieser Aktion übereinstimmenden Intent-Filter registrieren (impliziter Intent).
PendingIntents sind Intents, die an eine andere App delegiert wurden und später gesendet werden sollen. Das Erstellen eines impliziten Intents, der von einem PendingIntent umschlossen wird, ist eine Sicherheitslücke, die Denial-of-Service-Angriffe, den Diebstahl privater Daten und Angriffe durch Rechteausweitung begünstigen kann.
Prüfen Sie, wo in Ihrem SDK ein PendingIntent erstellt wird. Durch den folgenden Code wird beispielsweise ein PendingIntent erstellt, der einen impliziten Intent umschließt:
// Impliziten Basis-Intent erstellen und mit einem PendingIntent umschließen
Intent base = new Intent("ACTION_FOO");
base.setPackage("some_package");
PendingIntent pi = PendingIntent.getService(this, 0, base, 0);
Google empfiehlt Entwicklern, die Sicherheitslücke zu beseitigen, indem Sie möglichst viele der folgenden Maßnahmen umsetzen:
- Darauf achten, dass die Basis-Intent-Felder für Aktion, Paket und Komponente festgelegt sind.
- Dafür sorgen, dass der PendingIntent nur an vertrauenswürdige Komponenten gesendet wird.
- PendingIntents mithilfe von FLAG_IMMUTABLE (in SDK 23 hinzugefügt) erstellen. Dadurch wird verhindert, dass Apps, die den PendingIntent empfangen, nicht festgelegte Attribute selbst festlegen. Falls die App auch auf Geräten mit SDK 22 oder älteren Versionen ausgeführt wird, sollten Entwickler zusätzlich die Erstellung von PendingIntents mit dem folgenden Muster sicherer machen:
if (android.os.Build.VERSION.SDK_INT >= 23) {
// PendingIntent mithilfe von FLAG_IMMUTABLE erstellen
} else {
// Vorhandener Code, durch den ein PendingIntent erstellt wird
}
Probleme mit SDKs beheben, die eine Sicherheitslücke in Form eines impliziten internen Intents enthalten
Ihr SDK enthält ein Problem in Verbindung mit einem impliziten internen Intent. Implizite Intents, die dafür verwendet werden, eine interne Komponente zu erreichen, können Angreifern ermöglichen, die Nachricht abzufangen und sie entweder zu löschen, ihren Inhalt zu lesen oder ihn sogar zu ersetzen.
Wenn eine App Ihr anfälliges SDK verwendet, erhält sie eine Benachrichtigung in der Play Console. Damit Apps, die Ihr SDK verwenden, keine Benachrichtigungen erhalten, müssen Sie die Sicherheitslücke in Ihrem SDK beheben.
Sehen Sie sich die folgenden Schritte an, um das Problem in Ihrem SDK zu beheben. Die Stelle bzw. die Stellen der Verwendungen impliziter Intents in Ihrem SDK finden Sie in der SDK Console-Benachrichtigung für Ihr SDK.
Weitere Details
Prüfen Sie, wo in Ihrer SDK ein impliziter Intent verwendet wird. Im folgenden Code werden beispielsweise implizite Intents dafür genutzt, eine interne Komponente zu erreichen:
//Die App hat eine Komponente, die MY_CUSTOM_ACTION registriert,
//das nur von dieser App registriert wird, was darauf hindeutet, dass der Entwickler möchte,
//dass dieser Intent sicher an die interne Komponente gesendet wird.
Intent intent = new Intent("MY_CUSTOM_ACTION");
//Potenziell vertraulichen Inhalt zu „intent“ hinzufügen
intent.putExtra("message", sensitive_content);
startActivity(intent);
Google empfiehlt Entwicklern, explizite Intents zu verwenden, um ihre internen Komponenten zu erreichen. Dazu sollten sie so vorgehen:
- Intent.setComponent verwenden, um die Komponente explizit für die Verarbeitung des Intents einzurichten
- Intent.setClass oder Intent.setClassName verwenden, um explizit die Zielkomponente festzulegen
- Intent.setPackage verwenden, um die Komponenten einzuschränken, denen dieser Intent zugeordnet wird
Probleme mit SDKs beheben, die anfällige JavaScript-Bibliotheken enthalten
Ihr SDK enthält eine oder mehrere JavaScript-Bibliotheken mit bekannten Sicherheitsproblemen, z. B. häufigen Sicherheitslücken und Schwachstellen. Wenn Sie solche anfälligen Bibliotheken in Ihr SDK aufnehmen, können App-Nutzer gefährdet werden.
Wenn eine App Ihr anfälliges SDK verwendet, erhält sie eine Benachrichtigung in der Play Console. Damit Apps, die Ihr SDK verwenden, keine Benachrichtigungen erhalten, müssen Sie das Problem in Ihrem SDK beheben.
Sehen Sie sich die folgenden Schritte an, um das Problem in Ihrem SDK zu beheben. Eine Liste der erkannten unsicheren Bibliotheken und ihrer in Ihrem SDK verwendeten Versionen finden Sie in der SDK Console-Benachrichtigung für Ihr SDK.
Weitere Details
Sie können für jede erkannte unsichere Bibliothek eine der folgenden drei Maßnahmen ergreifen, um das Problem zu beheben:
- Verwenden Sie eine aktuelle Version der Bibliothek: Wenn für Ihr SDK eine direkte Abhängigkeit zur unsicheren Bibliothek besteht, das Sicherheitsproblem in der neuesten Version jedoch behoben wurde, muss das SDK mit der neuesten Version der Bibliothek neu erstellt werden.
- Kontaktieren Sie den Entwickler der Bibliothek: Möglicherweise wird die Bibliothek weiterhin aktualisiert, das Sicherheitsproblem wurde jedoch noch nicht behoben. Es ist auch möglich, dass für Ihr SDK eine transitive Abhängigkeit von der unsicheren Bibliothek besteht (d. h. das SDK ist von einer Bibliothek abhängig, die wiederum von der unsicheren Bibliothek abhängig ist). Wenden Sie sich in solchen Fällen an den Entwickler der Bibliothek, um das Problem zu beheben.
- Suchen Sie nach einer Alternative: Wenn die unsichere Bibliothek mit mindestens einem Sicherheitsproblem nicht länger aktualisiert wird, suchen Sie nach einer sicheren Alternative und nutzen Sie diese.
Probleme mit SDKs beheben, die WebViews zur Authentifizierung verwenden
Ihr SDK verwendet WebView zur Authentifizierung. Dies wird nicht empfohlen. Die Verwendung von WebViews für OAuth 2.0-Anfragen wirkt sich negativ auf die Sicherheit und Nutzerfreundlichkeit von Apps aus, für die Ihr SDK verwendet wird. Sehen Sie sich die folgenden Schritte an, um das Problem in Ihrem SDK zu beheben.
Wenn eine App Ihr SDK verwendet, erhält sie eine Benachrichtigung in der Play Console. Damit Apps, die Ihr SDK verwenden, keine Benachrichtigungen erhalten, müssen Sie die Sicherheitslücke in Ihrem SDK beheben.
Die Stellen für Code von OAuth 2.0-Anfragen über WebViews finden Sie in der SDK Console-Benachrichtigung für Ihr SDK.
Weitere Details
Seit der Einführung von benutzerdefinierten Tabs in Chrome hat Google Entwicklern empfohlen, WebViews nicht mehr zur Authentifizierung zu verwenden. Die Verwendung von OAuth zur Authentifizierung in einer WebView kann Apps, die Ihr SDK verwenden, anfällig für Sicherheitsprobleme machen und die Nutzerfreundlichkeit beeinträchtigen, da der Nutzer dadurch von SSO-Sitzungen getrennt wird. Mit benutzerdefinierten Tabs in Chrome können diese Probleme vermieden werden.
- Prüfen Sie, wo in Ihrem SDK eine OAuth 2.0-Anfrage über WebView ausgeführt wird.
- Google empfiehlt Entwicklern, diese WebView durch einen benutzerdefinierten Tab in Chrome zu ersetzen. Führen Sie dazu die Schritte im Leitfaden zur Implementierung von benutzerdefinierten Tabs in Chrome aus, um Ihrem SDK einen benutzerdefinierten Chrome-Tab hinzuzufügen.
- Verwenden Sie nun den hinzugefügten benutzerdefinierten Tab in Chrome, um die OAuth 2.0-Anfrage auszuführen.
Probleme mit SDKs beheben, die GCP-API-Schlüssel offenlegen
Ihr SDK enthält offengelegte API-Schlüssel für die Google Cloud Platform (GCP). Wenn Sie GCP-API-Schlüssel in Ihr SDK einbetten, sind diese Schlüssel öffentlich verfügbar. Diese Offenlegung Ihrer API-Schlüssel kann zu unerwarteten Kosten und Quotenänderungen im GCP-Konto Ihres SDK führen.
Wenn eine App Ihr anfälliges SDK verwendet, erhält sie eine Benachrichtigung in der Play Console. Damit Apps, die Ihr SDK verwenden, keine Benachrichtigungen erhalten, müssen Sie die Sicherheitslücke in Ihrem SDK beheben.
Sehen Sie sich die folgenden Schritte an, um das Problem in Ihrem SDK zu beheben. Die Stellen der offengelegten GCP-API-Schlüssel in Ihrem SDK finden Sie in der SDK Console-Benachrichtigung für Ihr SDK.
Zusätzliche Informationen
Wir empfehlen, das Problem in Ihrem SDK auf eine der folgenden Arten zu beheben:
- Verwenden Sie nach Möglichkeit GCP-Dienstkonten anstelle von GCP-API-Schlüsseln zur Authentifizierung Ihrer App. Ein GCP-Dienstkonto ist ein Google-Konto, das mit Ihrem GCP-Projekt verknüpft ist. Weitere Informationen dazu, wie Sie Dienstkonten erstellen und verwenden, finden Sie hier.
- Fügen Sie Ihrem API-Schlüssel Einschränkungen hinzu, sodass nur Ihre SDKs/Apps den API-Schlüssel verwenden dürfen. Weitere Informationen dazu, wie Sie Einschränkungen für API-Schlüssel hinzufügen, finden Sie hier. (Hinweis: Wenn Sie Ihrem API-Schlüssel bereits Einschränkungen hinzugefügt haben, können Sie diese Warnung ignorieren.)