10. Sicherheitsüberlegungen (Security Considerations)

Als flexibles und erweiterbares Framework hängen die Sicherheitsüberlegungen von OAuth von vielen Faktoren ab. Die folgenden Abschnitte geben Implementierern Sicherheitsrichtlinien mit Schwerpunkt auf den drei in Abschnitt 2.1 beschriebenen Clientprofilen: Webanwendung, user-agent-basierte Anwendung und native Anwendung.

Ein umfassendes OAuth-Sicherheitsmodell und eine Analyse sowie Hintergrund zum Protokolldesign werden in [OAuth-THREATMODEL] bereitgestellt.

10.1. Clientauthentifizierung (Client Authentication)

Der Autorisierungsserver richtet Client-Anmeldeinformationen mit Webanwendungs-Clients zum Zweck der Clientauthentifizierung ein. Der Autorisierungsserver wird ermutigt, stärkere Mittel der Clientauthentifizierung als ein Clientpasswort in Betracht zu ziehen. Webanwendungs-Clients müssen die Vertraulichkeit von Clientpasswörtern und anderen Client-Anmeldeinformationen sicherstellen (MUST).

Der Autorisierungsserver darf nativen Anwendungen oder user-agent-basierten Anwendungen keine Clientpasswörter oder anderen Client-Anmeldeinformationen zum Zweck der Clientauthentifizierung ausstellen (MUST NOT). Er kann jedoch ein Clientpasswort oder andere Anmeldeinformationen für eine bestimmte Installation eines nativen Anwendungs-Clients auf einem bestimmten Gerät ausstellen (MAY).

Wenn Clientauthentifizierung nicht möglich ist, sollte der Autorisierungsserver andere Mittel einsetzen, um die Identität des Clients zu validieren, etwa die Registrierung der Client-Weiterleitungs-URI verlangen oder den Ressourcenbesitzer zur Bestätigung der Identität einbeziehen (SHOULD). Eine gültige Weiterleitungs-URI reicht nicht aus, um die Clientidentität bei der Anfrage nach Autorisierung durch den Ressourcenbesitzer zu verifizieren, kann aber verhindern, dass Anmeldeinformationen nach erhaltener Autorisierung an einen gefälschten Client geliefert werden.

Der Autorisierungsserver muss die Sicherheitsauswirkungen der Interaktion mit nicht authentifizierten Clients berücksichtigen und Maßnahmen ergreifen, um die mögliche Offenlegung anderer an solche Clients ausgestellter Anmeldeinformationen, etwa Aktualisierungstokens, zu begrenzen.

10.2. Client-Impersonation (Client Impersonation)

Ein bösartiger Client kann sich als ein anderer Client ausgeben und Zugriff auf geschützte Ressourcen erhalten, wenn der imitierte Client seine Client-Anmeldeinformationen nicht vertraulich hält oder dazu nicht in der Lage ist.

Der Autorisierungsserver muss den Client wann immer möglich authentifizieren (MUST). Wenn er den Client aufgrund dessen Natur nicht authentifizieren kann, muss der Autorisierungsserver die Registrierung jeder Weiterleitungs-URI verlangen, die zum Empfang von Autorisierungsantworten verwendet wird (MUST), und sollte andere Mittel nutzen, um Ressourcenbesitzer vor solchen potenziell bösartigen Clients zu schützen (SHOULD). Zum Beispiel kann er den Ressourcenbesitzer einbeziehen, um bei der Identifizierung des Clients und seiner Herkunft zu helfen.

Der Autorisierungsserver sollte eine explizite Authentifizierung des Ressourcenbesitzers erzwingen und dem Ressourcenbesitzer Informationen über den Client sowie über den angeforderten Autorisierungsumfang und die Lebensdauer bereitstellen (SHOULD). Es liegt beim Ressourcenbesitzer, diese Informationen im Kontext des aktuellen Clients zu prüfen und die Anfrage zu erlauben oder abzulehnen.

Der Autorisierungsserver sollte wiederholte Autorisierungsanfragen nicht automatisch ohne aktive Interaktion des Ressourcenbesitzers verarbeiten, wenn er den Client nicht authentifiziert oder sich nicht auf andere Maßnahmen stützt, die sicherstellen, dass die wiederholte Anfrage vom ursprünglichen Client und nicht von einem Impersonator stammt (SHOULD NOT).

10.3. Zugangstokens (Access Tokens)

Zugangstoken-Anmeldeinformationen sowie alle vertraulichen Zugangstokenattribute müssen während Übertragung und Speicherung vertraulich gehalten werden (MUST) und dürfen nur zwischen dem Autorisierungsserver, den Ressourcenservern, für die das Zugangstoken gültig ist, und dem Client, dem das Zugangstoken ausgestellt wurde, geteilt werden. Zugangstoken-Anmeldeinformationen dürfen nur mit TLS gemäß Abschnitt 1.6 und Serverauthentifizierung nach [RFC2818] übertragen werden (MUST).

Bei Verwendung des impliziten Grant-Typs wird das Zugangstoken im URI-Fragment übertragen, wodurch es unautorisierten Parteien offengelegt werden kann.

Der Autorisierungsserver muss sicherstellen, dass unautorisierte Parteien keine gültigen Zugangstokens erzeugen, ändern oder erraten können (MUST).

Der Client sollte Zugangstokens mit dem minimal notwendigen Umfang anfordern (SHOULD). Der Autorisierungsserver sollte bei der Entscheidung, wie er den angeforderten Umfang berücksichtigt, die Clientidentität einbeziehen (SHOULD) und kann ein Zugangstoken mit weniger Rechten als angefordert ausstellen (MAY).

Diese Spezifikation stellt keine Methode bereit, mit der der Ressourcenserver sicherstellen kann, dass ein ihm von einem bestimmten Client vorgelegtes Zugangstoken diesem Client vom Autorisierungsserver ausgestellt wurde.

10.4. Aktualisierungstokens (Refresh Tokens)

Autorisierungsserver können Aktualisierungstokens an Webanwendungs-Clients und native Anwendungs-Clients ausstellen (MAY).

Aktualisierungstokens müssen während Übertragung und Speicherung vertraulich gehalten werden (MUST) und dürfen nur zwischen dem Autorisierungsserver und dem Client geteilt werden, dem sie ausgestellt wurden. Der Autorisierungsserver muss die Bindung zwischen einem Aktualisierungstoken und dem Client, dem es ausgestellt wurde, aufrechterhalten (MUST). Aktualisierungstokens dürfen nur mit TLS gemäß Abschnitt 1.6 und Serverauthentifizierung nach [RFC2818] übertragen werden (MUST).

Der Autorisierungsserver muss die Bindung zwischen Aktualisierungstoken und Clientidentität immer dann prüfen, wenn die Clientidentität authentifiziert werden kann (MUST). Wenn Clientauthentifizierung nicht möglich ist, sollte er andere Mittel einsetzen, um Missbrauch von Aktualisierungstokens zu erkennen (SHOULD).

Beispielsweise kann der Autorisierungsserver Aktualisierungstoken-Rotation verwenden, bei der mit jeder Antwort auf eine Zugangstoken-Aktualisierung ein neues Aktualisierungstoken ausgegeben wird. Das vorherige Aktualisierungstoken wird ungültig gemacht, aber vom Autorisierungsserver aufbewahrt. Wird ein Aktualisierungstoken kompromittiert und anschließend sowohl vom Angreifer als auch vom legitimen Client verwendet, wird einer von beiden ein ungültig gemachtes Token vorlegen, was den Autorisierungsserver über den Vorfall informiert.

Der Autorisierungsserver muss sicherstellen, dass unautorisierte Parteien keine gültigen Aktualisierungstokens erzeugen, ändern oder erraten können (MUST).

10.5. Autorisierungscodes (Authorization Codes)

Die Übertragung von Autorisierungscodes sollte über einen sicheren Kanal erfolgen (SHOULD), und der Client sollte TLS für seine Weiterleitungs-URI verlangen, wenn diese URI eine Netzwerkressource identifiziert (SHOULD). Da Autorisierungscodes über User-Agent-Weiterleitungen übertragen werden, können sie möglicherweise durch User-Agent-Verlauf und HTTP-Referer-Header offengelegt werden.

Autorisierungscodes wirken als Klartext-Bearer-Anmeldeinformationen und werden verwendet, um zu prüfen, dass der Ressourcenbesitzer, der beim Autorisierungsserver Autorisierung erteilt hat, derselbe Ressourcenbesitzer ist, der zum Client zurückkehrt, um den Prozess abzuschließen. Wenn der Client den Autorisierungscode für seine eigene Authentifizierung des Ressourcenbesitzers verwendet, muss der Client-Weiterleitungsendpunkt TLS verlangen (MUST).

Autorisierungscodes müssen kurzlebig und nur einmal verwendbar sein (MUST). Wenn der Autorisierungsserver mehrere Versuche beobachtet, einen Autorisierungscode gegen ein Zugangstoken einzutauschen, sollte er versuchen, alle bereits auf Grundlage dieses kompromittierten Codes gewährten Zugangstokens zu widerrufen (SHOULD).

Wenn der Client authentifiziert werden kann, muss der Autorisierungsserver den Client authentifizieren und sicherstellen, dass der Autorisierungscode demselben Client ausgestellt wurde (MUST).

10.6. Manipulation der Weiterleitungs-URI beim Autorisierungscode

Beim Anfordern von Autorisierung mit dem Autorisierungscode-Grant kann der Client über den Parameter "redirect_uri" eine Weiterleitungs-URI angeben. Wenn ein Angreifer diesen Wert manipulieren kann, kann er den Autorisierungsserver dazu bringen, den User-Agent des Ressourcenbesitzers mit dem Autorisierungscode an eine vom Angreifer kontrollierte URI weiterzuleiten.

Ein Angreifer kann bei einem legitimen Client ein Konto erstellen und den Autorisierungsablauf starten. Wenn der User-Agent des Angreifers zum Autorisierungsserver gesendet wird, um Zugriff zu gewähren, erfasst der Angreifer die vom legitimen Client bereitgestellte Autorisierungs-URI und ersetzt die Weiterleitungs-URI des Clients durch eine URI unter seiner Kontrolle. Anschließend bringt er das Opfer dazu, dem manipulierten Link zu folgen und Zugriff für den legitimen Client zu autorisieren.

Beim Autorisierungsserver sieht das Opfer eine normale, gültige Anfrage im Namen eines legitimen und vertrauenswürdigen Clients und autorisiert sie. Danach wird es mit dem Autorisierungscode zu einem vom Angreifer kontrollierten Endpunkt weitergeleitet. Der Angreifer schließt den Ablauf ab, indem er den Code über die ursprüngliche Weiterleitungs-URI an den Client sendet. Der Client tauscht den Code gegen ein Zugangstoken und verknüpft es mit dem Konto des Angreifers, das nun Zugriff auf die vom Opfer autorisierten geschützten Ressourcen erhalten kann.

Um diesen Angriff zu verhindern, muss der Autorisierungsserver sicherstellen, dass die zum Erhalt des Autorisierungscodes verwendete Weiterleitungs-URI identisch mit der URI ist, die beim Austausch des Codes gegen ein Zugangstoken bereitgestellt wird (MUST). Er muss öffentliche Clients zur Registrierung ihrer Weiterleitungs-URIs verpflichten (MUST) und sollte dies auch für vertrauliche Clients verlangen (SHOULD). Wenn in der Anfrage eine Weiterleitungs-URI bereitgestellt wird, muss der Autorisierungsserver sie gegen den registrierten Wert validieren (MUST).

10.7. Ressourcenbesitzer-Passwort-Anmeldeinformationen

Der Grant-Typ für Ressourcenbesitzer-Passwort-Anmeldeinformationen wird häufig aus Legacy- oder Migrationsgründen verwendet. Er verringert das Gesamtrisiko der Speicherung von Benutzernamen und Passwörtern durch den Client, beseitigt aber nicht die Notwendigkeit, hochprivilegierte Anmeldeinformationen dem Client offenzulegen.

Dieser Grant-Typ birgt ein höheres Risiko als andere Grant-Typen, weil er das Passwort-Anti-Pattern beibehält, das dieses Protokoll vermeiden will. Der Client könnte das Passwort missbrauchen, oder das Passwort könnte unbeabsichtigt einem Angreifer offengelegt werden, etwa durch Protokolldateien oder andere vom Client geführte Aufzeichnungen.

Da der Ressourcenbesitzer außerdem keine Kontrolle über den Autorisierungsprozess hat, nachdem er seine Anmeldeinformationen an den Client übergeben hat, kann der Client Zugangstokens mit einem größeren Umfang erhalten als vom Ressourcenbesitzer gewünscht. Der Autorisierungsserver sollte Umfang und Lebensdauer der über diesen Grant-Typ ausgestellten Tokens berücksichtigen.

Autorisierungsserver und Client sollten die Verwendung dieses Grant-Typs minimieren und wann immer möglich andere Grant-Typen nutzen (SHOULD).

10.8. Vertraulichkeit von Anfragen (Request Confidentiality)

Zugangstokens, Aktualisierungstokens, Ressourcenbesitzer-Passwörter und Client-Anmeldeinformationen dürfen nicht im Klartext übertragen werden (MUST NOT). Autorisierungscodes sollten nicht im Klartext übertragen werden (SHOULD NOT).

Die Parameter "state" und "scope" sollten keine sensiblen Informationen über Client oder Ressourcenbesitzer im Klartext enthalten, da sie über unsichere Kanäle übertragen oder unsicher gespeichert werden können (SHOULD NOT).

10.9. Sicherstellung der Endpunktauthentizität

Zur Verhinderung von Man-in-the-Middle-Angriffen muss der Autorisierungsserver für jede Anfrage an Autorisierungs- und Token-Endpunkte TLS mit Serverauthentifizierung gemäß [RFC2818] verlangen (MUST). Der Client muss das TLS-Zertifikat des Autorisierungsservers gemäß [RFC6125] und seinen Anforderungen an die Serveridentitätsauthentifizierung validieren (MUST).

10.10. Angriffe durch Erraten von Anmeldeinformationen

Der Autorisierungsserver muss verhindern, dass Angreifer Zugangstokens, Autorisierungscodes, Aktualisierungstokens, Ressourcenbesitzer-Passwörter und Client-Anmeldeinformationen erraten (MUST).

Die Wahrscheinlichkeit, dass ein Angreifer generierte Tokens und andere nicht für Endbenutzer bestimmte Anmeldeinformationen errät, muss kleiner oder gleich 2^(-128) sein (MUST) und sollte kleiner oder gleich 2^(-160) sein (SHOULD).

Der Autorisierungsserver muss andere Mittel nutzen, um Anmeldeinformationen zu schützen, die für die Verwendung durch Endbenutzer bestimmt sind (MUST).

10.11. Phishing-Angriffe

Die weite Verbreitung dieses und ähnlicher Protokolle kann dazu führen, dass Endbenutzer sich daran gewöhnen, zu Websites weitergeleitet zu werden, auf denen sie ihre Passwörter eingeben sollen. Wenn Endbenutzer die Authentizität dieser Websites vor der Eingabe ihrer Anmeldeinformationen nicht sorgfältig prüfen, können Angreifer diese Gewohnheit ausnutzen, um Passwörter von Ressourcenbesitzern zu stehlen.

Diensteanbieter sollten versuchen, Endbenutzer über die Risiken von Phishing-Angriffen aufzuklären, und Mechanismen bereitstellen, mit denen Endbenutzer die Authentizität ihrer Sites einfach bestätigen können. Cliententwickler sollten die Sicherheitsauswirkungen berücksichtigen, die sich aus ihrer Interaktion mit dem User-Agent ergeben, etwa extern oder eingebettet, sowie die Fähigkeit des Endbenutzers, die Authentizität des Autorisierungsservers zu prüfen.

Zur Verringerung des Phishing-Risikos müssen Autorisierungsserver TLS an jedem Endpunkt verlangen, der für Interaktion mit Endbenutzern verwendet wird (MUST).

10.12. Cross-Site Request Forgery

Cross-Site Request Forgery (CSRF) ist ein Angriff, bei dem ein Angreifer den User-Agent eines betroffenen Endbenutzers dazu bringt, einer bösartigen URI, etwa einem irreführenden Link, Bild oder einer Weiterleitung, zu einem vertrauenden Server zu folgen, üblicherweise gestützt auf ein gültiges Sitzungscookie.

Ein CSRF-Angriff gegen die Weiterleitungs-URI des Clients erlaubt es einem Angreifer, seinen eigenen Autorisierungscode oder sein eigenes Zugangstoken einzuschleusen. Dies kann dazu führen, dass der Client ein Zugangstoken verwendet, das mit den geschützten Ressourcen des Angreifers statt denen des Opfers verbunden ist, etwa indem Bankkontoinformationen des Opfers in einer vom Angreifer kontrollierten geschützten Ressource gespeichert werden.

Der Client muss CSRF-Schutz für seine Weiterleitungs-URI implementieren (MUST). Dies geschieht typischerweise, indem jede Anfrage an den Weiterleitungsendpunkt einen Wert enthalten muss, der die Anfrage an den authentifizierten Zustand des User-Agents bindet, etwa einen Hash des Sitzungscookies. Der Client sollte den Anfrageparameter "state" verwenden, um diesen Wert bei einer Autorisierungsanfrage an den Autorisierungsserver zu liefern (SHOULD).

Nachdem die Autorisierung vom Endbenutzer erhalten wurde, leitet der Autorisierungsserver den User-Agent mit dem erforderlichen Bindungswert im Parameter "state" zurück zum Client. Der Bindungswert ermöglicht dem Client, die Gültigkeit der Anfrage durch Vergleich mit dem authentifizierten Zustand des User-Agents zu prüfen. Der für CSRF-Schutz verwendete Bindungswert muss einen nicht erratbaren Wert enthalten, wie in Abschnitt 10.10 beschrieben (MUST), und der authentifizierte Zustand des User-Agents, etwa Sitzungscookie oder HTML5 Local Storage, muss an einem Ort aufbewahrt werden, der nur Client und User-Agent zugänglich ist, also durch Same-Origin-Policy geschützt ist (MUST).

Ein CSRF-Angriff gegen den Autorisierungsendpunkt des Autorisierungsservers kann dazu führen, dass ein Angreifer Endbenutzerautorisierung für einen bösartigen Client erhält, ohne den Endbenutzer einzubeziehen oder zu warnen.

Der Autorisierungsserver muss CSRF-Schutz für seinen Autorisierungsendpunkt implementieren und sicherstellen, dass ein bösartiger Client keine Autorisierung ohne Wissen und ausdrückliche Zustimmung des Ressourcenbesitzers erhalten kann (MUST).

10.13. Clickjacking

Bei einem Clickjacking-Angriff registriert ein Angreifer einen legitimen Client und erstellt dann eine bösartige Site, die die Webseite des Autorisierungsendpunkts des Autorisierungsservers in einem transparenten iframe über einer Reihe von Täuschungsbuttons lädt. Diese Buttons sind sorgfältig so platziert, dass sie direkt unter wichtigen Buttons der Autorisierungsseite liegen. Klickt ein Endbenutzer auf einen irreführenden sichtbaren Button, klickt er tatsächlich auf einen unsichtbaren Button der Autorisierungsseite, etwa "Authorize". Dadurch kann der Angreifer einen Ressourcenbesitzer dazu bringen, seinem Client Zugriff zu gewähren, ohne dass der Endbenutzer dies bemerkt.

Um diese Angriffsform zu verhindern, sollten native Anwendungen bei der Anfrage nach Endbenutzerautorisierung externe Browser verwenden, statt Browser in die Anwendung einzubetten (SHOULD). In den meisten neueren Browsern kann der Autorisierungsserver iframes mit dem nicht standardisierten Header "x-frame-options" vermeiden. Dieser Header kann die Werte "deny" und "sameorigin" haben, die jeweils jegliches Framing oder Framing durch Sites anderer Herkunft blockieren. Für ältere Browser können JavaScript-Frame-Busting-Techniken verwendet werden, sie sind aber möglicherweise nicht in allen Browsern wirksam.

10.14. Code Injection und Eingabevalidierung

Ein Code-Injection-Angriff tritt auf, wenn eine Eingabe oder sonstige externe Variable von einer Anwendung ungefiltert verwendet wird und die Anwendungslogik verändert. Dies kann einem Angreifer Zugriff auf das Anwendungsgerät oder dessen Daten ermöglichen, Denial of Service verursachen oder zahlreiche bösartige Nebeneffekte einführen.

Der Autorisierungsserver und der Client müssen jeden empfangenen Wert bereinigen und, wenn möglich, validieren, insbesondere die Werte der Parameter "state" und "redirect_uri" (MUST).

10.15. Offene Weiterleiter (Open Redirectors)

Der Autorisierungsserver, der Autorisierungsendpunkt und der Client-Weiterleitungsendpunkt können falsch konfiguriert sein und als offene Weiterleiter arbeiten. Ein offener Weiterleiter ist ein Endpunkt, der einen Parameter verwendet, um einen User-Agent ohne Validierung automatisch an den durch den Parameterwert angegebenen Ort weiterzuleiten.

Offene Weiterleiter können in Phishing-Angriffen genutzt werden oder um Endbenutzer durch Verwendung der URI-authority-Komponente eines vertrauten Ziels zum Besuch bösartiger Sites zu bewegen. Erlaubt der Autorisierungsserver dem Client außerdem, nur einen Teil der Weiterleitungs-URI zu registrieren, kann ein Angreifer einen vom Client betriebenen offenen Weiterleiter verwenden, um eine Weiterleitungs-URI zu konstruieren, die die Validierung des Autorisierungsservers besteht, den Autorisierungscode oder das Zugangstoken aber an einen vom Angreifer kontrollierten Endpunkt sendet.

10.16. Missbrauch von Zugangstokens zur Impersonation des Ressourcenbesitzers im impliziten Ablauf

Für öffentliche Clients, die implizite Abläufe verwenden, stellt diese Spezifikation keine Methode bereit, mit der der Client feststellen kann, welchem Client ein Zugangstoken ausgestellt wurde.

Ein Ressourcenbesitzer kann einem bösartigen Client eines Angreifers freiwillig Zugriff auf eine Ressource delegieren, etwa aufgrund von Phishing oder eines anderen Vorwands. Ein Angreifer kann ein Token auch über einen anderen Mechanismus stehlen und anschließend versuchen, sich als Ressourcenbesitzer auszugeben, indem er das Zugangstoken einem legitimen öffentlichen Client vorlegt.

Im impliziten Ablauf (response_type=token) kann der Angreifer das Token in der Antwort des Autorisierungsservers leicht austauschen und das echte Zugangstoken durch ein zuvor an den Angreifer ausgestelltes Token ersetzen.

Server, die mit nativen Anwendungen kommunizieren und sich darauf verlassen, dass ein im Backchannel übergebenes Zugangstoken den Benutzer des Clients identifiziert, können ähnlich kompromittiert werden, wenn ein Angreifer eine kompromittierte Anwendung erstellt, die beliebige gestohlene Zugangstokens einschleusen kann.

Jeder öffentliche Client, der annimmt, dass nur der Ressourcenbesitzer ihm ein gültiges Zugangstoken für die Ressource vorlegen kann, ist für diese Angriffsart anfällig.

Diese Angriffsart kann Informationen über den Ressourcenbesitzer beim legitimen Client gegenüber dem Angreifer, also dem bösartigen Client, offenlegen. Außerdem kann der Angreifer beim legitimen Client Operationen mit denselben Berechtigungen ausführen wie der Ressourcenbesitzer, der ursprünglich das Zugangstoken oder den Autorisierungscode gewährt hat.

Die Authentifizierung von Ressourcenbesitzern gegenüber Clients liegt außerhalb des Umfangs dieser Spezifikation. Jede Spezifikation, die den Autorisierungsprozess als Form delegierter Endbenutzerauthentifizierung gegenüber dem Client verwendet, etwa ein Drittanbieter-Anmeldedienst, darf den impliziten Ablauf nicht ohne zusätzliche Sicherheitsmechanismen verwenden, die es dem Client ermöglichen festzustellen, ob das Zugangstoken für seine Verwendung ausgestellt wurde, etwa durch eine Audience-Beschränkung des Zugangstokens (MUST NOT).