James Steidl - Fotolia
Sicherheitslücken in OAuth 2.0: Das müssen Unternehmen wissen
Forscher der Universität Trier haben Sicherheitslücken im beliebten Identity-Standard gefunden – wie können Unternehmen sich schützen?
OAuth 2.0 gilt als sicheres Framework – und doch konnten Forscher der Uni Trier Anfang des Jahres eine Handvoll Sicherheitslücken aufdecken. OAuth hat sich in den letzten Jahren zum De-Facto Standard für die Client-Autorisierung entwickelt und steht damit im Zentrum einer jeden Identity- und Access-Management-Infrastruktur. Denn das Framework wird in vielen SaaS-Anwendungen wie Facebook, Google und Yahoo oder in Cloud-Infrastrukturen wie Azure Active Directory sowie eben in moderner IAM-Software integriert.
Die umfassende Analyse der Forscher enthält zugegebenermaßen größtenteils theoretische Fälle, die eher marginale Bedeutung haben. Weiß ein Hacker aber um diese Lücken, kann er Log-in-Daten von Nutzern abgreifen, sobald sich diese mittels OAuth bei Online-Services anmelden.
Im Prinzip beweisen die Forscher damit, dass OAuth durchaus sicher ist – wenn man sich an Vorgaben wie RFC 6749 und RFC 6819 hält.
Und doch ist es beunruhigend, dass in einem Standard wie OAuth Lücken gefunden werden können, durch die Angreifer an Passwörter und sensible Daten gelangen können. Im Report werden zwei interessante Angriffsvektoren vorgestellt: der Authorization Grant und der Implicit Grant, die sich beide auf Redirect-basierte Flows beziehen. Der grundlegende Datenfluss besteht aus zwei Schritten:
- Im ersten Schritt lenkt der Client einen Nutzer per Redirect im Browser auf den OAuth 2.0 Autorisierungsserver (AS), um die Autorisierung zu bestätigen. In diesem Schritt authentifiziert der AS den Nutzer. Sobald er autorisiert wurde, schickt der AS den Nutzer zum Client zurück – entweder mit dem Access Token in einem URL-Fragment (Implicit Flow) oder mit einem Code, den der Client gegen die Token austauscht (Authorization Grant Flow).
- Im zweiten Schritt kann der Client diese Token dann nutzen, um auf gesicherte Ressourcen zuzugreifen.
Im Folgenden ein paar Details zu den zwei OAuth-Angriffsarten.
Beliebige HTTP-Redirects oder Code-307-Angriff
Dieser Angriff hängt davon ab, wie der Autorisierungsserver den Nutzer nach der Autorisierung zum Client leitet. Ein typischer Redirect nutzt den HTTP-Statuscode 302 und weist den Browser an, eine andere Seite zu laden.
„Die umfassende Analyse der Forscher enthält größtenteils theoretische Fälle, die eher marginale Bedeutung haben. Weiß ein Hacker aber um diese Lücken, kann er Log-in-Daten von Nutzern abgreifen.“
Hans Zandbelt, Ping Identity
xxx
Wenn der AS dagegen den Statuscode 307 verwendet, kann dies dazu führen, dass die Inhalte des ursprünglichen POST-Befehls an den neuen Host gesendet werden. So kann ein bösartiger Client an den Benutzernamen und das Passwort gelangen, das dem Autorisierungsserver übermittelt wurde.
Es handelt sich hierbei um eine theoretische Attacke. Die OAuth-Spezifikation beschreibt nicht explizit, wie der AS den Nutzer redirecten soll. Bestimmte Federated-Autorisierungsserver nutzen daher den Code 302 für Redirects und sind so nicht anfällig für diese Art des Angriffs.
Die Verwirrungstaktik via Autorisierungsserver
Dieser Angriff kann erfolgen, wenn ein Client mit mehreren OAuth-Autorisierungsservern interagiert. Ein bösartiger Autorisierungsserver kann dann versuchen, dem Client vorzugaukeln, er sei der echte Autorisierungsserver. Hat er damit Erfolg, so kann er sensible Informationen wie Geheimdaten, Codes und Tokens abgreifen.
Unternehmen, die mit einem solchen Setup arbeiten – ein Client mit multiplen Identitäts-Providern oder Autorisierungsservern – oder dieses Deployment in Erwägung ziehen, sollten den Empfehlungen der OAuth-Community folgen, um eine solche Verwirrungsattacke abzuwehren. Die OAuth-Community denkt bereits über eine Behebung dieser Schwachstelle nach, die im Update der OAuth-Spezifikationen enthalten sein wird. So können Unternehmen diesen Fehler standardisiert beseitigen, sobald die Implementationen verfügbar sind.
Über den Autor:
Hans Zandbelt ist Senior Technical Architect bei Ping Identity.
Folgen Sie SearchSecurity.de auch auf Twitter, Google+, Xing und Facebook!
