OWASP-Kategorie: MASVS-PLATFORM: Plattforminteraktion
Übersicht
Eine Android-Berechtigung ist eine String-ID, die im Manifest der App deklariert wird, um Zugriff auf eingeschränkte Daten oder Aktionen anzufordern, die vom Android-Framework zur Laufzeit erzwungen werden.
Die Android-Berechtigungsstufen geben das potenzielle Risiko an, das mit der Berechtigung verbunden ist:
- Normal: Berechtigungen mit geringem Risiko, die bei der Installation automatisch gewährt werden
- Gefährlich: Berechtigungen mit hohem Risiko, die den Zugriff auf vertrauliche Nutzerdaten ermöglichen und eine ausdrückliche Nutzergenehmigung zur Laufzeit erfordern
- Signatur: Wird nur für Apps gewährt, die mit demselben Zertifikat signiert sind wie die App, in der die Berechtigung erklärt wird. Wird in der Regel für System-Apps oder Interaktionen zwischen Apps desselben Entwicklers verwendet.
Sicherheitslücken im Zusammenhang mit berechtigungsbasierten Zugriffssteuerungen treten auf, wenn eine Komponente einer App (z. B. Aktivität, Empfänger, Inhaltsanbieter oder Dienst) alle folgenden Kriterien erfüllt:
- Die Komponente ist mit keinem
android:permission
in derManifest
verknüpft. - Die Komponente führt eine sensible Aufgabe aus, für die eine Berechtigung vorhanden ist, die der Nutzer bereits genehmigt hat.
- Die Komponente wird exportiert.
- Die Komponente führt keine manuellen Berechtigungsprüfungen (auf Manifest- oder Codeebene) durch.
In diesem Fall kann eine schädliche App sensible Aktionen ausführen, indem sie die Berechtigungen der angreifbaren Komponente missbraucht und die Berechtigungen der angreifbaren App an die schädliche App weiterleitet.
Positiv beeinflussen
Der Export von angreifbaren Komponenten kann dazu verwendet werden, Zugriff auf vertrauliche Ressourcen zu erhalten oder vertrauliche Aktionen auszuführen. Die Auswirkungen dieses unerwünschten Verhaltens hängen vom Kontext der angreifbaren Komponente und ihren Berechtigungen ab.
Abhilfemaßnahmen
Berechtigungen für sensible Aufgaben anfordern
Wenn Sie eine Komponente mit vertraulichen Berechtigungen exportieren, müssen für alle eingehenden Anfragen dieselben Berechtigungen erforderlich sein. Die Android Studio IDE bietet Lint-Prüfungen für Empfänger und Dienste, um diese Sicherheitslücke zu erkennen und die erforderlichen Berechtigungen zu empfehlen.
Entwickler können Berechtigungen für eingehende Anfragen anfordern, indem sie sie entweder in der Datei Manifest
oder auf Codeebene bei der Implementierung des Dienstes deklarieren, wie in den folgenden Beispielen gezeigt.
XML
<manifest ...>
<uses-permission android:name="android.permission.READ_CONTACTS" />
<application ...>
<service android:name=".MyExportService"
android:exported="true"
android:permission="android.permission.READ_CONTACTS" />
</application>
</manifest>
Kotlin
class MyExportService : Service() {
private val binder = MyExportBinder()
override fun onBind(intent: Intent): IBinder? {
// Enforce calling app has the required permission
enforceCallingPermission(Manifest.permission.READ_CONTACTS, "Calling app doesn't have READ_CONTACTS permission.")
// Permission is enforced, proceed with export logic
return binder
}
// Inner class for your Binder implementation
private inner class MyExportBinder : Binder() {
// Permission is enforced, proceed with export logic
}
}
Java
public class MyExportService extends Service {
@Override
public IBinder onBind(Intent intent) {
// Enforce calling app has the required permission
enforceCallingPermission(Manifest.permission.READ_CONTACTS, "Calling app doesn't have READ_CONTACTS permission.");
return binder;
}
// Inner class for your Binder implementation
private class MyExportBinder extends Binder {
// Permission is enforced, proceed with export logic
}
}
Komponente nicht exportieren
Exportieren Sie Komponenten mit Zugriff auf vertrauliche Ressourcen nur, wenn es unbedingt erforderlich ist. Dazu müssen Sie in der Datei Manifest
den Wert für android:exported
für Ihre Komponente auf false
festlegen. Ab API-Level 31 wird dieses Attribut standardmäßig auf false
festgelegt.
XML
<activity
android:name=".MyActivity"
android:exported="false"/>
Signaturbasierte Berechtigungen anwenden
Verwenden Sie signaturbasierte Berechtigungen, wenn Sie Daten zwischen zwei Apps freigeben, die Sie verwalten oder besitzen. Für diese Berechtigungen ist keine Nutzerbestätigung erforderlich. Stattdessen wird geprüft, ob die Apps, die auf die Daten zugreifen, mit demselben Signaturschlüssel signiert sind. Diese Einrichtung bietet eine optimierte und sicherere Nutzererfahrung. Beachten Sie bei der Deklaration benutzerdefinierter Berechtigungen die entsprechenden Sicherheitsrichtlinien.
XML
<manifest xmlns:android="http://schemas.android.com/apk/res/android"
package="com.example.myapp">
<permission android:name="my_custom_permission_name"
android:protectionLevel="signature" />
Endpunkte für eine einzelne Aufgabe
Implementieren Sie Ihre App gemäß dem Designprinzip Aufgabentrennung. Jeder Endpunkt sollte nur eine kleine Anzahl bestimmter Aufgaben mit bestimmten Berechtigungen ausführen. Diese gute Designpraxis ermöglicht es dem Entwickler auch, detaillierte Berechtigungen für jeden Endpunkt anzuwenden. Erstellen Sie beispielsweise keinen einzelnen Endpunkt, der sowohl für den Kalender als auch für Kontakte verwendet wird.
Ressourcen
- Android-Zugriff auf app-geschützte Komponenten aus dem Blog „Oversecured“
- Best Practices für Contentanbieter
- Laufzeitberechtigungen (gefährlich)
- Designprinzip der Trennung von Bedenken
- Dokumentation zu Android-Berechtigungen
- Sicherheitstipps für Android-Broadcast-Empfänger
- Sicherheitstipps für Android-Dienste
- Für Android 12 (API 31) wurde „false“ als Standardwert für den Export festgelegt.
- Lint-Prüfung: Exportierte PreferenceActivity sollte nicht exportiert werden
- Lint-Prüfung: Für den exportierten Empfänger ist keine Berechtigung erforderlich
- Lint-Prüfung: Für den exportierten Dienst ist keine Berechtigung erforderlich