Wie schützt OAuth 2 vor Dingen wie Replay-Angriffen unter Verwendung des Security Token?

Question

So wie ich es verstehe, läuft in OAuth 2 die folgende Kette von Ereignissen ab, damit Site-A zum Zugang Der Benutzer Informationen aus Site-B .

1. Site-A registriert am Site-B und erhält ein Geheimnis und eine ID.
2. Wenn Benutzer sagt Site-A zum Zugang Site-B , Benutzer wird gesendet an Site-B wo sie erzählen Site-B dass sie in der Tat gerne geben würden Site-A Berechtigungen für bestimmte Informationen.
3. Site-B leitet um. Benutzer zurück zu Site-A zusammen mit einem Autorisierungscode.
4. Site-A gibt dann diesen Autorisierungscode zusammen mit seinem Geheimnis zurück an Site-B im Gegenzug für ein Sicherheits-Token.
5. Site-A stellt dann Anfragen an Site-B im Namen von Benutzer durch Bündelung des Sicherheits-Tokens zusammen mit den Anfragen.

Wie funktioniert das Ganze in Bezug auf Sicherheit und Verschlüsselung auf hohem Niveau? Wie schützt OAuth 2 vor Dingen wie Replay-Attacken unter Verwendung des Security Token?

Answer 1

Das ist ein Juwel:

https://www.digitalocean.com/community/tutorials/an-introduction-to-oauth-2

Sehr kurze Zusammenfassung:

OAuth definiert vier Rollen:

1. Eigentümer der Ressource
2. Kunde
3. Ressourcen-Server
4. Autorisierungsserver

Sie (Ressourcenbesitzer) haben ein Mobiltelefon. Sie haben mehrere verschiedene E-Mail-Konten, aber Sie möchten alle Ihre E-Mail-Konten in einer App haben, damit Sie nicht ständig wechseln müssen. Also bittet Ihr GMail (Client) um Zugriff (über den Autorisierungsserver von Yahoo) auf Ihre Yahoo-E-Mails (Ressourcenserver), damit Sie beide E-Mails in Ihrer GMail-Anwendung lesen können.

Der Grund für die Existenz von OAuth ist, dass es für GMail zu unsicher ist, Ihren Yahoo-Benutzernamen und Ihr Passwort zu speichern.

Answer 2

Die andere Antwort ist sehr detailliert und geht auf den größten Teil der Fragen ein, die der Antragsteller gestellt hat.

Um die Frage des Auftraggebers "Wie schützt OAuth 2 vor Dingen wie Replay-Attacken mit dem Security Token?" näher zu erläutern, gibt es zwei zusätzliche Schutzmaßnahmen in den offiziellen Empfehlungen für Implementierung OAuth 2:

1. Token haben in der Regel eine kurze Verfallszeit ( https://www.rfc-editor.org/rfc/rfc6819#section-5.1.5.3 ) :

Eine kurze Verfallszeit für Token ist ein Mittel zum Schutz gegen die folgenden Bedrohungen:

• Wiederholung...

2. Wenn das Token von Site A verwendet wird, wird empfohlen, dass es nicht als URL-Parameter, sondern im Header-Feld der Autorisierungsanfrage ( https://www.rfc-editor.org/rfc/rfc6750 ) :

Clients SOLLTEN authentifizierte Anfragen mit einem Überbringer-Token stellen, indem sie das Header-Feld "Autorisierung" mit dem HTTP-Autorisierungscode "Bearer" verwenden Autorisierungsschema. ...

Die Methode "application/x-www-form-urlencoded" SOLLTE NICHT verwendet werden außer in Anwendungskontexten, in denen die beteiligten Browser keinen keinen Zugriff auf das Header-Feld "Autorisierung" haben. ...

URI Query Parameter... wird aufgenommen, um die derzeitige Verwendung zu dokumentieren; seine Verwendung wird nicht empfohlen empfohlen, da sie Sicherheitsmängel aufweist.

Answer 3

Hier ist vielleicht die einfachste Erklärung, wie OAuth2 für alle 4 Gewährungstypen funktioniert, d. h. für 4 verschiedene Abläufe, bei denen die Anwendung das Zugriffstoken erwerben kann.

Ähnlichkeit

Alle Förderungsbewegungen bestehen aus 2 Teilen:

• Zugriffstoken abrufen
• Zugangstoken verwenden

Der 2. Teil Zugangstoken verwenden'. ist für alle Ströme identisch

Unterschied

Der 1. Teil des Flusses Zugangstoken abrufen". für jede Zuschussart variiert.

Im Allgemeinen ist jedoch die Zugangstoken abrufen". Teil lässt sich in 5 Schritten zusammenfassen:

1. Vorregistrierung Ihrer Anwendung (Client) beim OAuth-Anbieter, z. B. Twitter usw., um Client-ID/Geheimnis zu erhalten
2. Erstellen Sie eine Social Login-Schaltfläche mit der Client-ID und den erforderlichen Bereichen/Berechtigungen auf Ihrer Seite, so dass der Benutzer beim Anklicken zum OAuth-Anbieter weitergeleitet wird, um sich zu authentifizieren.
3. OAuth-Anbieter fordert den Benutzer auf, Ihrer Anwendung (Client) die Erlaubnis zu erteilen
4. OAuth-Anbieter gibt Code aus
5. App (Client) erwirbt Zugriffstoken

Das folgende Diagramm zeigt, wie sich die einzelnen Förderungsarten anhand der 5 Schritte unterscheiden.

Dieses Diagramm stammt aus https://blog.oauth.io/introduction-oauth2-flow-diagrams/

Sie haben unterschiedliche Schwierigkeitsgrade bei der Implementierung, Sicherheit und Anwendungsfälle. Je nach Ihren Bedürfnissen und Ihrer Situation müssen Sie eine von ihnen verwenden. Welches soll verwendet werden?

Client-Berechtigungsnachweis : Wenn Ihre Anwendung nur einen einzigen Benutzer bedient

Ressourceneigentümer Passwort Crendential : Dies sollte nur als letzter Ausweg verwendet werden, da der Benutzer seine Anmeldedaten an die App weitergeben muss, was bedeutet, dass die App alles tun kann, was der Benutzer kann

Berechtigungscode : Der beste Weg, um eine Benutzerautorisierung zu erhalten

Implizit : Wenn Ihre App mobil oder einseitig ist

Hier finden Sie weitere Erklärungen zu dieser Wahl: https://blog.oauth.io/choose-oauth2-flow-grant-types-for-app/

Answer 4

Um ehrlich zu sein, habe ich unter den Antworten keine gefunden, die die wichtigste Frage beantwortet: "Wie schützt OAuth 2 vor Dingen wie Replay-Attacken mit dem Security Token?".

Erstens gilt das von OP beschriebene Zugangsschema nur für einen der von OAuth 2.0 bereitgestellten Ströme - Berechtigungscode Erteilung . Es gibt noch andere Ströme. Eines der gemeinsamen Merkmale aller Ströme ist, dass bei erfolgreicher Authentifizierung die Der Kunde erhält ein Zugangstoken .

Wie können Sie sich vor Replay-Angriffen schützen? Das ist (mit einigen Vorbehalten) möglich, aber Sie müssen verstehen, dass dies erstens eine Reihe von Maßnahmen erfordert (die weiter unten beschrieben werden), und zweitens können Sie sich nicht einfach zu 100 % vor dieser Art von Angriffen schützen, manchmal können Sie unberechtigte Zugriffsversuche sofort stoppen, manchmal können Sie nur die Dauer eines solchen Angriffs verkürzen, wenn er stattfindet.

Was brauchen Sie also dafür?

1. Signiert verwenden JWT als Ihre Spielsteine.
2. Verwenden Sie eine sehr kurze Verfallszeit für Zugangstokens, 10 Minuten sind meiner Meinung nach ausreichend.
3. Ihr Autorisierungsserver muss Aktualisierungs-Tokens ausgeben, was im Allgemeinen optional nach der Norm . Die Ablaufzeit von Refresh-Tokens sollte nicht zu lang sein. Für jede Situation sollte sie anders gelöst werden, zum Beispiel würde ich sie für eine Website etwas länger als eine normale Benutzersitzung festlegen. Sie können auch eine Ablaufzeit für die Sitzung implementieren, wenn der Benutzer im Leerlauf ist, aber dies gilt für die Anwendungslogik und ist im Standard nicht vorgesehen (dies ist ein recht einfacher Mechanismus, der aber nicht in den Rahmen dieser Frage passt).
4. Sie müssen die ausgegebenen Aktualisierungs-Tokens in der Datenbank des Autorisierungsservers speichern. Sie müssen jedoch keine Zugriffstoken-Daten speichern, um die Vorteile von eigenständigen JWTs zu nutzen.
5. Es ist ratsam, Daten über Aktualisierungs-Token während der Lebensdauer der Sitzung zu speichern, d. h. bis zu dem Zeitpunkt, an dem das Aktualisierungs-Token abläuft (es handelt sich nicht um ein Token, sondern um eine Token-Familie - mehr dazu weiter unten).
6. Ergreifen Sie allgemeine Maßnahmen zum Schutz vor Token-/Sitzungsdiebstahl, die wahrscheinlich bekannt sind, darunter die folgenden: Verwenden Sie nur eine sichere Verbindung; wenn Sie Token auf der Seite des Endnutzers mit Cookies speichern, setzen Sie Cookie-Flags, um sie zu schützen, mehr Details hier einen Schutz gegen Cross-Site Request Forgery (CSRF) implementieren, mehr Details hier .
7. ( Jetzt beginnt der interessanteste Teil ) Implementieren Sie die Rotation von Aktualisierungs-Token. Das bedeutet, dass jedes Mal, wenn ein Client ein Refresh-Token verwendet, um ein neues Access-Token zu erhalten (weil das Access-Token abgelaufen ist), ein neues Refresh-Token muss zusammen mit dem neuen Zugangstoken ausgestellt werden, und das alte Refresh-Token muss ungültig gemacht werden . Es könnte nur eine Markierung in der Datenbank sein, die anzeigt, dass das Aktualisierungs-Token ungültig ist.
8. Jedes Mal, wenn der Autorisierungsserver ein Refresh-Token ausstellt, muss er diesem (neben anderen erforderlichen/empfohlenen) die folgenden Angaben hinzufügen: jti mit einer eindeutigen Token-ID und einem privaten Anspruch mit beliebigen nicht zugewiesener öffentlicher Name z.B. fid mit eindeutiger Token-Familien-ID (innerhalb einer Sitzung). Zum Beispiel, refresh token 1 hatte jti 3c30a712-247b-4091-b692-8c3e92b83bb2 , fid 4eb44450-84e9-4fbc-830e-33935e20f7e6 nach der Ausgabe von refresh token 2 anstelle von refresh token 1 könnte es eine neue jti f467cf40-8cd7-485e-8711-b5c657832fc6 haben aber die gleiche fid 4eb44450-84e9-4fbc-830e-33935e20f7e6 . Sie halten die gesamte Refresh-Token-Familie in der Datenbank, bis das letzte, noch gültige Token ungültig wird, z. B. bis es abläuft. *Sie können auf den fid dann müssen Sie die gesamte Kette/Familie von Refresh-Tokens, die innerhalb derselben Sitzung ausgegeben wurden, mit Hilfe relationaler Datenbankmechanismen verknüpfen.
9. Einführung einer absoluten Verfallszeit für Aktualisierungs-Token. Jedes Mal, wenn der Autorisierungsserver innerhalb der gleichen Sitzung ein neues Refresh-Token anstelle des vorherigen Refresh-Tokens ausstellt, wird der Wert von dessen exp Anspruch sollte die Verfallszeit des allerersten Refresh-Tokens nicht überschreiten. Zum Beispiel, wenn refresh token 1 hatte einen Wert von 1643384057 para exp Anspruch, dann jedes nachfolgende Refresh-Token, zum Beispiel refresh token 5 sollte ebenfalls denselben Wert enthalten 1643384057 im exp Anspruch.
10. Implementierung der Erkennung der Wiederholung (Wiederverwendung) von Refresh-Token. Vielleicht haben Sie schon erraten, was als nächstes zu tun ist. Jedes Mal, wenn der Autorisierungsserver eine Anfrage zur Ausstellung eines Zugangstokens erhält, muss der Autorisierungsserver unter anderem prüfen, ob das vorgelegte Refresh-Token zu einer bestehenden Kette/Familie gehört und nicht als ungültig markiert ist. Erhält ein Autorisierungsserver ein ungültig gewordenes Aktualisierungs-Token, das zu einer Familie mit einem gültigen (neuesten) Aktualisierungs-Token gehört, MUSS er das jüngste Aktualisierungs-Token ungültig machen (keine gültigen Token mehr vorhanden) und die Ausstellung eines Zugriffstokens verweigern.

Was passiert, wenn ein Angreifer ein Token/eine Sitzung stiehlt und versucht, es/sie wiederzuverwenden? Es gibt mehrere Szenarien:

1. Das Token/die Sitzung wurde vom Angreifer verwendet, bevor der Client auf Antrag eines rechtmäßigen Benutzers die Ausstellung neuer Zugangs- und Aktualisierungs-Tokens beantragte. Das heißt, der Angreifer hat es geschafft, dies zuerst zu tun. Bei der nächsten Anfrage eines rechtmäßigen Benutzers sendet der Client dann ein ungültiges Refresh-Token an den Autorisierungsserver (weil der Angreifer die Anfrage früher gestellt hat und das Refresh-Token des rechtmäßigen Benutzers ungültig wurde). Die Sitzung wird für ungültig erklärt.
2. Das Token/die Sitzung wurde von einem legitimen Benutzer verwendet, und das gestohlene Token/die gestohlene Sitzung wurde später von einem Angreifer verwendet. In diesem Fall passiert das Gleiche - die Sitzung wird ungültig, ich denke, das ist verständlich.
3. Es ist möglich, dass der rechtmäßige Benutzer nach dem Diebstahl des Tokens/der Sitzung keine weiteren Anfragen mehr gestellt hat, so dass der Angreifer bis zum absoluten Ablauf des Refresh-Tokens (siehe Punkt 9) Zugang hat.

Der Autorisierungsserver kann nicht wissen, wer ein rechtmäßiger Benutzer und wer ein Angreifer ist, so dass in einer solchen Situation immer das letzte (gültige) Refresh-Token ungültig gemacht wird, wodurch die Sitzung abläuft/ungültig wird. Danach kann ein rechtmäßiger Benutzer seine Identität durch Eingabe eines Kennworts überprüfen, ein Angreifer jedoch nicht.

Wenn Sie wissen, wie das funktioniert, sollten Sie Werte für den Ablauf von Token wählen, die für Ihr Projekt relevant sind.

Ich empfehle Ihnen, sich eingehender mit der verwandte Normen sowie die OAuth 2.0 Sicherheit Beste aktuelle Praxis . Dort finden Sie auch die Abschnitt Token Replay Prevention .

Answer 5

OAuth2 allein bietet keinen Schutz vor Replay-Angriffen. Es gibt jedoch "Erweiterungen" wie MTLS oder DPoP, die verwendet werden können. Mehr dazu finden Sie unter https://marcinjahn.com/technologies/security/oauth2/sender-constraint.html