Wenn ich nur eine auf Benutzernamen / Passwörtern basierende Authentifizierung verwende, sind sie nicht sicher genug?
Nein, da Sie nur identifizieren, dass die WHO auf den API-Server zugreift, nicht jedoch, WAS auf ihn zugreift.
Der Unterschied zwischen WHO und WHAT besteht darin, auf den API-Server zuzugreifen
Um die Unterschiede zwischen der WHO und dem WAS, die auf einen API-Server zugreifen, besser zu verstehen , verwenden wir dieses Bild:
Der beabsichtigte Kommunikationskanal stellt die mobile App dar, die von einem legitimen Benutzer ohne böswillige Absichten wie erwartet verwendet wird, eine nicht manipulierte Version der mobilen App verwendet und direkt mit dem API-Server kommuniziert, ohne dass ein Mann in der Mitte angegriffen wird.
Der tatsächliche Kanal kann verschiedene Szenarien darstellen, z. B. einen legitimen Benutzer mit böswilligen Absichten, der möglicherweise eine neu gepackte Version der mobilen App verwendet, einen Hacker, der die Originalversion der mobilen App verwendet, während ein Mann in der Mitte sie angreift, um zu verstehen, wie Die Kommunikation zwischen der mobilen App und dem API-Server erfolgt, um Angriffe auf Ihre API automatisieren zu können. Viele andere Szenarien sind möglich, aber wir werden hier nicht jedes einzelne aufzählen.
Ich hoffe, dass Sie jetzt vielleicht schon eine Ahnung haben, warum die WHO und das WAS nicht dasselbe sind, aber wenn nicht, wird es gleich klar.
Die WHO ist der Benutzer der mobilen App, die wir auf verschiedene Arten authentifizieren, autorisieren und identifizieren können, beispielsweise mithilfe von OpenID Connect- oder OAUTH2-Flows.
OAUTH
Im Allgemeinen bietet OAuth Clients im Auftrag eines Ressourcenbesitzers einen "sicheren delegierten Zugriff" auf Serverressourcen. Es gibt einen Prozess an, mit dem Ressourcenbesitzer den Zugriff von Drittanbietern auf ihre Serverressourcen autorisieren können, ohne ihre Anmeldeinformationen zu teilen. OAuth wurde speziell für die Verwendung mit HTTP (Hypertext Transfer Protocol) entwickelt und ermöglicht im Wesentlichen die Ausgabe von Zugriffstoken an Clients von Drittanbietern durch einen Autorisierungsserver mit Genehmigung des Ressourcenbesitzers. Der Dritte verwendet dann das Zugriffstoken, um auf die geschützten Ressourcen zuzugreifen, die vom Ressourcenserver gehostet werden.
OpenID Connect
OpenID Connect 1.0 ist eine einfache Identitätsschicht über dem OAuth 2.0-Protokoll. Es ermöglicht Clients, die Identität des Endbenutzers anhand der von einem Autorisierungsserver durchgeführten Authentifizierung zu überprüfen und grundlegende Profilinformationen über den Endbenutzer auf interoperable und REST-ähnliche Weise abzurufen.
Während die Benutzerauthentifizierung den API-Server möglicherweise darüber informiert, dass die WHO die API verwendet, kann nicht garantiert werden, dass die Anforderungen von WAS Sie erwarten, der Originalversion der mobilen App, stammen.
Jetzt müssen wir herausfinden, WAS den API-Server aufruft, und hier werden die Dinge schwieriger, als die meisten Entwickler vielleicht denken. Das WAS ist die Sache, die die Anfrage an den API-Server stellt. Ist es wirklich eine echte Instanz der mobilen App oder ist es ein Bot, ein automatisiertes Skript oder ein Angreifer, der mit einem Tool wie Postman manuell mit dem API-Server herumstochert?
Zu Ihrer Überraschung stellen Sie möglicherweise fest, dass es sich um einen der legitimen Benutzer handelt, der eine neu gepackte Version der mobilen App oder ein automatisiertes Skript verwendet, das versucht, den von der Anwendung bereitgestellten Dienst zu spielen und zu nutzen.
Um das WAS zu identifizieren , greifen Entwickler in der Regel auf einen API-Schlüssel zurück, den sie normalerweise im Code ihrer mobilen App fest codieren. Einige Entwickler gehen noch einen Schritt weiter und berechnen den Schlüssel zur Laufzeit in der mobilen App. Daher wird er zu einem Laufzeitgeheimnis, im Gegensatz zum früheren Ansatz, wenn ein statisches Geheimnis in den Code eingebettet ist.
Der obige Artikel stammt aus einem Artikel mit dem Titel WARUM BRAUCHT IHRE MOBILE APP EINEN API-SCHLÜSSEL? , und das können Sie hier vollständig lesen , das ist der erste Artikel in einer Reihe von Artikeln über API-Schlüssel.
Speichern sensibler Daten auf dem Client-Gerät
Und ich kann diesen Benutzernamen / dieses Passwort aus Sicherheitsgründen natürlich nicht auf dem Gerät speichern? Sollte ich bei der Anmeldung für jeden Benutzer eine GUID ausgeben, diese auf seinem Gerät speichern und jedes Mal während einer API-Anforderung abrufen?
Alles, was Sie auf dem Gerät speichern, auch wenn es verschlüsselt ist, kann zur Laufzeit mit Tools wie Frida oder Xposed rückentwickelt werden.
Frida
Fügen Sie Ihre eigenen Skripte in Black-Box-Prozesse ein. Haken Sie jede Funktion ein, spionieren Sie Krypto-APIs aus oder verfolgen Sie den Code einer privaten Anwendung, ohne dass ein Quellcode erforderlich ist. Bearbeiten Sie, klicken Sie auf Speichern und sehen Sie sofort die Ergebnisse. Alles ohne Kompilierungsschritte oder Programmneustarts.
xPosed
Xposed ist ein Framework für Module, die das Verhalten des Systems und der Apps ändern können, ohne APKs zu berühren. Das ist großartig, weil es bedeutet, dass Module für verschiedene Versionen und sogar ROMs ohne Änderungen arbeiten können (solange der ursprüngliche Code
In einem Gerät, das der Angreifer steuert, kann er auch einen Proxy verwenden, um einen Mann im mittleren Angriff auszuführen, um jedes Geheimnis zu extrahieren, mit dem Sie das WAS oder die WHO identifizieren können, wie ich im Artikel Diesen API-Schlüssel mit einem Mann im Angriff stehlen zeige ::
Während wir fortgeschrittene Techniken wie JNI / NDK verwenden können, um den API-Schlüssel im Code der mobilen App zu verbergen, wird dies niemanden daran hindern, einen MitM-Angriff auszuführen, um den API-Schlüssel zu stehlen. Tatsächlich ist ein MitM-Angriff so einfach, dass er sogar von Nicht-Entwicklern ausgeführt werden kann.
Also was nun ... Bin ich so zum Scheitern verurteilt, dass ich meinen API-Server nicht mehr vor Missbrauch schützen kann? Keine Ruhe also ... Hoffnung besteht noch !!!
Mögliche Lösungen
Kann mir jemand sagen, mit welcher Methode berühmte Android-Anwendungen wie Facebook, FourSquare oder Twitter jede Anfrage von ihrer mobilen Anwendung an ihren Server authentifizieren?
Entschuldigung, aber ich habe nicht genug Wissen über diese Apps, um Sie zu erläutern, aber ich kann Sie auf einige andere Ansätze hinweisen.
Welche anderen Muster verfügbar sind und welche am effizientesten und sichersten sind, brauche ich nur einen Prozessablauf dafür.
Alles, was auf der Clientseite ausgeführt wird und ein Geheimnis für den Zugriff auf eine API benötigt, kann auf unterschiedliche Weise missbraucht werden. In dieser Artikelserie über Sicherheitstechniken für mobile APIs erfahren Sie mehr . In diesem Artikel erfahren Sie, wie API-Schlüssel, Benutzerzugriffstoken, HMAC- und TLS-Pinning zum Schutz der API verwendet werden können und wie sie umgangen werden können.
Um das Problem zu lösen, WAS auf Ihre mobile App zugreift, müssen Sie eine oder alle der Lösungen verwenden, die in der oben erwähnten Artikelserie über mobile API-Sicherheitstechniken erwähnt wurden und akzeptiert haben, dass sie nur den unbefugten Zugriff auf Ihren API-Server erschweren können Bypass aber nicht unmöglich.
Eine bessere Lösung kann verwendet werden, indem eine Mobile App Attestation-Lösung verwendet wird, mit der der API-Server erkennt, dass nur Anforderungen von einer echten mobilen App empfangen werden.
Mobile App Attestation
Durch die Verwendung einer Mobile App Attestation-Lösung kann der API-Server erkennen, WAS die Anforderungen sendet. Auf diese Weise kann er nur auf Anforderungen einer echten mobilen App antworten und alle anderen Anforderungen aus unsicheren Quellen ablehnen.
Die Rolle einer Mobile App Attestation-Lösung besteht darin, zur Laufzeit sicherzustellen, dass Ihre mobile App nicht manipuliert wurde, nicht auf einem gerooteten Gerät ausgeführt wird, nicht von einem Framework wie xPosed oder Frida instrumentiert wird und nicht von MitM angegriffen wird wird durch Ausführen eines SDK im Hintergrund erreicht. Der in der Cloud ausgeführte Dienst fordert die App heraus und bestätigt anhand der Antworten die Integrität der mobilen App und des Geräts, auf dem das Gerät ausgeführt wird. Daher ist das SDK niemals für Entscheidungen verantwortlich.
Bei erfolgreicher Bestätigung der Integrität der mobilen App wird ein kurzlebiges JWT-Token ausgestellt und mit einem Geheimnis signiert, das nur dem API-Server und dem Dienst zur Bestätigung der mobilen App in der Cloud bekannt ist. Im Falle eines Fehlers bei der Bestätigung der mobilen App wird das JWT-Token mit einem Geheimnis signiert, das der API-Server nicht kennt.
Jetzt muss die App bei jedem API-Aufruf das JWT-Token in den Headern der Anfrage senden. Auf diese Weise kann der API-Server Anforderungen nur dann bearbeiten, wenn er die Signatur und die Ablaufzeit im JWT-Token überprüfen und ablehnen kann, wenn die Überprüfung fehlschlägt.
Sobald das vom Mobile App Attestation-Dienst verwendete Geheimnis der mobilen App nicht bekannt ist, kann es zur Laufzeit nicht zurückentwickelt werden, selbst wenn die App manipuliert wird, auf einem gerooteten Gerät ausgeführt wird oder über eine Verbindung kommuniziert, bei der es sich um die Verbindung handelt Ziel eines Mannes im mittleren Angriff.
Der Mobile App Attestation-Dienst existiert bereits als SAAS-Lösung bei Approov (ich arbeite hier) und bietet SDKs für verschiedene Plattformen, einschließlich iOS, Android, React Native und andere. Die Integration erfordert auch eine kleine Überprüfung des API-Servercodes, um das vom Cloud-Dienst ausgegebene JWT-Token zu überprüfen. Diese Überprüfung ist erforderlich, damit der API-Server entscheiden kann, welche Anforderungen zu bedienen und welche abzulehnen sind.
Fazit
Letztendlich muss die Lösung zum Schutz Ihres API-Servers entsprechend dem Wert dessen, was Sie schützen möchten, und den gesetzlichen Anforderungen für diese Art von Daten wie den GDPR-Bestimmungen in Europa ausgewählt werden.
MÖCHTEN SIE DIE EXTRA MILE GEHEN?
OWASP Mobile Security Project - Top 10 Risiken
Das OWASP Mobile Security Project ist eine zentralisierte Ressource, mit der Entwickler und Sicherheitsteams die Ressourcen erhalten, die sie zum Erstellen und Verwalten sicherer mobiler Anwendungen benötigen. Im Rahmen des Projekts ist es unser Ziel, mobile Sicherheitsrisiken zu klassifizieren und Entwicklungskontrollen bereitzustellen, um deren Auswirkungen oder die Wahrscheinlichkeit einer Ausnutzung zu verringern.
