10. Sicherheitsüberlegungen (Security Considerations)
Als flexibles und erweiterbares Framework hängen die Sicherheitsüberlegungen von OAuth von vielen Faktoren ab. Die folgenden Abschnitte bieten Implementierern Sicherheitsrichtlinien, die sich auf die drei in Abschnitt 2.1 beschriebenen Client-Profile konzentrieren: Webanwendung, benutzeragenten-basierte Anwendung und native Anwendung.
Ein umfassendes OAuth-Sicherheitsmodell und eine Analyse sowie Hintergrundinformationen zum Protokolldesign werden von [OAuth-THREATMODEL] bereitgestellt.
10.1. Client-Authentifizierung (Client Authentication)
Der Autorisierungsserver (Authorization Server) richtet Client-Anmeldeinformationen mit Webanwendungsclients zum Zweck der Client-Authentifizierung ein. Der Autorisierungsserver wird ermutigt, stärkere Client-Authentifizierungsmittel als ein Client-Passwort in Betracht zu ziehen. Webanwendungsclients müssen (MUST) die Vertraulichkeit von Client-Passwörtern und anderen Client-Anmeldeinformationen sicherstellen.
Der Autorisierungsserver darf (MUST NOT) Client-Passwörter oder andere Client-Anmeldeinformationen an native Anwendungs- oder benutzeragenten-basierte Anwendungsclients zum Zweck der Client-Authentifizierung ausgeben. Der Autorisierungsserver kann (MAY) ein Client-Passwort oder andere Anmeldeinformationen für eine bestimmte Installation eines nativen Anwendungsclients auf einem bestimmten Gerät ausgeben.
Wenn die Client-Authentifizierung nicht möglich ist, sollte (SHOULD) der Autorisierungsserver andere Mittel einsetzen, um die Identität des Clients zu validieren - beispielsweise durch Anforderung der Registrierung der Client-Weiterleitungs-URI oder durch Einbeziehung des Ressourcenbesitzers (Resource Owner) zur Bestätigung der Identität.
10.2. Client-Identitätsfälschung (Client Impersonation)
Ein böswilliger Client kann sich als ein anderer Client ausgeben und Zugriff auf geschützte Ressourcen erhalten, wenn der gefälschte Client seine Client-Anmeldeinformationen nicht vertraulich halten kann oder nicht in der Lage ist, sie vertraulich zu halten.
Der Autorisierungsserver muss (MUST) den Client wann immer möglich authentifizieren. Wenn der Autorisierungsserver den Client aufgrund der Natur des Clients nicht authentifizieren kann, muss (MUST) der Autorisierungsserver die Registrierung jeder Weiterleitungs-URI erfordern, die zum Empfangen von Autorisierungsantworten verwendet wird, und sollte (SHOULD) andere Mittel nutzen, um Ressourcenbesitzer vor solchen potenziell böswilligen Clients zu schützen.
10.3. Zugangstokens (Access Tokens)
Zugangstoken-Anmeldeinformationen (Access Token) (das Zugangstoken und das vom Autorisierungsserver ausgegebene Geheimnis) können verwendet werden, um Zugriff auf den Ressourcenserver (Resource Server) zu erhalten. Zugangstoken-Anmeldeinformationen müssen (MUST) vor unbefugtem Zugriff geschützt werden.
Zugangstokens haben normalerweise eine begrenzte Lebensdauer und können bei Ablauf aktualisiert werden. Solche Tokens können jedoch von einem Angreifer abgefangen und verwendet werden. Maßnahmen zur Minderung der Sicherheitsauswirkungen umfassen die Ausgabe von Tokens mit kurzer Lebensdauer und begrenztem Bereich.
10.4. Aktualisierungstokens (Refresh Tokens)
Der Autorisierungsserver kann (MAY) strenge Speicheranforderungen für Aktualisierungstokens (Refresh Token) durchsetzen. Beispielsweise kann der Autorisierungsserver die Lebensdauer des Aktualisierungstokens begrenzen oder den Bereich des Aktualisierungstokens einschränken.
Der Autorisierungsserver muss (MUST) eine Bindung zwischen dem Aktualisierungstoken und dem Client aufrechterhalten, dem es ausgestellt wurde. Das Aktualisierungstoken darf (MUST) nur vom Client verwendet werden, dem es ausgestellt wurde.
10.5. Autorisierungscodes (Authorization Codes)
Die Übertragung des Autorisierungscodes (Authorization Code) sollte (SHOULD) über einen sicheren Kanal erfolgen, um Vertraulichkeit und Client-Authentizität zu gewährleisten.
Der Autorisierungsserver muss (MUST) sicherstellen, dass der Autorisierungscode nur einmal verwendet wird. Wenn ein Autorisierungscode mehr als einmal verwendet wird, muss (MUST) der Autorisierungsserver die Anforderung ablehnen und sollte (SHOULD), wenn möglich, alle zuvor auf der Grundlage dieses Autorisierungscodes ausgestellten Tokens widerrufen.
10.6. Manipulation der Autorisierungscode-Weiterleitungs-URI (Authorization Code Redirection URI Manipulation)
Wenn ein Angreifer einen Autorisierungscode abfängt, kann der Angreifer versuchen, die vom Client verwendete Weiterleitungs-URI durch eine vom Angreifer kontrollierte URI zu ersetzen.
Der Autorisierungsserver muss (MUST) diesen Angriff verhindern, indem er die Registrierung der Weiterleitungs-URI erfordert und die Weiterleitungs-URI validiert, wenn der Client den Autorisierungscode austauscht.
10.7. Ressourcenbesitzer-Passwort-Anmeldeinformationen (Resource Owner Password Credentials)
Der Ressourcenbesitzer-Passwort-Anmeldeinformationen-Autorisierungstyp wird häufig aus Legacy- oder Migrationsgründen verwendet. Dieser Autorisierungstyp sollte (SHOULD) nur verwendet werden, wenn eine hohe Vertrauensbeziehung zwischen dem Ressourcenbesitzer und dem Client besteht.
10.8. Anforderungsvertraulichkeit (Request Confidentiality)
Zugangstokens, Aktualisierungstokens, Ressourcenbesitzer-Passwörter und Client-Anmeldeinformationen dürfen (MUST NOT) ohne Vertraulichkeit übertragen werden. Es wird empfohlen (RECOMMENDED), TLS [RFC5246] Version 1.2 oder höher zu verwenden.
10.9. Sicherstellung der Endpunkt-Authentizität (Ensuring Endpoint Authenticity)
TLS-Server-Authentifizierung (definiert in RFC5246) sollte (SHOULD) verwendet werden, um die Identität der Endpunkte zu überprüfen, mit denen der Ressourcenbesitzer und der Client kommunizieren.
10.10. Anmeldeinformationen-Raten-Angriffe (Credentials-Guessing Attacks)
Der Autorisierungsserver muss (MUST) Schutzmaßnahmen gegen Brute-Force-Angriffe implementieren, um den Autorisierungsserver selbst und seine Clients vor Anmeldeinformationen-Raten-Angriffen zu schützen.
10.11. Phishing-Angriffe (Phishing Attacks)
Die umfangreiche Verwendung von Umleitungen im OAuth-Protokolldesign schafft Möglichkeiten für Angreifer, den OAuth-Protokollfluss auszunutzen, um Phishing-Angriffe zu starten.
Der Autorisierungsserver sollte (SHOULD) Authentifizierungsmechanismen verwenden, die es dem Ressourcenbesitzer ermöglichen, die Entität, bei der er sich authentifiziert, visuell zu überprüfen.
10.12. Cross-Site Request Forgery (Cross-Site Request Forgery)
Cross-Site Request Forgery (CSRF) ist eine Exploitationstechnik, bei der ein Angreifer den Benutzeragenten des Opfers dazu bringt, unbeabsichtigte Anfragen ohne Wissen des Opfers zu senden.
Der Client muss (MUST) den Anforderungsparameter „state" verwenden, um den Zustand zwischen seiner Client-Autorisierungs-Endpunkt-Anforderung und dem nachfolgenden Rückruf aufrechtzuerhalten, um sich vor CSRF-Angriffen zu schützen.
10.13. Clickjacking (Clickjacking)
Beim Clickjacking registriert ein Angreifer eine Zielseite, die von einem legitimen Server bereitgestellt wird, in einem iframe und platziert sie als transparente Ebene über dem iframe.
Der Autorisierungsserver sollte (SHOULD) das X-Frame-Options-Headerfeld verwenden, um Clickjacking-Angriffe zu verhindern.
10.14. Code-Injektion und Eingabevalidierung (Code Injection and Input Validation)
Alle Eingabewerte, die vom Autorisierungsserver, Client und Ressourcenserver empfangen werden, müssen (MUST) validiert werden, um Injektionsangriffe zu verhindern.
10.15. Offene Weiterleitungen (Open Redirectors)
Der Autorisierungsserver, der Autorisierungs-Endpunkt und der Client-Weiterleitungs-Endpunkt dürfen (MUST NOT) als offene Weiterleitungen konzipiert sein.
10.16. Missbrauch des Zugangstokens zur Identitätsfälschung des Ressourcenbesitzers (Misuse of Access Token)
Im impliziten Autorisierungsfluss kann ein Angreifer ein abgefangenes Zugangstoken verwenden, um sich als Ressourcenbesitzer auszugeben, indem er sich als ein anderer Client ausgibt.
Client-Entwickler sollten (SHOULD) Maßnahmen ergreifen, um sicherzustellen, dass Zugangstokens nur vom beabsichtigten Ressourcenserver verwendet werden.