Die Popularität mobiler Anwendungen nimmt weiter zu. Dies gilt auch für das OAuth 2.0-Protokoll für mobile Apps. Es reicht nicht aus, Standard zu implementieren, um das OAuth 2.0-Protokoll dort sicher zu machen. Man muss die Besonderheiten mobiler Anwendungen berücksichtigen und einige zusätzliche Sicherheitsmechanismen anwenden.

In diesem Artikel möchte ich die Konzepte mobiler OAuth 2.0-Angriffe und Sicherheitsmechanismen zur Verhinderung solcher Probleme erläutern. Beschriebene Konzepte sind nicht neu, aber es fehlen strukturierte Informationen zu diesem Thema. Das Hauptziel des Artikels ist es, diese Lücke zu schließen.

OAuth 2.0 Art und Zweck

OAuth 2.0 ist ein Autorisierungsprotokoll , das eine Möglichkeit für einen Clientdienst beschreibt, einen sicheren Zugriff auf die Ressourcen des Benutzers bei einem Dienstanbieter zu erhalten. Dank OAuth 2.0 muss der Benutzer sein Passwort nicht außerhalb des Dienstanbieters eingeben: Der gesamte Vorgang beschränkt sich auf das Klicken auf die Schaltfläche "Ich stimme zu, Zugriff auf ... zu gewähren".

Ein Anbieter ist ein Dienst, dem die Benutzerdaten gehören und der mit Erlaubnis des Benutzers Diensten (Clients) von Drittanbietern einen sicheren Zugriff auf diese Daten bietet. Ein Client ist eine Anwendung, die die vom Anbieter gespeicherten Benutzerdaten abrufen möchte.

Kurz nach der Veröffentlichung des OAuth 2.0-Protokolls wurde es für die Authentifizierung angepasst, obwohl es nicht dafür gedacht war. Durch die Verwendung von OAuth 2.0 zur Authentifizierung wird ein Angriffsvektor von den beim Dienstanbieter gespeicherten Daten auf die Benutzerkonten des Clientdienstes verschoben.

Die Authentifizierung war jedoch nur ein Anfang. In Zeiten mobiler Apps und der Verherrlichung von Conversions klang der Zugriff auf eine App mit nur einer Taste gut. Entwickler haben OAuth 2.0 für den mobilen Einsatz angepasst. Natürlich machten sich nicht viele Sorgen um die Sicherheit und die Besonderheiten mobiler Apps: zap und in die Produktion gingen sie! Andererseits funktioniert OAuth 2.0 außerhalb von Webanwendungen nicht gut: Sowohl bei mobilen als auch bei Desktop-Apps treten dieselben Probleme auf.

Lassen Sie uns also herausfinden, wie Sie Mobile OAuth 2.0 sicher machen können.

Wie funktioniert es

Es gibt zwei Hauptprobleme bei der mobilen OAuth 2.0-Sicherheit:

Nicht vertrauenswürdiger Kunde. Einige mobile Anwendungen haben kein Backend für OAuth 2.0, sodass der Client-Teil des Protokollflusses auf dem mobilen Gerät ausgeführt wird.
Die Umleitungen von einem Browser zu einer mobilen App verhalten sich je nach Systemeinstellungen, Reihenfolge der Installation der Anwendungen und anderer Magie unterschiedlich.

Schauen wir uns diese Themen genauer an.

Mobile Anwendung ist ein öffentlicher Client

Um die Wurzeln und Konsequenzen des ersten Problems zu verstehen, sehen wir uns an, wie OAuth 2.0 bei Server-zu-Server-Interaktion funktioniert, und vergleichen es dann mit OAuth 2.0 bei Client-zu-Server-Interaktion.

In beiden Fällen beginnt alles mit den Client-Service-Registern im Provider-Service und empfängt client_id und in einigen Fällen , client_secret. client_id , client_secret. client_id ist ein öffentlicher Wert, der für die Identifizierung des client_secret erforderlich ist, im Gegensatz zum Wert client_secret , der privat ist. Weitere Informationen zum Registrierungsprozess finden Sie in RFC 7591 .

Das folgende Schema zeigt die Funktionsweise von OAuth 2.0 bei Server-zu-Server-Interaktionen.

Bildursprung: https://tools.ietf.org/html/rfc6749#section-1.2

Das OAuth 2.0-Protokoll kann in drei Hauptschritte unterteilt werden:

[Schritte AC] Erhalten Sie einen authorization_code (im Folgenden code ).
[Schritte DE] Tauschen Sie den code in access_token .
Ressource über access_token .

Lassen Sie uns den Prozess zum Abrufen des code näher erläutern:

[Schritt A] Der Client leitet den Benutzer an den Dienstanbieter weiter.
[Schritt B] Der Dienstanbieter fordert vom Benutzer die Erlaubnis an, dem Client die Daten bereitzustellen (Pfeil B nach oben). Der Benutzer bietet Datenzugriff (Pfeil B nach rechts).
[Schritt C] Der Dienstanbieter gibt code an den Benutzerbrowser zurück, der den code an den Client weiterleitet.

Lassen Sie uns mehr über den Prozess des access_token von access_token :

[Schritt D] Der Client-Server sendet eine Anforderung für access_token . Code , client_secret und redirect_uri sind in der Anfrage enthalten.
[Schritt E] Bei gültigem code , client_secret und redirect_uri , wird access_token bereitgestellt.

Die Anforderung von access_token erfolgt gemäß dem Server-zu-Server-Schema. Daher muss der Angreifer im Allgemeinen den Client-Service-Server oder den Service-Provider-Server hacken, um access_token zu stehlen.

Betrachten wir nun das mobile OAuth 2.0-Schema ohne Backend (Client-Server-Interaktion).

Bildursprung: https://tools.ietf.org/html/rfc8252#section-4.1

Das Hauptschema ist in die gleichen Hauptschritte unterteilt:

[Schritte 1-4 im Bild] code abrufen.
[Schritte 5-6 im Bild] Tauschen Sie den code in access_token
access_token Ressourcenzugriff über access_token

In diesem Fall verfügt die mobile App jedoch auch über die Serverfunktionen. Daher würde client_secret in die Anwendung eingebettet. Daher kann client_secret auf mobilen Geräten nicht vor Angreifern verborgen client_secret . Eingebettetes client_secret kann auf zwei Arten extrahiert werden: durch Analyse des Anwendungs-Server-Verkehrs oder durch Reverse Engineering. Beides kann einfach implementiert werden, weshalb client_secret auf Mobilgeräten unbrauchbar ist.

Sie könnten fragen: "Warum bekommen wir nicht sofort access_token ?" Sie könnten denken, dass dieser zusätzliche Schritt unnötig ist. Darüber hinaus gibt es ein implizites Grant- Schema, mit dem ein Client access_token sofort empfangen access_token . Obwohl es in einigen Fällen verwendet werden kann, funktioniert Implicit Grant nicht für sicheres mobiles OAuth 2.0.

Umleitung auf mobilen Geräten

Im Allgemeinen werden benutzerdefinierte URI- Schema- und AppLink- Mechanismen für die Umleitung von Browser zu App verwendet. Keiner dieser Mechanismen kann so sicher sein wie Browser-Weiterleitungen für sich.

Das benutzerdefinierte URI-Schema (oder Deep Link) wird folgendermaßen verwendet: Ein Entwickler bestimmt vor der Bereitstellung ein Anwendungsschema. Das Schema kann ein beliebiges sein, und ein Gerät kann mehrere Anwendungen mit demselben Schema haben.

Dies erleichtert die Arbeit, wenn jedes Schema auf einem Gerät einer Anwendung entspricht. Was aber, wenn zwei Anwendungen dasselbe Schema auf einem Gerät registrieren? Wie entscheidet das Betriebssystem, welche App geöffnet werden soll, wenn es über das benutzerdefinierte URI-Schema kontaktiert wird? Android zeigt ein Fenster mit einer Auswahl an Apps und einem Link, dem Sie folgen können. iOS hat hierfür kein Verfahren und daher kann jede Anwendung geöffnet werden. Auf jeden Fall hat der Angreifer die Möglichkeit, Code oder access_token abzufangen .

Im Gegensatz zum benutzerdefinierten URI-Schema garantiert AppLink , dass die richtige Anwendung geöffnet wird. Dieser Mechanismus weist jedoch mehrere Mängel auf:

Jeder Service-Client muss sich dem Überprüfungsverfahren unterziehen .
Android-Benutzer können AppLink für eine bestimmte App in den Einstellungen deaktivieren.
Android-Versionen älter als 6.0 und iOS-Versionen älter als 9.0 unterstützen AppLink nicht.

All diese AppLink-Fehler verlängern die Lernkurve für potenzielle Service-Clients und können unter bestimmten Umständen zu einem OAuth 2.0-Fehler des Benutzers führen. Aus diesem Grund wählen viele Entwickler den AppLink-Mechanismus nicht als Ersatz für die Browserumleitung im OAuth 2.0-Protokoll.

OK, was gibt es zum Angriff?

Mobile OAuth 2.0-Probleme haben einige spezifische Angriffe verursacht. Mal sehen, was sie sind und wie sie funktionieren.

Abfangangriff auf Autorisierungscode

Betrachten wir die Situation, in der das Benutzergerät eine legitime Anwendung (OAuth 2.0-Client) und eine bösartige Anwendung hat, die dasselbe Schema wie die legitime registriert hat. Das Bild unten zeigt das Angriffsschema.

Bildursprung https://tools.ietf.org/html/rfc7636#section-1

Hier ist das Problem: Im vierten Schritt gibt der Browser den code in der Anwendung über das benutzerdefinierte URI-Schema zurück. Daher kann der code von einer böswilligen App abgefangen werden (da er dasselbe Schema wie eine legitime App registriert hat). Anschließend ändert die böswillige App den code in access_token und erhält Zugriff auf die Benutzerdaten.

Was ist der Schutz? In einigen Fällen können Sie die Kommunikation zwischen Prozessen verwenden. Wir werden später darüber sprechen. Im Allgemeinen benötigen Sie ein Schema namens Proof Key für Code Exchange . Es ist im folgenden Schema beschrieben.

Bildursprung: https://tools.ietf.org/html/rfc7636#section-1.1

Die code_verifier verfügt über mehrere zusätzliche Parameter: code_verifier , code_challenge (im Schema t(code_verifier) ) und code_challenge_method (im Schema t_m ).

Code_verifier - ist eine Zufallszahl mit einer Mindestlänge von 256 Bit , die nur einmal verwendet wird . Ein Client muss code_verifier für jede code_verifier einen neuen code_verifier code .

Code_challenge_method - Dies ist ein Name einer Konvertierungsfunktion, meistens SHA-256.

Code_challenge - ist der code_verifier auf den die Konvertierung von code_challenge_method angewendet wurde und der in URL Safe Base64 codiert wurde.

Die Konvertierung von code_verifier in code_challenge ist erforderlich, um die Angriffsvektoren basierend auf code_verifier Abfangen von code_verifier (z. B. aus den Gerätesystemprotokollen) beim Anfordern von code code_verifier .

Wenn ein Benutzergerät SHA-256 nicht unterstützt , kann ein client is allowed to use plain conversion of code_verifier . In allen anderen Fällen muss SHA-256 verwendet werden.

So funktioniert dieses Schema:

Der Client generiert code_verifier und speichert ihn.
Der Client wählt code_challenge_method und empfängt code_challenge von code_verifier .
[Schritt A] Der Client fordert code , wobei der Anforderung code_challenge und code_challenge_method hinzugefügt werden.
[Schritt B] Der Anbieter speichert code_challenge und code_challenge_method auf dem Server und gibt code an einen Client zurück.
[Schritt C] Der Client fordert access_token und code_verifier hinzu.
Der Anbieter empfängt code_challenge vom eingehenden code_verifier und vergleicht ihn code_challenge mit dem von ihm gespeicherten code_challenge .
[Schritt D] Wenn die Werte übereinstimmen, gibt der Anbieter dem Client access_token .

Um zu verstehen, warum code_challenge Abfangen von Code code_challenge , sehen wir uns an, wie der Protokollfluss aus der Sicht des Angreifers aussieht.

Zunächst legitimer App-Anforderungscode ( code_challenge und code_challenge_method werden zusammen mit der Anforderung gesendet).
Schädliche App fängt code (aber nicht code_challenge , da _challenge nicht in der Antwort enthalten ist).
Schädliche App fordert access_token (mit gültigem code , aber ohne gültigen code_verifier ).
Der Server stellt eine code_challenge von code_challenge und gibt eine Fehlermeldung aus.

Beachten Sie, dass der Angreifer code_verifier (zufälliger 256-Bit-Wert!) Nicht erraten oder irgendwo in den Protokollen finden kann (da die erste Anforderung tatsächlich code_challenge übertragen code_challenge ).

code_challenge beantwortet also die Frage des Dienstanbieters: "Wird access_token von demselben App-Client angefordert, der code angefordert hat code oder von einem anderen?".

OAuth 2.0 CSRF

OAuth 2.0 CSRF ist relativ harmlos, wenn OAuth 2.0 für die Autorisierung verwendet wird. Ganz anders sieht es aus, wenn OAuth 2.0 zur Authentifizierung verwendet wird. In diesem Fall führt OAuth 2.0 CSRF häufig zu einer Kontoübernahme.

Lassen Sie uns am Beispiel des Taxi-App-Clients und des Anbieters von provider.com mehr über den CSRF-Angriff gemäß OAuth 2.0 sprechen. Zunächst meldet sich ein Angreifer auf seinem eigenen Gerät bei attacker@provider.com an und erhält den code für das Taxi. Dann unterbricht er den OAuth 2.0-Prozess und generiert einen Link:

 com.taxi.app://oauth? code=b57b236c9bcd2a61fcd627b69ae2d7a6eb5bc13f2dc25311348ee08df43bc0c4

Dann sendet der Angreifer diesen Link an sein Opfer, beispielsweise in Form einer Mail oder einer Textnachricht von Taxis. Das Opfer klickt auf den Link, die Taxi-App wird geöffnet und erhält access_token . Infolgedessen befinden sie sich auf dem Taxikonto des Angreifers . Das Opfer ist sich dessen nicht bewusst und verwendet dieses Konto: Reisen, persönliche Daten eingeben usw.

Jetzt kann sich der Angreifer jederzeit in das Taxikonto des Opfers einloggen, da es mit attacker@provider.com verknüpft ist. Durch einen CSRF-Anmeldeangriff konnte der Übertreter ein Konto stehlen.

CSRF-Angriffe werden normalerweise mit einem CSRF-Token (auch als state ) zurückgewiesen, und OAuth 2.0 ist keine Ausnahme. So verwenden Sie das CSRF-Token:

Die Clientanwendung generiert und speichert CSRF-Token auf dem mobilen Gerät eines Clients.
Die Clientanwendung enthält das CSRF-Token in der Codezugriffsanforderung.
Der Server gibt dasselbe CSRF-Token mit code in seiner Antwort zurück.
Die Clientanwendung vergleicht die eingehenden und gespeicherten CSRF-Token. Wenn ihre Werte übereinstimmen, wird der Prozess fortgesetzt.

CSRF-Token-Anforderungen: Nonce muss mindestens 256 Bit groß sein und von einer guten Quelle pseudozufälliger Sequenzen empfangen werden.

access_token gesagt, mit dem CSRF-Token kann ein Anwendungsclient die folgende Frage beantworten: "War das ich, der die Anforderung access_token initiiert access_token oder versucht jemand, mich access_token ?".

Hardcodiertes Kundengeheimnis

Mobile Anwendungen ohne Backend speichern manchmal client_id client_secret Werte für client_id und client_secret . Natürlich können sie einfach per Reverse Engineering App extrahiert werden.

Die Auswirkung der Offenlegung von client_id und client_secret hängt stark davon ab, wie viel Vertrauensdienstanbieter auf das bestimmte Paar client_id , client_secret legt. Man verwendet sie nur, um einen Client von einem anderen zu unterscheiden, während andere versteckte API-Endpunkte öffnen oder für einige Clients niedrigere Ratenbeschränkungen festlegen.

In dem Artikel Warum OAuth-API-Schlüssel und -Sekrete in mobilen Apps nicht sicher sind, wird dieses Thema ausführlicher behandelt.

Schädliche App als legitimer Client

Einige böswillige Apps können die legitimen Apps imitieren und in ihrem Namen einen Zustimmungsbildschirm anzeigen (ein Zustimmungsbildschirm ist ein Bildschirm, auf dem ein Benutzer Folgendes sieht: "Ich bin damit einverstanden, Zugriff auf ... zu gewähren"). Der Benutzer kann auf "Zulassen" klicken und der bösartigen App seine Daten zur Verfügung stellen.

Android und iOS bieten die Mechanismen für die Gegenprüfung von Anwendungen. Ein Anwendungsanbieter kann sicherstellen, dass eine Clientanwendung legitim ist und umgekehrt.

Wenn der OAuth 2.0-Mechanismus einen Thread über einen Browser verwendet, ist es leider unmöglich, sich gegen diesen Angriff zu verteidigen.

Andere Angriffe

Wir haben uns die Angriffe genauer angesehen, die nur für mobile OAuth 2.0 gelten. Vergessen wir jedoch nicht die ursprüngliche OAuth 2.0: Ersetzung von redirect_uri , Abfangen des Datenverkehrs über eine unsichere Verbindung usw. Hier können Sie mehr darüber lesen.

Wie geht das sicher?

Wir haben erfahren, wie das OAuth 2.0-Protokoll funktioniert und welche Schwachstellen es auf Mobilgeräten aufweist. Lassen Sie uns nun die einzelnen Teile zusammenfügen, um ein sicheres mobiles OAuth 2.0-Schema zu erhalten.

Gute, schlechte OAuth 2.0

Beginnen wir mit der richtigen Verwendung des Einwilligungsbildschirms. Mobile Geräte haben zwei Möglichkeiten, eine Webseite in einer mobilen Anwendung zu öffnen.

Der erste Weg führt über die benutzerdefinierte Registerkarte "Browser" (links im Bild). Hinweis : Die benutzerdefinierte Registerkarte "Browser" für Android heißt "Chrome Custom Tab" und für iOS - SafariViewController. Es ist nur eine Browser-Registerkarte, die in der App angezeigt wird: Es gibt keinen visuellen Wechsel zwischen den Anwendungen.

Der zweite Weg führt über WebView (rechts im Bild) und ich halte es für schlecht in Bezug auf das mobile OAuth 2.0.

WebView ist ein eingebetteter Browser für eine mobile App.

" Eingebetteter Browser " bedeutet, dass der Zugriff auf Cookies, Speicher, Cache, Verlauf und andere Safari- und Chrome-Daten für WebView verboten ist. Das Gegenteil ist auch richtig: Safari und Chrome können nicht auf WebView-Daten zugreifen.

" Browser für mobile Apps" bedeutet, dass eine mobile App, auf der WebView ausgeführt wird, vollen Zugriff auf Cookies, Speicher, Cache, Verlauf und andere WebView-Daten hat.

Stellen Sie sich nun vor: Ein Benutzer klickt auf "Enter with ..." und ein WebView einer bösartigen App fordert seinen Login und sein Passwort vom Dienstanbieter an.

Epischer Fehler:

Der Benutzer gibt sein Login und Passwort für das Konto des Dienstanbieters in die App ein, mit dem diese Daten leicht gestohlen werden können.
OAuth 2.0 wurde ursprünglich entwickelt, um die Anmeldung und das Kennwort des Dienstanbieters nicht einzugeben.

Der Benutzer gewöhnt sich daran, sein Login und Passwort überall einzugeben, was die Angelmöglichkeiten erhöht.

In Anbetracht aller Nachteile von WebView bietet sich eine offensichtliche Schlussfolgerung an: Verwenden Sie die benutzerdefinierte Registerkarte Browser für den Zustimmungsbildschirm.

Wenn jemand Argumente für WebView anstelle von Browser Custom Tab hat, würde ich mich freuen, wenn Sie darüber in den Kommentaren schreiben.

Sicheres mobiles OAuth 2.0-Schema

Wir werden das Authorization Code Grant-Schema verwenden, da es uns ermöglicht, code_challenge hinzuzufügen sowie einen Code-Interception-Angriff und OAuth 2.0 CSRF code_challenge und zu verteidigen.

Bildursprung: https://tools.ietf.org/html/rfc8252#section-4.1

Die Codezugriffsanforderung (Schritte 1-2) sieht wie folgt aus:

 https://o2.mail.ru/code? redirect_uri=com.mail.cloud.app%3A%2F%2Foauth& state=927489cb2fcdb32e302713f6a720397868b71dd2128c734181983f367d622c24& code_challenge=ZjYxNzQ4ZjI4YjdkNWRmZjg4MWQ1N2FkZjQzNGVkODE1YTRhNjViNjJjMGY5MGJjNzdiOGEzMDU2ZjE3NGFiYw%3D%3D& code_challenge_method=S256& scope=email%2Cid& response_type=code& client_id=984a644ec3b56d32b0404777e1eb73390c 3D% 3D & https://o2.mail.ru/code? redirect_uri=com.mail.cloud.app%3A%2F%2Foauth& state=927489cb2fcdb32e302713f6a720397868b71dd2128c734181983f367d622c24& code_challenge=ZjYxNzQ4ZjI4YjdkNWRmZjg4MWQ1N2FkZjQzNGVkODE1YTRhNjViNjJjMGY5MGJjNzdiOGEzMDU2ZjE3NGFiYw%3D%3D& code_challenge_method=S256& scope=email%2Cid& response_type=code& client_id=984a644ec3b56d32b0404777e1eb73390c

In Schritt 3 erhält der Browser eine Antwort mit Umleitung:

 com.mail.cloud.app://outh? code=b57b236c9bcd2a61fcd627b69ae2d7a6eb5bc13f2dc25311348ee08df43bc0c4& state=927489cb2fcdb32e302713f6a720397868b71dd2128c734181983f367d622c24

In Schritt 4 öffnet der Browser das benutzerdefinierte URI-Schema und übergibt das CSRF-Token an eine Client-App.
access_token Anforderung (Schritt 5):

 https://o2.mail.ru/token? code_verifier=e61748f28b7d5daf881d571df434ed815a4a65b62c0f90bc77b8a3056f174abc& code=b57b236c9bcd2a61fcd627b69ae2d7a6eb5bc13f2dc25311348ee08df43bc0c4& client_id=984a644ec3b56d32b0404777e1eb73390c

Der letzte Schritt bringt eine Antwort mit access_token .

Dieses Schema ist im Allgemeinen sicher, aber es gibt einige Sonderfälle, in denen OAuth 2.0 einfacher und sicherer sein kann.

Android IPC

Android verfügt über einen Mechanismus zur bidirektionalen Datenkommunikation zwischen Prozessen: IPC (Inter-Process Communication). IPC ist aus zwei Gründen besser als das benutzerdefinierte URI-Schema:

Eine App, die den IPC-Kanal öffnet, kann die Authentizität einer App, die sie öffnet, anhand ihres Zertifikats bestätigen. Das Gegenteil ist auch der Fall: Die geöffnete App kann die Authentizität der App bestätigen, die sie geöffnet hat.
Wenn ein Absender eine Anfrage über den IPC-Kanal sendet, kann er eine Antwort über denselben Kanal empfangen. Zusammen mit der Gegenprüfung (Punkt 1) bedeutet dies, dass kein fremder Prozess access_token abfangen access_token .

Daher können wir Implicit Grant verwenden , um das mobile OAuth 2.0-Schema zu vereinfachen. Keine code_challenge und kein code_challenge bedeuten auch weniger Angriffsfläche. Wir können auch das Risiko verringern, dass sich böswillige Apps wie legitime Kunden verhalten, die versuchen, die Benutzerkonten zu stehlen.

SDK für Kunden

Neben der Implementierung dieses sicheren mobilen OAuth 2.0-Schemas sollte ein Anbieter ein SDK für seine Kunden entwickeln. Dies vereinfacht die Implementierung von OAuth 2.0 auf Clientseite und reduziert gleichzeitig die Anzahl der Fehler und Schwachstellen.

Schlussfolgerungen

Lassen Sie es mich für Sie zusammenfassen. Hier ist die (grundlegende) Checkliste für sicheres OAuth 2.0 für OAuth 2.0-Anbieter:

Ein starkes Fundament ist entscheidend. Im Fall von mobilem OAuth 2.0 ist die Grundlage ein Schema oder ein Protokoll, das für die Implementierung ausgewählt wurde. Es ist leicht, Fehler zu machen, während Sie Ihr eigenes OAuth 2.0-Schema implementieren . Andere haben bereits geklopft und ihre Lektion gelernt; Es ist nichts Falsches daran, aus ihren Fehlern zu lernen und eine sichere Implementierung auf einmal durchzuführen. Das sicherste mobile OAuth 2.0-Schema wird unter Wie wird es sicher durchgeführt ? Beschrieben.
Access_token und andere vertrauliche Daten müssen in Keychain für iOS und in Internal Storage für Android gespeichert werden. Diese Speicher wurden speziell dafür entwickelt. Der Inhaltsanbieter kann in Android verwendet werden, muss jedoch sicher konfiguriert sein.
Client_secret ist nutzlos , es sei denn, es wird im Backend gespeichert. Geben Sie es nicht an öffentliche Kunden weiter.
Verwenden Sie WebView nicht für den Zustimmungsbildschirm. Verwenden Sie die benutzerdefinierte Registerkarte des Browsers.
Verwenden Sie code_challenge um sich gegen Code-Interception-Angriffe zu verteidigen.
Verwenden Sie state um sich gegen OAuth 2.0 CSRF zu verteidigen.
Verwenden Sie HTTPS überall , wobei ein Downgrade auf HTTP verboten ist. Hier ist eine 3-minütige Demo, die erklärt, warum (mit einem Beispiel aus einer Bug Bounty).
Befolgen Sie die Kryptografiestandards (Auswahl des Algorithmus, Länge der Token usw.). Sie können die Daten kopieren und herausfinden, warum dies so gemacht wird, aber keine eigene Krypto rollen.
Code darf nur einmal verwendet werden, mit einer kurzen Lebensdauer.
Überprüfen Sie auf der Seite eines App-Clients, was Sie für OAuth 2.0 öffnen. Überprüfen Sie auf der Seite eines App-Anbieters, wer Sie für OAuth 2.0 öffnet.
Beachten Sie die allgemeinen OAuth 2.0-Schwachstellen . Mobile OAuth 2.0 vergrößert und vervollständigt das Original. Daher ist redirect_uri Überprüfung von redirect_uri auf eine genaue Übereinstimmung und andere Empfehlungen für das Original OAuth 2.0 noch in Kraft.
Sie sollten Ihren Kunden das SDK zur Verfügung stellen. Sie haben weniger Fehler und Schwachstellen und es wird für sie einfacher sein, OAuth 2.0 zu implementieren.

Weiterführende Literatur

"Sicherheitslücken von Mobile OAuth 2.0" https://www.youtube.com/watch?v=vjCF_O6aZIg
OAuth 2.0 Race Condition Research https://hackerone.com/reports/55140
Fast alles über OAuth 2.0 an einem Ort https://oauth.net/2/
Warum OAuth-API-Schlüssel und -Sekrete in mobilen Apps nicht sicher sind https://developer.okta.com/blog/2019/01/22/oauth-api-keys-arent-safe-in-mobile-apps
[RFC] OAuth 2.0 für native Apps https://tools.ietf.org/html/rfc8252
[RFC] Proof-Schlüssel für den Code-Austausch durch öffentliche OAuth-Clients https://tools.ietf.org/html/rfc7636
[RFC] Überlegungen zum OAuth 2.0-Bedrohungsmodell und zur Sicherheit https://tools.ietf.org/html/rfc6819
[RFC] OAuth 2.0 Dynamic Client Registration Protocol https://tools.ietf.org/html/rfc7591
Google OAuth 2.0 für mobile und Desktop-Apps https://developers.google.com/identity/protocols/OAuth2InstalledApp

Credits

Vielen Dank an alle, die mir geholfen haben, diesen Artikel zu schreiben. Insbesondere an Sergei Belov, Andrei Sumin, Andrey Labunets für das Feedback zu technischen Details, an Pavel Kruglov für die englische Übersetzung und an Daria Yakovleva für die Hilfe bei der Veröffentlichung der russischen Version dieses Artikels.

Sicherheit von mobilem OAuth 2.0