Best Practices zur App-Sicherheit

Dieser Abschnitt enthält Empfehlungen zur Gewährleistung der Sicherheit von Apps auf Android-Geräten.

Quellcodeüberprüfung

Bei der Überprüfung des Quellcodes kann eine Vielzahl von Sicherheitsproblemen erkannt werden, einschließlich der in diesem Dokument beschriebenen. Android empfiehlt dringend sowohl manuelle als auch automatisierte Quellcodeüberprüfungen.

  • Halten Sie sich bei der Durchführung von Prüfungen an umfassende Sicherheitsrichtlinien, um eine vollständige Abdeckung zu gewährleisten. Verwenden Sie relevante interne oder externe Standards, um konsistente und vollständige Überprüfungen zu gewährleisten.
  • Führen Sie einen Linter wie den Android Studio-Linter für den gesamten App-Code aus, der das Android SDK verwendet, und beheben Sie alle erkannten Probleme.
  • Analysieren Sie nativen Code mit einem automatisierten Tool, das Probleme bei der Speicherverwaltung wie Pufferüberläufe und Off-by-One-Fehler erkennen kann.
  • Das Android-Build-System unterstützt viele der LLVM-Sanitizer, z. B. AddressSanitizer und UndefinedBehaviorSanitizer, die für die Laufzeitanalyse speicherbezogener Probleme verwendet werden können. In Kombination mit Fuzzing, das in Android über libFuzzer unterstützt wird, können Sanitizer ungewöhnliche Grenzfälle aufdecken, die weitere Untersuchungen erfordern.
  • Ein sachkundiger Sicherheitsprüfer sollte Code mit höherem Risiko überprüfen, z. B. Code für die Verarbeitung von Kryptografie, Zahlungen und personenidentifizierbaren Informationen.

Automatisierte Tests

Automatisierte Tests können helfen, eine Vielzahl von Sicherheitsproblemen zu erkennen, und sollten regelmäßig durchgeführt werden.

  • Führen Sie die aktuelle Version von CTS regelmäßig während des gesamten Entwicklungsprozesses aus, um Probleme frühzeitig zu erkennen und die Korrekturzeit zu verkürzen. Android verwendet CTS im Rahmen der Continuous Integration in unserem automatisierten Build-Prozess, der mehrmals täglich ausgeführt wird.
  • Automatisieren Sie Sicherheitstests von Schnittstellen, einschließlich Tests mit fehlerhaften Eingaben (Fuzzing). Das Build-System von Android unterstützt libFuzzer zum Schreiben von Fuzz-Tests.

Scannen auf Sicherheitslücken

Durch das Scannen auf Sicherheitslücken kann sichergestellt werden, dass vorinstallierte Apps keine bekannten Sicherheitslücken aufweisen. Durch die erweiterte Erkennung können der Zeitaufwand und die Kosten für die Behebung dieser Sicherheitslücken und die Vermeidung von Risiken für Nutzer und Geräte reduziert werden.

  • Scannen Sie alle vorinstallierten Apps mit einem branchenweit anerkannten Tool zum Scannen von App-Sicherheitslücken und beheben Sie erkannte Sicherheitslücken.

Potenziell schädliche Apps

Es ist wichtig, dass die vorinstallierten Apps auf Ihrem Gerät keine potenziell schädlichen Anwendungen (Potentially Harmful Applications, PHAs) sind. Sie sind für das Verhalten aller Apps verantwortlich, die auf Ihren Geräten enthalten sind. Scannen Sie vor der Markteinführung des Geräts alle vorinstallierten Apps auf Sicherheitslücken.

Weitere Informationen zu potenziell schädlichen Apps und dazu, wie Google sie im Play Store bekämpft, finden Sie in der Google Play Protect-Entwicklerdokumentation.

App-Installation und ‑Berechtigungen

Übermäßige Berechtigungen für vorinstallierte Apps können ein Sicherheitsrisiko darstellen. Beschränken Sie vorinstallierte Apps auf die erforderlichen Mindestberechtigungen und sorgen Sie dafür, dass sie keinen Zugriff auf unnötige Berechtigungen oder Rechte haben. App-Berechtigungen werden in der Datei AndroidManifest.xml beschrieben.

  • Vorinstallierten Apps keine unnötigen Berechtigungen oder Rechte gewähren Prüfen Sie Apps mit Systemberechtigungen sorgfältig, da sie sehr vertrauliche Berechtigungen haben können.
  • Achten Sie darauf, dass alle angeforderten Berechtigungen für die Funktionalität der jeweiligen App relevant und erforderlich sind.
  • Sorgen Sie dafür, dass Nutzer über alle vorinstallierten Apps informiert werden, die die Berechtigung INSTALL_PACKAGES verwenden.
  • Der Entwickler muss vertraglich verpflichtet sein, keine Apps als UID 0 zu installieren.
  • Bewerten Sie die im Manifest aller Apps deklarierten Berechtigungen, die über das Netzwerk des Entwicklers installiert werden sollen.
  • Der Entwickler muss vertraglich verpflichtet sein, alle Download-URLs von Auto-Updater- und Installations-Apps mit der Google Safe Browsing API zu scannen, bevor Apps auf dem Gerät bereitgestellt werden.

App-Signatur

App-Signaturen spielen eine wichtige Rolle für die Gerätesicherheit und werden für Berechtigungsprüfungen und Softwareupdates verwendet. Bei der Auswahl eines Schlüssels zum Signieren von Apps ist es wichtig, zu berücksichtigen, ob eine App nur auf einem einzelnen Gerät oder auf mehreren Geräten verfügbar ist.

  • Achten Sie darauf, dass Apps nicht mit einem öffentlich bekannten Schlüssel signiert werden, z. B. dem AOSP-Entwicklerschlüssel.
  • Sorgen Sie dafür, dass Schlüssel, die zum Signieren von Apps verwendet werden, in einer Weise verwaltet werden, die den branchenüblichen Verfahren für den Umgang mit vertraulichen Schlüsseln entspricht. Dazu gehört auch ein Hardware Security Module (HSM), das eingeschränkten, prüfbaren Zugriff bietet.
  • Achten Sie darauf, dass Apps nicht mit dem Plattformschlüssel signiert werden. Dadurch erhält eine App Zugriff auf Berechtigungen mit Plattformsignatur, die sehr leistungsstark sind und nur von Komponenten des Betriebssystems verwendet werden sollen. System-Apps sollten privilegierte Berechtigungen verwenden.
  • Achten Sie darauf, dass Apps mit demselben Paketnamen nicht mit unterschiedlichen Schlüsseln signiert werden. Das passiert häufig, wenn Sie eine App für verschiedene Geräte erstellen, insbesondere wenn Sie den Plattformschlüssel verwenden. Wenn die App geräteunabhängig ist, verwenden Sie denselben Schlüssel auf allen Geräten. Wenn die App gerätespezifisch ist, erstellen Sie eindeutige Paketnamen pro Gerät und Schlüssel.

Apps und Prozesse isolieren

Das Android-Sandboxing-Modell bietet zusätzliche Sicherheit für Apps und Prozesse, wenn es richtig verwendet wird.

Root-Prozesse isolieren

Root-Prozesse sind das häufigste Ziel von Angriffen zur Rechteausweitung. Wenn Sie die Anzahl der Root-Prozesse reduzieren, verringern Sie das Risiko einer Rechteausweitung.

  • Achten Sie darauf, dass auf Geräten nur der unbedingt erforderliche Code als Root ausgeführt wird. Verwenden Sie nach Möglichkeit einen regulären Android-Prozess anstelle eines Root-Prozesses. Wenn ein Prozess auf einem Gerät als Root ausgeführt werden muss, dokumentieren Sie den Prozess in einer AOSP-Funktionsanfrage, damit er öffentlich überprüft werden kann.
  • Wenn möglich, sollte der Root-Code von nicht vertrauenswürdigen Daten isoliert und über die Interprozesskommunikation (IPC) aufgerufen werden. Sie können beispielsweise die Root-Funktionalität auf einen kleinen Dienst beschränken, auf den über Binder zugegriffen werden kann, und den Dienst mit einer Signaturberechtigung für eine App mit geringen oder keinen Berechtigungen zum Verarbeiten von Netzwerk-Traffic bereitstellen.
  • Root-Prozesse dürfen nicht auf einem Netzwerk-Socket lauschen.
  • Root-Prozesse dürfen keine Allzweck-Laufzeitumgebung wie eine Java-VM enthalten.

System-Apps isolieren

Im Allgemeinen sollten vorinstallierte Apps nicht mit der gemeinsamen eindeutigen System-ID (UID) ausgeführt werden. Wenn eine App die gemeinsame UID des Systems oder eines anderen privilegierten Dienstes (z.B. Telefon) verwenden muss, darf sie keine Dienste, Broadcast-Empfänger oder Contentanbieter exportieren, auf die von Drittanbieter-Apps zugegriffen werden kann, die von Nutzern installiert wurden.

  • Achten Sie darauf, dass auf Geräten der als System erforderliche Mindestcode ausgeführt wird. Verwenden Sie nach Möglichkeit einen Android-Prozess mit einer eigenen UID, anstatt die System-UID wiederzuverwenden.
  • Systemcode sollte nach Möglichkeit von nicht vertrauenswürdigen Daten isoliert werden und IPC nur für andere vertrauenswürdige Prozesse verfügbar machen.
  • Systemprozesse dürfen nicht auf einem Netzwerk-Socket lauschen. Dies ist eine CTS-Anforderung.

Prozesse isolieren

Die Android-App-Sandbox bietet Apps die Möglichkeit, sich von anderen Prozessen im System zu isolieren, einschließlich Root-Prozessen und Debuggern. Sofern das Debugging nicht ausdrücklich von der App und dem Nutzer aktiviert wurde, sollte keine App gegen diese Erwartung verstoßen.

  • Achten Sie darauf, dass Root-Prozesse nicht auf Daten in den einzelnen App-Datenordnern zugreifen, es sei denn, es wird eine dokumentierte Android-Debugging-Methode verwendet.
  • Achten Sie darauf, dass Root-Prozesse nicht auf den Arbeitsspeicher von Apps zugreifen, es sei denn, es wird eine dokumentierte Android-Debugging-Methode verwendet.
  • Geräte dürfen keine Apps enthalten, die auf Daten oder den Arbeitsspeicher anderer Apps oder Prozesse zugreifen.