OWASP-Kategorie:MASVS-PLATFORM: Platform Interaction
Übersicht
Viele mobile Anwendungen verwenden eine externe API, um Funktionen bereitzustellen. Bisher wurde ein statisches Token oder ein statischer Schlüssel verwendet, um die Anwendung zu authentifizieren, die eine Verbindung zum Dienst herstellt.
Im Kontext einer Client-Server-Umgebung (oder einer mobilen App und API) gilt die Verwendung eines statischen Schlüssels jedoch im Allgemeinen nicht als sichere Authentifizierungsmethode für den Zugriff auf vertrauliche Daten oder Dienste. Im Gegensatz zur internen Infrastruktur kann jeder auf eine externe API zugreifen und den Dienst missbrauchen, wenn er Zugriff auf diesen Schlüssel hat.
Beispielsweise kann ein statischer Schlüssel entweder durch Reverse Engineering aus der Anwendung abgeleitet oder abgefangen werden, wenn eine mobile Anwendung mit der externen API kommuniziert. Außerdem ist es wahrscheinlicher, dass dieser statische Schlüssel in der Anwendung hartcodiert ist.
Das Risiko für die API-Daten und -Dienste entsteht, wenn keine ausreichend sicheren Authentifizierungs- und Zugriffssteuerungen verwendet werden.
Bei Verwendung eines statischen Schlüssels kann die API ausgenutzt werden, indem Anfragen wiedergegeben oder neue Anfragen mit dem (abgefangenen oder durch Reverse Engineering ermittelten) Schlüssel ohne Zeitbeschränkungen erstellt werden.
Positiv beeinflussen
Wenn ein Entwickler für einen KI- oder ML-API-Dienst bezahlt, kann ein Angreifer diesen Schlüssel relativ einfach stehlen und Schulden für den Dienst verursachen oder ihn verwenden, um gefälschte Inhalte zu erstellen.
Alle Nutzerdaten, Dateien oder personenbezogenen Daten, die in der API gespeichert sind, wären frei verfügbar, was zu schädlichen Lecks führen würde.
Ein Angreifer kann diesen Zugriff auch nutzen, um betrügerische Handlungen vorzunehmen, Dienste umzuleiten und in seltenen Fällen die vollständige Kontrolle über die Server zu erlangen.
Maßnahmen zur Risikominderung
Zustandsbehaftete API
Wenn die Anwendung eine Nutzeranmeldung bietet oder Nutzer-Sessions verfolgen kann, empfehlen wir Entwicklern, einen API-Dienst wie Google Cloud für die zustandsbehaftete Integration in ihre App zu verwenden.
Verwenden Sie außerdem die sichere Authentifizierung, Clientvalidierung und Sitzungssteuerung, die vom API-Dienst bereitgestellt werden, und erwägen Sie, ein dynamisches Token anstelle eines statischen Schlüssels zu verwenden. Das Token sollte nach einer angemessen kurzen Zeit ablaufen (in der Regel nach einer Stunde).
Das dynamische Token sollte dann zur Authentifizierung verwendet werden, um Zugriff auf die API zu erhalten. In diesen Richtlinien wird beschrieben, wie dies mit OAuth 2.0 erreicht werden kann. Zusätzlich zu diesen Richtlinien kann OAuth 2.0 weiter gestärkt werden, um Sicherheitslücken in Ihrer Android-App zu reduzieren. Dazu müssen Sie die folgenden Funktionen implementieren.
Implementieren Sie eine angemessene Fehlerbehandlung und ein angemessenes Logging:
- OAuth-Fehler sollten auf angemessene und sichtbare Weise behandelt und zu Debugging-Zwecken protokolliert werden.
- Eine reduzierte Angriffsfläche hilft Ihnen auch dabei, eventuelle Probleme zu erkennen und zu beheben.
- Achten Sie darauf, dass alle Nachrichten, die protokolliert oder dem Nutzer präsentiert werden, klar formuliert sind, aber keine Informationen enthalten, die für einen Angreifer nützlich sein könnten.
OAuth in der Anwendung sicher konfigurieren:
- Senden Sie den Parameter
redirect_urisowohl an die Autorisierungs- als auch an die Tokenendpunkte. - Wenn Ihre App OAuth mit einem Drittanbieterdienst verwendet, konfigurieren Sie CORS (Cross-Origin Resource Sharing), um den Zugriff auf die Ressourcen Ihrer App einzuschränken.
- So können unbefugte Cross-Site-Scripting-Angriffe (XSS) verhindert werden.
- Verwenden Sie den Statusparameter, um CSRF-Angriffe zu verhindern.
Sicherheitsbibliothek verwenden:
- Verwenden Sie eine Sicherheitsbibliothek wie AppAuth, um die Implementierung sicherer OAuth-Abläufe zu vereinfachen.
- Diese Android-Bibliotheken können helfen, viele der zuvor erwähnten Sicherheits-Best Practices zu automatisieren.
Andere Authentifizierungsmethoden, einschließlich Firebase- und Google-ID-Tokens, werden in der OpenAPI-Dokumentation beschrieben.
Zustandslose API
Wenn der API-Dienst keinen der zuvor empfohlenen Schutzmechanismen bietet und es eine Anforderung für zustandslose Sitzungen ohne Nutzeranmeldung gibt, müssen Entwickler möglicherweise eigene Middleware-Lösungen bereitstellen.
Dazu müssten Anfragen zwischen der App und dem API-Endpunkt „weitergeleitet“ werden. Eine Möglichkeit hierfür ist die Verwendung von JSON Web Tokens (JWT) und JSON Web Signature (JWS) oder die Bereitstellung eines vollständig authentifizierten Dienstes, wie oben empfohlen. So kann der anfällige statische Schlüssel serverseitig statt in der Anwendung (Client) gespeichert werden.
Es gibt inhärente Probleme bei der Bereitstellung einer End-to-End-Lösung ohne Status in mobilen Anwendungen. Zu den wichtigsten Herausforderungen gehören die Validierung des Clients (der App) und die sichere Speicherung des privaten Schlüssels oder des Secrets auf dem Gerät.
Die Play Integrity API bietet eine Validierung der Integrität der Anwendung und der Anfragen. Dadurch können einige Szenarien, in denen dieser Zugriff missbraucht werden kann, abgemildert werden. Was die Schlüsselverwaltung betrifft, ist in vielen Fällen der Schlüsselspeicher der beste Ort für die sichere Speicherung privater Schlüssel.
Einige mobile Anwendungen verwenden eine Registrierungsphase, um die Integrität der Anwendung zu prüfen und einen Schlüssel über einen sicheren Austausch bereitzustellen. Diese Methoden sind komplex und werden in diesem Dokument nicht behandelt. Eine mögliche Lösung ist jedoch ein Cloud Key Management Service.