Sichere Programmierung: Das Problem der benutzerdefinierten Berechtigungen

Bei der Entwicklung für Mobilgeräte müssen Anwendungen häufig bestimmte Berechtigungen vom System anfordern. Sie benötigen möglicherweise Zugriff auf die Kontakte des Benutzers, die Bluetooth-Verbindung oder die Möglichkeit, SMS-Nachrichten zu versenden. Alle genannten Berechtigungen sind Plattformberechtigungen, die vom Android-Framework definiert werden.

Es gibt jedoch Fälle, in denen diese nicht ausreichen und die Anwendung ihre eigenen benutzerdefinierten Berechtigungen definieren muss. Ich verwende unser eigenes Unternehmen als Beispiel. Secure Code Warrior könnte eine App erstellen, die private Daten als Teil eines Profils speichert, einschließlich der Leistung des Benutzers auf der SCW-Plattform. Wir möchten einer anderen Sicherheitsschulungs-App, sagen wir DevTrainer, erlauben, diese Daten zu verwenden, wenn der Benutzer ihnen die Erlaubnis dazu erteilt. Da es sich um sensible Daten handelt, möchte der Benutzer sicherlich nicht, dass jeder darauf zugreifen kann, aber die SCWApp sollte sie auch nicht vollständig verbergen und schützen, da sie nützlich sein könnten. Wir möchten dem Benutzer also die Kontrolle darüber überlassen. Hier kommen benutzerdefinierte Berechtigungen ins Spiel.

Die SCWApp erstellt eine benutzerdefinierte Berechtigung, DevTrainer fordert diese Berechtigung an und der Benutzer kann entscheiden, ob er dies zulassen möchte oder nicht. Dies ist eine gängige Praxis und eine gute Möglichkeit, den Zugriff auf Anwendungen auf einer Whitelist zu beschränken.

Leider gibt es einige unintuitive Verhaltensweisen bei benutzerdefinierten Berechtigungen, die sie aus Sicherheitssicht riskant machen. Konkret können benutzerdefinierte Berechtigungen von jeder App jederzeit definiert werden, wobei das Prinzip „Wer zuerst kommt, mahlt zuerst“ gilt – und diese Strategie hat einige Konsequenzen.

Für das folgende Szenario definieren wir zwei App-Profile, die wir oben vorgestellt haben (alle diese Anwendungen sind fiktiv und dienen nur zu Demonstrationszwecken):

1. SCWApp: die App, die eine benutzerdefinierte Berechtigung definiert und eine Komponente mithilfe dieser Berechtigung schützt.

2. DevTrainer: diese App definiert dieselbe Berechtigung wie die SCWApp und erklärt dem Benutzer, dass sie diese Berechtigung erhalten möchte.

Dies ist ein häufiges Szenario, das als „Peer Apps Case“ bezeichnet wird. Wäre die DevTrainer-App nur ein Plugin für die SCWApp, müsste sie die benutzerdefinierte Berechtigung nicht definieren. Die Annahme ist in diesem Fall, dass die SCWApp vor DevTrainer installiert wird und kein unerwartetes Verhalten auftritt. Wenn der Benutzer DevTrainer jedoch zuerst installiert, wird er nicht über die Berechtigungsanfrage informiert. Installiert der Benutzer später die SCWApp, wird DevTrainer die Berechtigung nicht rückwirkend erteilt, sodass die Versuche der DevTrainer-App, die geschützte Komponente zu verwenden, fehlschlagen.

Hier kommt der „Peers App Case“ ins Spiel. In manchen Fällen kann man nicht davon ausgehen, dass eine App vor der anderen installiert wird. Wenn beispielsweise Facebook und Twitter beide die Komponenten des jeweils anderen nutzen möchten, müssen sie die benutzerdefinierten Berechtigungen des anderen definieren.

Hier wird es jedoch kompliziert. Wenn die DevTrainer-App zuerst installiert wird, wird der Benutzer nicht über die Anfrage für die benutzerdefinierte Berechtigung informiert. An diesem Punkt besitzt DevTrainer die benutzerdefinierte Berechtigung und kann auf die geschützte Komponente zugreifen, obwohl der Benutzer nicht informiert wurde.

Es wird noch komplizierter. Die DevTrainer-App kann die Schutzstufe der Berechtigungen ändern. Android verwendet nicht die Schutzstufe des Verteidigers, sondern die zuerst definierte Schutzstufe. Das bedeutet, dass die App, die zuerst installiert wurde, diese definieren kann. Wenn DevTrainer also die Berechtigungsstufe auf „normal“ ändert, müssen zukünftige Apps, die diese Berechtigung anfordern, nicht vom Benutzer bestätigt werden, sondern erhalten automatisch Zugriff.

Dieses Szenario wurde durch die Erklärung dieses Problems auf dem cwac-security github inspiriert.

Die „Wer zuerst kommt, mahlt zuerst“-Strategie hat gefährliche Konsequenzen. Wenn man dieses Verhalten nicht kennt, trifft man als Entwickler möglicherweise Sicherheitsentscheidungen auf Basis nicht vertrauenswürdiger Eingaben und erlaubt unbeabsichtigt Apps den Zugriff auf sensible Daten oder geschützte Dienste. Um mehr darüber zu erfahren, wie man Sicherheitsentscheidungen durch nicht vertrauenswürdige Eingaben vermeidet, besuchen Sie unsere Plattform. Dieses Verhalten wurde ab Android 5.0 (Lollipop) geändert. Da jedoch derzeit mehr als 22 % der Android-Geräte noch mit einer älteren Android-Version laufen, ist es wichtig, die Risiken des ursprünglichen Verhaltens in Ihrer App zu mindern. Prüfen Sie beim ersten Start Ihrer App, ob die Berechtigung bereits definiert wurde, und ergreifen Sie entsprechende Maßnahmen, um Sicherheitsrisiken zu beheben.

Viel Erfolg beim Programmieren und bis nächste Woche!

Durch die Definition benutzerdefinierter Berechtigungen kann eine App ihre Ressourcen und Funktionen für andere Apps freigeben.

https://developer.android.com/guide/topics/permissions/defining.html