Berechtigungen
Da Android-Anwendungen voneinander getrennt sind, müssen Anwendungen explizit Ressourcen und Daten gemeinsam nutzen. Dazu deklarieren sie die Berechtigungen, die sie für zusätzliche Funktionen benötigen, die nicht von der Basis-Sandbox bereitgestellt werden, einschließlich des Zugriffs auf Gerätefunktionen wie die Kamera.
Erlaubnisanfragen
Minimieren Sie die Anzahl der Berechtigungen, die Ihre App anfordert. Die Beschränkung des Zugriffs auf vertrauliche Berechtigungen verringert das Risiko eines versehentlichen Missbrauchs dieser Berechtigungen, verbessert die Benutzerakzeptanz und macht Ihre App weniger anfällig für Angreifer. Wenn für die Funktion Ihrer App keine Berechtigung erforderlich ist, fordern Sie diese im Allgemeinen nicht an. Lesen Sie den Leitfaden zur Bewertung, ob Ihre App Berechtigungen deklarieren muss.
Gestalten Sie Ihre Anwendung nach Möglichkeit so, dass keine Berechtigungen erforderlich sind. Anstatt beispielsweise Zugriff auf Geräteinformationen anzufordern, um eine eindeutige Kennung zu erstellen, erstellen Sie eine UUID für Ihre Anwendung (siehe Abschnitt über Benutzerdaten). Oder anstatt externen Speicher zu verwenden (für den eine Genehmigung erforderlich ist), speichern Sie Daten im internen Speicher.
Zusätzlich zum Anfordern von Berechtigungen kann Ihre Anwendung das <permission>-Element verwenden, um sicherheitsrelevante IPCs zu schützen, die anderen Anwendungen wie einem ContentProvider ausgesetzt sind. Im Allgemeinen empfehlen wir, wenn möglich, andere Zugriffskontrollen als vom Benutzer bestätigte Berechtigungen zu verwenden, da Berechtigungen für Benutzer verwirrend sein können. Erwägen Sie beispielsweise die Verwendung der Signaturschutzstufe für Berechtigungen für die IPC-Kommunikation zwischen Anwendungen, die von einem einzelnen Entwickler bereitgestellt werden.
Geben Sie keine berechtigungsgeschützten Daten preis. Dies geschieht, wenn Ihre App Daten über IPC verfügbar macht, die nur verfügbar sind, weil Ihre App über die Berechtigung zum Zugriff auf diese Daten verfügt. Die Clients der IPC-Schnittstelle Ihrer App verfügen möglicherweise nicht über dieselbe Datenzugriffsberechtigung. Weitere Details zur Häufigkeit und den möglichen Auswirkungen dieses Problems finden Sie im Forschungspapier Permission Re-Delegation: Attacks and Defenses, veröffentlicht bei USENIX.
Berechtigungsdefinitionen
Definieren Sie den kleinsten Satz an Berechtigungen, der Ihren Sicherheitsanforderungen entspricht. Das Erstellen einer neuen Berechtigung ist für die meisten Anwendungen relativ ungewöhnlich, da die systemdefinierten Berechtigungen viele Situationen abdecken. Führen Sie gegebenenfalls Zugriffsprüfungen anhand vorhandener Berechtigungen durch.
Wenn Sie eine neue Berechtigung benötigen, überlegen Sie, ob Sie Ihre Aufgabe mit einer Signaturschutzstufe erfüllen können. Signaturberechtigungen sind für den Benutzer transparent und ermöglichen den Zugriff nur Anwendungen, die von demselben Entwickler signiert sind wie die Anwendung, die die Berechtigungsprüfung durchführt.
Wenn das Erstellen einer neuen Berechtigung dennoch erforderlich ist, deklarieren Sie diese im App-Manifest mithilfe des Elements <permission>. Apps, die die neue Berechtigung verwenden, können darauf verweisen, indem sie ihren Manifestdateien ein <uses-permission>-Element hinzufügen. Sie können Berechtigungen auch dynamisch hinzufügen, indem Sie die Methode addPermission() verwenden.
Wenn Sie eine Berechtigung mit der Schutzstufe „Gefährlich“ erstellen, müssen Sie eine Reihe von Komplexitäten berücksichtigen:
Die Berechtigung muss eine Zeichenfolge enthalten, die dem Benutzer die Sicherheitsentscheidung, die er treffen muss, prägnant zum Ausdruck bringt.
Die Berechtigungszeichenfolge muss für viele verschiedene Sprachen lokalisiert werden.
Benutzer entscheiden sich möglicherweise dafür, eine Anwendung nicht zu installieren, weil eine Berechtigung verwirrend ist oder als riskant empfunden wird.
Anwendungen fordern möglicherweise die Berechtigung an, wenn der Ersteller der Berechtigung nicht installiert wurde.
Jedes davon stellt für Sie als Entwickler eine erhebliche nichttechnische Herausforderung dar und verwirrt gleichzeitig Ihre Benutzer. Aus diesem Grund raten wir von der Verwendung der gefährlichen Berechtigungsstufe ab.