Hallo allerseits! Ich bin Nikita Stupin, Informationssicherheitsspezialist, Mail.Ru Mail. Vor nicht allzu langer Zeit habe ich eine Schwachstellenforschung für mobiles OAuth 2.0 durchgeführt. Um ein sicheres mobiles OAuth 2.0-Schema zu erstellen, reicht es nicht aus, den Standard in seiner reinen Form zu implementieren und redirect_uri zu überprüfen. Es ist notwendig, die Besonderheiten mobiler Anwendungen zu berücksichtigen und zusätzliche Schutzmechanismen anzuwenden.

In diesem Artikel möchte ich Ihnen Wissen über Angriffe auf mobile OAuth 2.0, über Schutzmethoden und die sichere Implementierung dieses Protokolls mitteilen. Alle erforderlichen Schutzkomponenten, auf die ich weiter unten eingehen werde, sind im neuesten SDK für die mobilen Mail.Ru Mail-Clients implementiert.

Die Art und Funktion von OAuth 2.0

OAuth 2.0 ist ein Autorisierungsprotokoll, das beschreibt, wie sicher ein Clientdienst auf Benutzerressourcen eines Dienstanbieters zugreifen kann. Gleichzeitig erspart OAuth 2.0 dem Benutzer die Eingabe eines Kennworts außerhalb des Dienstanbieters: Der gesamte Vorgang wird auf das Klicken auf die Schaltfläche "Ich stimme zu, Zugriff zu gewähren ..." reduziert.

Ein Anbieter im Sinne von OAuth 2.0 ist ein Dienst, der Benutzerdaten besitzt und mit Erlaubnis des Benutzers Diensten (Clients) von Drittanbietern einen sicheren Zugriff auf diese Daten bietet. Ein Client ist eine Anwendung, die Benutzerdaten von einem Anbieter empfangen möchte.

Einige Zeit nach der Veröffentlichung des OAuth 2.0-Protokolls haben gewöhnliche Entwickler es für die Authentifizierung angepasst, obwohl es ursprünglich nicht dafür vorgesehen war. Durch die Authentifizierung wird der Angriffsvektor von Benutzerdaten, die beim Dienstanbieter gespeichert sind, auf Benutzerkonten für Benutzerdienste verschoben.

Es war nicht nur auf die Authentifizierung beschränkt. Im Zeitalter der mobilen Apps und der zunehmenden Konvertierung ist das Aufrufen der App mit einer einzigen Schaltfläche sehr verlockend geworden. Die Entwickler setzen OAuth 2.0 auf mobile Schienen. Natürlich haben nur wenige Menschen über die Sicherheit und Besonderheiten mobiler Anwendungen nachgedacht: immer wieder und in der Produktion. OAuth 2.0 funktioniert jedoch im Allgemeinen nicht gut außerhalb von Webanwendungen: Die gleichen Probleme treten sowohl bei mobilen als auch bei Desktopanwendungen auf.

Lassen Sie uns herausfinden, wie Sie ein sicheres mobiles OAuth 2.0 erstellen.

Wie funktioniert es

Denken Sie daran, dass der Client auf Mobilgeräten möglicherweise kein Browser ist, sondern eine mobile Anwendung ohne Backend. Daher stehen wir vor zwei großen Sicherheitsproblemen für mobile OAuth 2.0:

Dem Client wird nicht vertraut.
Das Verhalten einer Umleitung von einem Browser zu einer mobilen Anwendung hängt von den Einstellungen und Anwendungen ab, die der Benutzer installiert hat.

Mobile Anwendung ist ein öffentlicher Client

Um die Wurzel 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 damit, dass sich der Service-Client beim Service-Provider registriert und client_id und in einigen Fällen client_secret . Der Wert client_id ist öffentlich und wird im Gegensatz zu client_secret , dessen Wert privat ist, zur Identifizierung des client_secret . Der Registrierungsprozess wird in RFC 7591 ausführlicher beschrieben .

Das folgende Diagramm zeigt den Betrieb von OAuth 2.0 bei der Server-zu-Server-Kommunikation.

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

Es gibt 3 Hauptstufen des OAuth 2.0-Protokolls:

[AC-Schritte] Holen Sie sich den Autorisierungscode (im Folgenden einfach code ).
[DE-Schritte] Austauschcode für access_token .
access_token mit access_token die Ressource zu.

Wir werden den Erhalt des Codes genauer analysieren:

[Schritt A] Der Service-Client leitet den Benutzer zum Service-Provider weiter.
[Schritt B] Der Dienstanbieter fordert vom Benutzer die Erlaubnis an, Daten für den Clientdienst bereitzustellen (Pfeil B nach oben). Der Benutzer bietet Zugriff auf die Daten (Pfeil B rechts).
[Schritt C] Der Dienstanbieter gibt den code an den Browser des Benutzers zurück, der den code den Clientdienst umleitet.

access_token wir access_token genauer an:

[Schritt D] Der Client-Server sendet eine Anforderung für access_token . Die Anfrage enthält: code , client_secret und redirect_uri .
[Schritt E] Bei gültigem code , client_secret und redirect_uri , wird client_secret bereitgestellt.

Die Anforderung für access_token wird gemäß dem Server-zu-Server-Schema ausgeführt. Um client_secret zu stehlen client_secret muss client_secret Angreifer im Allgemeinen den Server-Client-Server oder den Server des Dienstanbieters hacken.

Lassen Sie uns nun sehen, wie das OAuth 2.0-Schema auf einem mobilen Gerät ohne Backend aussieht (Client-Server-Interaktion).

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

Das allgemeine Schema ist in die gleichen drei Hauptschritte unterteilt:

[Schritte 1-4 im Bild] Holen Sie sich den code .
[Schritte 5-6 im Bild] Austauschcode für access_token .
access_token mit access_token die Ressource zu.

In diesem Fall fungiert die mobile Anwendung jedoch auch als Server, was bedeutet, dass client_secret innerhalb der Anwendung client_secret wird. Dies führt dazu, dass es auf mobilen Geräten unmöglich ist, lient_secret vor einem Angreifer geheim zu halten. client_secret gibt zwei Möglichkeiten, client_secret mit der Anwendung zu verbinden: Filtern des Datenverkehrs von der Anwendung zum Server oder Reverse Engineering der Anwendung. Beide Methoden sind einfach zu implementieren, sodass client_secret auf Mobilgeräten unbrauchbar client_secret .

In Bezug auf das Client-zu-Server-Schema haben Sie möglicherweise die Frage: "Warum nicht sofort access_token ?". Es scheint, warum brauchen wir einen zusätzlichen Schritt? Darüber hinaus gibt es ein implizites Grant- Schema, bei dem der Client sofort ein access_token erhält. Obwohl es in einigen Fällen verwendet werden kann, werden wir unten sehen, dass Implicit Grant nicht für sicheres mobiles OAuth 2.0 geeignet ist.

Weiterleitung auf Mobilgeräten

Im Allgemeinen werden für eine Umleitung von einem Browser zu einer Anwendung auf Mobilgeräten das benutzerdefinierte URI-Schema und die AppLink- Mechanismen verwendet. Keiner dieser Mechanismen in seiner reinen Form ist so zuverlässig wie eine Browserumleitung.

Das benutzerdefinierte URI-Schema (oder Deep Link) wird wie folgt verwendet: Der Entwickler definiert das Anwendungsschema vor dem Zusammenbau. Das Schema kann beliebig sein, während auf demselben Gerät mehrere Anwendungen mit demselben Schema installiert werden können. Alles ist ganz einfach, wenn jede Anwendung auf dem Gerät einer Anwendung entspricht. Was aber, wenn zwei Anwendungen dieselbe Schaltung auf demselben Gerät registriert haben? Wie kann das Betriebssystem bestimmen, welche der beiden Anwendungen beim Zugriff auf das benutzerdefinierte URI-Schema geöffnet werden soll? Android zeigt ein Fenster mit der Auswahl der Anwendung an, in der Sie einen Link öffnen möchten. In iOS ist das Verhalten nicht definiert , was bedeutet, dass eine der beiden Anwendungen geöffnet werden kann. In beiden Fällen kann ein Angreifer Code oder access_token abfangen .

Im Gegensatz zum benutzerdefinierten URI-Schema wird AppLink garantiert die richtige Anwendung öffnen. Dieser Mechanismus weist jedoch mehrere Nachteile auf:

Jeder Service-Client muss das Überprüfungsverfahren unabhängig bestehen.
Android-Benutzer können AppLink für eine bestimmte Anwendung in den Einstellungen deaktivieren.
Android unter 6.0 und iOS unter 9.0 unterstützen AppLink nicht.

Die oben genannten Nachteile von AppLink erhöhen zum einen die Eintrittsschwelle für potenzielle Client-Dienste und zum anderen können sie dazu führen, dass der Benutzer unter bestimmten Umständen nicht mit OAuth 2.0 arbeitet. Dies macht AppLink ungeeignet zum Ersetzen von Browserumleitungen im OAuth 2.0-Protokoll.

Okay, was soll ich angreifen?

Die Probleme des mobilen OAuth 2.0 führten auch zu spezifischen Angriffen. Mal sehen, was sie sind und wie sie funktionieren.

Abfangangriff auf Autorisierungscode

Anfangsdaten: Auf dem Gerät des Benutzers sind eine legitime Anwendung (OAuth 2.0-Client) und eine schädliche Anwendung installiert, die dasselbe Schema wie die legitime registriert haben. Die folgende Abbildung zeigt das Angriffsschema.

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

Hier ist das Problem: In Schritt 4 gibt der Browser über das benutzerdefinierte URI-Schema code an die Anwendung zurück, sodass der code von der Malware abgefangen werden kann (da er dasselbe Schema wie die legitime Anwendung registriert hat). Danach ändert die Malware den code in access_token und erhält Zugriff auf Benutzerdaten.

Wie können Sie sich schützen? In einigen Fällen können Interprozess-Kommunikationsmechanismen verwendet werden, auf die wir weiter unten eingehen werden. Im allgemeinen Fall müssen Sie ein Schema namens Proof Key für Code Exchange anwenden. Sein Wesen spiegelt sich in der folgenden Abbildung wider.

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

In Anforderungen vom Client gibt es mehrere zusätzliche Parameter: code_verifier , code_challenge (im t(code_verifier) ) und code_challenge_method (im code_challenge_method Diagramm).

Code_verifier ist eine Zufallszahl von mindestens 256 Bit Länge , die nur einmal verwendet wird . Das heißt, für jede code_verifier muss code Client einen neuen code_verifier generieren.

Code_challenge_method ist der Name einer Konvertierungsfunktion, meistens SHA-256.

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

Die Konvertierung von code_verifier in code_challenge erforderlich, um sich vor Angriffsvektoren zu schützen, die auf dem Abfangen von code_verifier (z. B. aus den Systemprotokollen des Geräts) beim Anfordern von code basieren.

Wenn das Gerät des Benutzers SHA-256 nicht unterstützt , ist ein Downgrade zulässig, bis die Konvertierung von code_verifier fehlt . In allen anderen Fällen müssen Sie SHA-256 verwenden.

Das Schema funktioniert wie folgt:

Der Client generiert einen code_verifier und merkt sich diesen.
Der Client wählt code_challenge_method und erhält 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 merkt sich die code_challenge und code_challenge_method auf dem Server und gibt den code Client zurück.
[Schritt C] Der Client fordert access_token , wobei access_token zur code_verifier hinzugefügt wird.
Der Anbieter empfängt die code_challenge vom eingehenden code_verifier und vergleicht sie dann mit der code_challenge , an die er sich erinnert hat.
[Schritt D] Wenn die Werte übereinstimmen, gibt der Anbieter ein access_token Client aus.

Mal code_challenge warum code_challenge mit code_challenge vor einem Code-Interception-Angriff schützen können. Zu diesem access_token wir die Phasen des Erhaltens von access_token .

Zunächst wird ein legitimer Anwendungsanforderungscode ( code_challenge und code_challenge_method zusammen mit der Anforderung gesendet).
Die Malware fängt code (aber nicht code_challenge , da die Antwort keine code_challenge ).
Die Malware fordert access_token (mit gültigem code , jedoch ohne gültigen code_verifier ).
Der Server bemerkt die code_challenge und gibt einen Fehler aus.

Beachten Sie, dass der Angreifer nicht in der Lage ist, den code_verifier zu erraten (zufällige 256 Bit!) Oder ihn irgendwo in den Protokollen zu finden ( code_verifier wird einmal übertragen).

Wenn dies alles auf eine Phrase reduziert ist, kann der Dienstanbieter mit code_challenge die Frage beantworten: " access_token von derselben Clientanwendung angefordert, die code angefordert code , oder von einer anderen?".

OAuth 2.0 CSRF

Auf Mobilgeräten wird OAuth 2.0 häufig als Authentifizierungsmechanismus verwendet. Wie wir uns erinnern, unterscheidet sich die Authentifizierung über OAuth 2.0 von der Autorisierung darin, dass OAuth 2.0-Schwachstellen Benutzerdaten auf der Seite des Service-Clients und nicht des Service-Providers betreffen. Infolgedessen können Sie mit dem CSRF-Angriff auf OAuth 2.0 das Konto eines anderen stehlen.

Betrachten Sie einen CSRF-Angriff gegen OAuth 2.0 am Beispiel der Taxi-Client-Anwendung und des Provider.com-Providers. Zunächst meldet sich ein Angreifer auf seinem Gerät bei attacker@provider.com an und erhält einen code für das Taxi. Danach unterbricht der Angreifer den OAuth 2.0-Prozess und generiert eine Verknüpfung:

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

Dann sendet der Angreifer einen Link zum Opfer, beispielsweise unter dem Deckmantel eines Briefes oder einer SMS der Taxiverwaltung. Das Opfer access_token Link, eine Taxi-Anwendung wird auf seinem Telefon geöffnet, die access_token empfängt, und das Opfer landet auf dem access_token des Angreifers . Das Opfer ist sich des Fangs nicht bewusst und verwendet dieses Konto: macht Reisen, gibt seine Daten ein usw.

Jetzt kann sich ein Angreifer jederzeit in das Taxikonto des Opfers einloggen, da er an attacker@provider.com gebunden ist. CSRF-Angriff auf die Anmeldung erlaubt, ein Konto zu stehlen.

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

Die Clientanwendung generiert und speichert das CSRF-Token auf dem mobilen Gerät des Benutzers.
Die Clientanwendung enthält das CSRF-Token in der Codeanforderung.
Der Server gibt das gleiche CSRF-Token in der Antwort zusammen mit dem Code zurück.
Die Clientanwendung vergleicht das eingehende und das gespeicherte CSRF-Token. Wenn die Werte übereinstimmen, wird der Prozess fortgesetzt.

CSRF-Token-Anforderungen: Nonce mindestens 256 Bit lang, erhalten aus einer guten Quelle von Pseudozufallssequenzen.

Kurz gesagt, mit dem CSRF-Token kann die Clientanwendung die Frage beantworten: " access_token ich angefangen, access_token zu erhalten, oder versucht mich jemand access_token ?"

Malware, die vorgibt, ein legitimer Client zu sein

Einige Malware kann legitime Anwendungen imitieren und in ihrem Namen einen Zustimmungsbildschirm auslösen (der Zustimmungsbildschirm ist ein Bildschirm, auf dem der Benutzer Folgendes sieht: "Ich bin damit einverstanden, Zugriff auf ... zu gewähren"). Unaufmerksame Benutzer können auf "Zulassen" klicken. Dadurch erhält die Malware Zugriff auf Benutzerdaten.

Android und iOS bieten Mechanismen zur gegenseitigen Überprüfung von Anwendungen. Die Anbieteranwendung kann die Legitimität der Clientanwendung überprüfen und umgekehrt.

Wenn der OAuth 2.0-Mechanismus einen Stream über einen Browser verwendet, können Sie sich leider nicht gegen diesen Angriff verteidigen.

Andere Angriffe

Wir haben die Angriffe untersucht, die nur für mobile OAuth 2.0 gelten. Vergessen Sie jedoch nicht die Angriffe auf reguläres OAuth 2.0: redirect_uri Spoofing, Abfangen des Datenverkehrs über eine unsichere Verbindung usw. Mehr darüber können Sie hier lesen.

Was tun?

Wir haben gelernt, wie das OAuth 2.0-Protokoll funktioniert, und herausgefunden, welche Schwachstellen in den Implementierungen dieses Protokolls auf Mobilgeräten vorhanden sind. Lassen Sie uns nun ein sicheres mobiles OAuth 2.0-Schema aus einzelnen Teilen zusammenstellen.

Gute, schlechte OAuth 2.0

Beginnen wir mit dem richtigen Aufrufen des Zustimmungsbildschirms. Auf Mobilgeräten gibt es zwei Möglichkeiten, eine Webseite aus einer nativen Anwendung heraus zu öffnen (Beispiele für native Anwendungen: Mail.Ru Mail, VK, Facebook).

Die erste Methode heißt Browser Custom Tab (im Bild links). Hinweis : Die benutzerdefinierte Registerkarte "Browser" unter Android heißt "Chrome Custom Tab" und unter iOS SafariViewController. Tatsächlich ist dies eine normale Browser-Registerkarte, die direkt in der Anwendung angezeigt wird, d. H. Es gibt kein visuelles Umschalten zwischen Anwendungen.

Die zweite Methode heißt "Raise WebView" (im Bild rechts). In Bezug auf mobile OAuth 2.0 halte ich sie für schlecht.

WebView ist ein eigenständiger Browser für eine native Anwendung.

Ein "eigenständiger Browser " bedeutet, dass WebView keinen Zugriff auf Cookies, Speicher, Cache, Verlauf und andere Daten von Safari- und Chrome-Browsern zulässt. Das Gegenteil ist auch der Fall: Safari und Chrome können nicht auf WebView-Daten zugreifen.

" Browser für eine native Anwendung " bedeutet, dass die native Anwendung, die WebView ausgelöst hat, vollen Zugriff auf Cookies, Speicher, Cache, Verlauf und andere WebView-Daten hat.

Stellen Sie sich nun vor: Der Benutzer drückt auf die Schaltfläche "Anmelden mit ..." und das WebView der bösartigen Anwendung fragt den Dienstanbieter nach seinem Benutzernamen und Passwort.

Fehler an allen Fronten sofort:

Der Benutzer gibt den Benutzernamen und das Kennwort über das Konto des Dienstanbieters in der Anwendung ein, wodurch diese Daten leicht gestohlen werden können.
OAuth 2.0 wurde ursprünglich entwickelt , um keinen Benutzernamen und kein Passwort von einem Dienstanbieter einzugeben .
Der Benutzer gewöhnt sich daran, das Login und das Passwort überall einzugeben, die Wahrscheinlichkeit von Phishing steigt.

Angesichts der Tatsache, dass alle Argumente gegen WebView sprechen, bietet sich die Schlussfolgerung an: Öffnen Sie die Registerkarte Benutzerdefiniert für die Einwilligung des Browsers.

Wenn einer von Ihnen Argumente für WebView anstelle von Browser Custom Tab hat, schreiben Sie darüber in den Kommentaren, ich werde sehr dankbar sein.

Sicheres mobiles OAuth 2.0-Schema

Wir werden das Authorization Code Grant-Schema verwenden, da es uns ermöglicht, eine code_challenge hinzuzufügen und code_challenge vor einem Code-Interception-Angriff zu schützen.

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

Die Codeanforderung (Schritte 1-2) sieht folgendermaßen aus:

https://o2.mail.ru/code?
redirect_uri=com.mail.cloud.app%3A%2F%2Foauth&
anti_csrf=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 umgeleitete Antwort:

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

In Schritt 4 öffnet der Browser das benutzerdefinierte URI-Schema und übergibt den code und das CSRF-Token an die Clientanwendung.

Anfrage für access_token (Schritt 5):

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

Der letzte Schritt gibt eine Antwort mit access_token .

Im Allgemeinen ist das obige Schema sicher, aber es gibt auch Sonderfälle, in denen OAuth 2.0 einfacher und ein wenig sicherer gemacht werden kann.

Android IPC

Android verfügt über einen Mechanismus für den bidirektionalen Datenaustausch zwischen Prozessen: IPC (Inter-Process Communication). IPC wird aus zwei Gründen dem benutzerdefinierten URI-Schema vorgezogen:

Eine Anwendung, die einen IPC-Kanal öffnet, kann die Authentizität einer geöffneten Anwendung anhand ihres Zertifikats überprüfen. Das Gegenteil ist auch der Fall: Eine geöffnete Anwendung kann die Authentizität der Anwendung überprüfen, die sie geöffnet hat.
Durch Senden einer Anfrage über einen IPC-Kanal kann der Absender eine Antwort über denselben Kanal empfangen. Zusammen mit der gegenseitigen Überprüfung (Punkt 1) bedeutet dies, dass kein Prozess eines access_token abfangen access_token .

Somit können wir den impliziten Zuschuss verwenden und das mobile OAuth 2.0-Schema erheblich vereinfachen. Keine code_challenge und CSRF-Token. Darüber hinaus können wir uns vor Malware schützen, die legitime Kunden nachahmt, um Benutzerkonten zu stehlen.

Kunden-SDK

Zusätzlich zur Implementierung des oben beschriebenen sicheren mobilen OAuth 2.0-Schemas sollte der Anbieter ein SDK für seine Kunden entwickeln. Dies erleichtert die Implementierung von OAuth 2.0 auf der Clientseite und reduziert gleichzeitig die Anzahl der Fehler und Schwachstellen.

Schlussfolgerungen ziehen

Für OAuth 2.0-Anbieter habe ich die „Secure Mobile OAuth 2.0-Checkliste“ zusammengestellt:

Ein solides Fundament ist entscheidend. Im Fall von mobilem OAuth 2.0 ist die Grundlage das Schema oder Protokoll, das wir implementieren möchten. Wenn Sie Ihr eigenes OAuth 2.0-Schema implementieren, können Sie leicht einen Fehler machen. Andere haben die Unebenheiten bereits aufgefüllt und Schlussfolgerungen gezogen. Es ist nichts Falsches daran, aus ihren Fehlern zu lernen und sofort eine sichere Implementierung vorzunehmen. Im Allgemeinen ist das sicherste mobile OAuth 2.0-Schema das im Abschnitt "Was ist zu tun?".
Access_token und andere vertrauliche Daten: unter iOS - im Schlüsselbund, unter Android - im internen Speicher. Diese Repositorys wurden speziell für solche Zwecke entwickelt. Bei Bedarf können Sie den Inhaltsanbieter in Android verwenden, er muss jedoch sicher konfiguriert sein.
Code sollte einmalig sein und eine kurze Lebensdauer haben.
Verwenden code_challenge zum Schutz vor dem Abfangen von Code code_challenge .
Verwenden Sie CSRF-Token, um sich vor einem CSRF-Angriff auf die Anmeldung zu schützen.
Verwenden Sie WebView nicht für den Einwilligungsbildschirm, sondern verwenden Sie die benutzerdefinierte Registerkarte "Browser".
Client_secret nutzlos, wenn es nicht im Backend gespeichert ist. Geben Sie es nicht an öffentliche Kunden weiter.
Verwenden Sie HTTPS überall , mit dem Verbot eines Downgrades auf HTTP.
Befolgen Sie die Kryptografieempfehlungen (Verschlüsselungsauswahl, Tokenlänge usw.) aus den Standards . Sie können die Daten kopieren und herausfinden, warum dies so gemacht wurde, aber Sie können Ihre Kryptografie nicht durchführen .
Überprüfen Sie in der Clientanwendung, wen Sie für OAuth 2.0 öffnen, und in der Anbieteranwendung, wer Sie für OAuth 2.0 öffnet.
Beachten Sie die üblichen OAuth 2.0-Schwachstellen . Mobile OAuth 2.0 erweitert und ergänzt das reguläre OAuth 2.0, sodass niemand die Überprüfung von redirect_uri auf genaue Übereinstimmungen und andere Empfehlungen für reguläres OAuth 2.0 abgebrochen hat.
Stellen Sie sicher, dass Sie den Kunden SDKs zur Verfügung stellen. Der Client hat weniger Fehler und Schwachstellen im Code, und es ist für ihn einfacher, OAuth 2.0 zu implementieren.

Was zu lesen

[RFC] OAuth 2.0 für native Apps https://tools.ietf.org/html/rfc8252
Google OAuth 2.0 für mobile und Desktop-Apps https://developers.google.com/identity/protocols/OAuth2InstalledApp
[RFC] Proof-Schlüssel für den Code-Austausch durch öffentliche OAuth-Clients https://tools.ietf.org/html/rfc7636
OAuth 2.0 Race Condition https://hackerone.com/reports/55140
[RFC] Überlegungen zum OAuth 2.0-Bedrohungsmodell und zur Sicherheit https://tools.ietf.org/html/rfc6819
Angriffe auf reguläres OAuth 2.0 https://sakurity.com/oauth
[RFC] OAuth 2.0 Dynamic Client Registration Protocol https://tools.ietf.org/html/rfc7591

Danksagung

Vielen Dank an alle, die diesen Artikel mitgeschrieben haben, insbesondere an Sergey Belov, Andrey Sumin, Andrey Labunts ( @isciurus ) und Daria Yakovleva.

Mobile OAuth 2.0-Sicherheit