OAuth (Open Authorization) ist ein Protokoll, mit dem Nutzer einer Drittanbieteranwendung Zugriff auf Daten gewähren können, ohne ihr Passwort preisgeben zu müssen. Dadurch können Nutzer Drittanbieter-Apps authentifizieren und autorisieren, sodass diese auf gespeicherte Daten und Ressourcen wie Kontoinformationen, Fotos und Dokumente zugreifen können, jedoch nicht auf Anmeldeinformationen. Die aktuellste Version von OAuth ist OAuth 2.0.
OAuth wird auch für Single-Sign-On-Anmeldungen verwendet, sodass Nutzer sich bei einem Webdienst identifizieren können, ohne jedes Mal ihren Nutzernamen und ihr Passwort eingeben zu müssen.
Wenn ein webbasierter Dienst eine Verbindung zu einem anderen herstellt, arbeiten diese Dienste mit dem OAuth-Protokoll, um eine sichere Interaktion zu gewährleisten, bei der Nutzer nicht aufgefordert werden, Passwörter weiterzugeben.
Geschichte von OAuth
Die Weitergabe von Passwörtern wird für keine Anwendung empfohlen. Deshalb führten große Technologieunternehmen wie Google und Twitter eine Lösung namens OAuth ein.
Bereits im Jahr 2010 bot Google kleineren App-Herausgebern die Möglichkeit, Dienste zu entwickeln, die Google-Kontoinformationen verwenden, sodass Nutzer ihre Google-Passwörter nicht mit Dritten teilen müssen. Anstatt vertrauliche Passwortdaten selbst zu speichern und dann für die Sicherheit der Nutzerkonten mitverantwortlich zu sein, kann eine dritte Anwendung mit OAuth das System von Google nutzen, um Nutzer zu authentifizieren.
Dabei wird ein Zugriffstoken generiert, der die Autorisierung des Google-Kontos speichert, und die Drittanbieteranwendung verwendet dann dieses OAuth-Token, um auf einen definierten Satz von Google-Kontodaten zuzugreifen.
Das OAuth-Protokoll hat mehrere Iterationen durchlaufen, mit den letzten großen Verbesserungen im Jahr 2012. Mehrere andere große Technologieunternehmen bieten mittlerweile die OAuth-Integration für Drittentwickler an. Amazon, Netflix, PayPal, Microsoft, LinkedIn, Facebook und viele andere ermöglichen Drittentwicklern, Nutzerkontodaten mithilfe von OAuth in ihre Apps zu integrieren.
Warum wird OAuth verwendet?
Vor OAuth verfügte jeder webbasierte Dienst über separate Anmeldeinformationen für ein Nutzerkonto. Dienste konnten keine Daten austauschen, es sei denn, sie boten eine API an, über die Daten zwischen zwei Stellen ausgetauscht werden konnten. Doch selbst bei einer API stellt die dienstübergreifende Weitergabe von Passwörtern eine Sicherheitslücke dar: Wird nur einer der Dienste kompromittiert, sind die privaten Daten aller offengelegt.
Mit OAuth können Nutzer Drittanbieter-Apps Zugriff auf ihre Konten gewähren, und das für eine Vielzahl von Funktionen. Beispiele hierfür sind die Nutzung von Kalenderdaten zur einfacheren Planung, das Speichern von App-Einstellungen in der Cloud oder sogar die Analyse von Musik-Playlists für neue Empfehlungen. Für die Autorisierung sind keine Passwörter mehr erforderlich, und Nutzer können den Zugriff jederzeit widerrufen.
Entwickler von Drittanbieter-Apps speichern dabei ein Zugriffstoken, um autorisierte Daten abzurufen. Diese Daten müssen zwar auch sicher gespeichert werden, die Anbieter laufen aber nicht Gefahr, Nutzeranmeldeinformationen preiszugeben.
Wie funktioniert OAuth?
An einer erfolgreichen OAuth-Transaktion sind drei Entitäten beteiligt:
- Der Nutzer (die Person oder Organisation, die den Zugriff auf ihre Daten autorisiert)
- Der OAuth-Anbieter (das ist die App oder der Dienst, der die Daten und Anmeldeinformationen des Nutzers speichert)
- Der Dienst (die Anwendung, die Zugriff auf die Daten des Nutzers anfordert)
Es gibt einen definierten OAuth-Workflow, um die Sicherheit der Nutzerdaten zu gewährleisten und Anfragen für den Nutzer zu vereinfachen:
- Zunächst fordert die den Zugriff anfordernde Anwendung (Dienst) ein OAuth-Zugriffstoken vom OAuth-Anbieter an. Sofern der Nutzer noch nicht beim OAuth-Anbieter angemeldet ist, wird er gebeten, dies zu tun.
- Der OAuth-Anbieter listet dann auf, auf welche Arten von Daten die App zugreifen möchte, und fordert den Nutzer auf, den Zugriff zu genehmigen oder zu verweigern.
- Stimmt der Nutzer zu, sendet der OAuth-Anbieter dann ein Zugriffstoken an den Dienst, der es für zukünftige Zugriffsanfragen speichert. Nach der Validierung wird das Zugriffstoken in allen Zugriffsanfragen für die Daten des Nutzers verwendet (im Rahmen der vom Nutzer gewährten Berechtigungen).
Zugriffstokens laufen ab, jedoch können Entwickler Zugriffstokens für zukünftige Anforderungen aktualisieren. Die Gültigkeitsdauer wird vom OAuth-Anbieter festgelegt, sodass die Dauer von dessen Sicherheitsprotokollen abhängt. Das Zugriffstoken muss sicher gespeichert werden, da es von jedem verwendet werden kann, um Nutzerdaten abzurufen und Funktionen im Namen des Nutzers auszuführen.
Sollten Nutzer beschließen, den Zugriff zu widerrufen, können sie dies über den OAuth-Anbieter tun. Nachdem der Zugriff widerrufen wurde, muss der Nutzer sich erneut zu authentifizieren, um auf alle in der Anwendung des Dienstes gespeicherten Daten zugreifen zu können. Wenn der OAuth-Anbieter von einer Datenverletzung betroffen ist, bei der Zugriffstokens offengelegt wurden, kann er zum Schutz der Nutzerdaten proaktiv alle Zugriffstoken für ungültig erklären.
OAuth vs. OpenID
OpenID ist ein Single-Sign-On-Protokoll, das in OAuth integriert ist.
Single Sign-On (SSO) ist eine gängige Sicherheitsstrategie, bei der ein Anbieter die Authentifizierung von Nutzern bei mehreren Diensten übernimmt. OpenID ist eines der ältesten SSO-Protokolle, das 2005 zur Authentifizierung bei LiveJournal eingeführt wurde. Es wurden mittlerweile zwar einige Aktualisierungen vorgenommen; die Implementierung galt jedoch damals als zu schwierig, insbesondere im Vergleich zu anderen Methoden, vor allem Facebook Connect. Da Facebook eine bekannte Marke war, wechselten die meisten Entwickler zu Facebook Connect, damit sich Nutzer bei der Authentifizierung wohler fühlten.
Im Jahr 2014 überarbeitete OpenID seinen Code und wurde später in OAuth integriert. OpenID kümmert sich nun um die Authentifizierung und OAuth um die Autorisierung. Der Prozess läuft für den Nutzer nahtlos ab; die Aufgabenteilung bedeutet jedoch, dass Diensteanbieter OAuth einfacher integrieren können, um Nutzer zu authentifizieren und Zugriff auf ihre Kontodaten zu erhalten.
OAuth vs. SAML
Ein älteres Produkt, das OAuth ähnelt, ist die XML-basierte Security Assertion Markup Language (SAML). Der Hauptunterschied zwischen SAML und OAuth besteht darin, dass SAML sowohl Authentifizierung als auch Autorisierung durchführt. OAuth verwendet OpenID als Authentifizierungsschicht, übernimmt die Authentifizierung jedoch nicht allein. Apps, die SAML verwenden, benötigen keine anderen Dienste zur Authentifizierung.
Ein weiterer Unterschied zwischen den beiden Protokollen ist die Sprache, die zum Übertragen von Daten zwischen Diensten verwendet wird. SAML verwendet XML; OAuth verwendet JSON, das bevorzugte Format für Datenübertragungen. Die meisten Datendienste arbeiten hauptsächlich mit JSON, wodurch OAuth für die meisten Unternehmen einfacher zu integrieren ist.
OAuth 1.0 vs. OAuth 2.0
Wie jedes andere Protokoll hat sich auch OAuth im Laufe der Zeit weiterentwickelt und verbessert. OAuth 2.0 hat OAuth 1.0 (das nicht mehr sicher ist) abgelöst, daher erlauben die meisten Dienstanbieter nur OAuth 2.0 für den Zugriff. OAuth 1.0 ist einfacher zu verwenden und verfügt über einen in mancher Hinsicht einfacheren Workflow. Es gilt jedoch nicht mehr als sicher.
OAuth 2.0 fügte dem Autorisierungsworkflow zwei Schritte hinzu. Es ermöglicht HTTPS und signierte Geheimnisse, sodass Tokens auf Endpunkten (Nutzergeräten) nicht mehr verschlüsselt werden müssen. HTTPS verschlüsselt Zugriffstokens während der Übertragung, obwohl einige Dienste, die persönliche Daten oder andere sensible Daten speichern, Daten im Ruhezustand weiterhin verschlüsseln.
Ein Kritikpunkt an OAuth 2.0 ist, dass es Datenübertragungen über unverschlüsselte Kanäle erlaubt, sodass Entwickler dafür sorgen müssen, dass die TLS/SSL-Verschlüsselung über alle Kanäle hinweg aufrechterhalten wird.
Beispiele für OAuth 2.0
Damit ein Entwickler die Vorteile von OAuth 2.0 nutzen kann, muss es der OAuth-Anbieter auf seinem System implementiert haben. Mehrere große Social-Media-Plattformen verwenden OAuth 2.0, um die Integration ihrer Plattform in andere Apps zu integrieren. Es handelt sich um einen Marketingvorteil, der Plattformbesitzern dabei hilft, eine Fangemeinde für ihre Produkte aufzubauen.
Seit der ersten Veröffentlichung von OAuth 2.0 durch Google nutzen es viele Apps als SSO-Anbieter und als Dienst, der grundlegende Nutzerinformationen bereitstellt. In einem einfachen OAuth-2.0-Workflow bietet der Dienst einen Link zu „Mit Google anmelden“ als Option zum Erstellen eines Kontos an. Wenn der Nutzer bereits authentifiziert ist, zeigt Google eine Liste der Ressourcen und Daten an, auf die der Dienst zugreifen könnte, wenn der Nutzer zustimmt.
Der Nutzer kann die Autorisierungsanfrage des Dienstes zulassen oder ablehnen. Lehnt der Nutzer ab, kann der Dienst nicht auf die Daten des Nutzers zugreifen. Lässt der Nutzer die Datenanfrage zu, generiert der OAuth-Anbieter ein Zugriffstoken. Das Zugriffstoken gewährt die Autorisierung nur für die in der ursprünglichen Anfrage aufgeführten Daten.
Bei den meisten großen Plattformen muss eine App vor dem Zugriff auf bestimmte Daten vom OAuth-Anbieter vorab überprüft werden. Typischerweise legt der Dienst dabei dar, welche Daten er zum Funktionieren benötigt und wie diese Daten verwendet werden. Der OAuth-Anbieter kann die Anfrage im Vorhinein zulassen oder ablehnen.
OAuth wird auch verwendet, um eine Plattform in einen anderen Dienst zu integrieren. Angenommen, Sie haben eine App, die direkt mit dem Google-Produkt funktioniert, beispielsweise Gmail. Um die E-Mails Ihrer Nutzer direkt lesen zu können, benötigen Sie die Erlaubnis des Nutzers. Google verwendet OAuth, um Ihrer App die Interaktion mit dem Gmail-Konto des Nutzers zu ermöglichen. Um Google Gmail in Ihrer App zu nutzen, geben Sie die für die Funktion der App erforderlichen Daten an; Nutzer müssen dann die App für den Zugriff autorisieren.
Ist OAuth sicher?
OAuth ist sicher, wenn es korrekt bereitgestellt wird. Der Dienst muss sicherstellen, dass er über eine Datenberechtigung verfügt; außerdem muss TLS/SSL verwendet werden, um eine sichere Verbindung herzustellen und Daten in verschlüsselter Form zu übertragen. Der OAuth-Anbieter kann eine sichere Datenübertragung gewährleisten, indem er Apps dazu verpflichtet, verschlüsselte Verbindungen zu verwenden und unverschlüsselte Kanäle abzulehnen.
OAuth-Risiken
OAuth ist zwar sicherer als das Teilen von Anmeldeinformationen, aber nicht risikofrei. Hier sind einige Sicherheitslücken, auf die Unternehmen achten sollten, wenn sie Nutzern erlauben, mithilfe von OAuth externe Apps mit ihren Konten zu verbinden.
Phishing
Die Bedrohung durch Phishing ist bei OAuth ein großes Problem. Angreifer verwenden häufig Links zu Webseiten, auf denen Nutzer aufgefordert werden, Anmeldeinformationen einzugeben, um sich bei ihren Konten zu authentifizieren. Die Seite sieht aus wie eine offizielle Seite oder ist einem Dienst, der OAuth verwendet, täuschend ähnlich. Doch anstatt sich bei einem offiziellen Dienst zu authentifizieren, geben Nutzer ihre Anmeldeinformationen auf der Phishing-Website eines Angreifers ein. Nutzer sollten die im Popup-Fenster des Authentifizierungsbrowsers aufgeführte Adresse überprüfen, um sicherzustellen, dass die Website legitim ist.
Im Rahmen einer von uns entdeckten Phishing-Kampagne verschafften sich Angreifer Zugriff auf die Anmeldeinformationen von Microsoft-Nutzern, indem sie URL-Parameter änderten, um Nutzer auf eine Website umzuleiten, die Anmeldeinformationen stiehlt.
Auf der Phishing-Seite wurde dann eine gefälschte Microsoft-Berechtigungsnachricht angezeigt, die den meisten Nutzern bekannt vorkam. Dann wurden Nutzer aufgefordert, sich bei ihrem Microsoft-Konto anzumelden. So erhielten Angreifer jedoch die Anmeldeinformationen für das Microsoft-Konto. Mit diesen Anmeldeinformationen können sie Microsoft-Konten übernehmen, Nutzerdaten abrufen oder Konten bei separaten Diensten kapern, bei denen Nutzer diese Anmeldeinformationen wiederverwendet haben.
Zu weitreichende Berechtigungen
Wenn Nutzer Apps über OAuth installieren und autorisieren, klicken sie häufig auf „Akzeptieren“, ohne den Umfang der Berechtigungen genau zu prüfen. Jede App mit umfassenden Zugriffsberechtigungen stellt ein potenzielles Sicherheitsrisiko für Ihr Unternehmen dar.
Apps von Drittanbietern können leicht ausgenutzt werden. Angreifer können den OAuth-Zugriff nutzen, um Cloud-Konten zu kompromittieren und zu übernehmen. Bis das OAuth-Token explizit widerrufen wird, hat der Angreifer dauerhaften Zugriff auf das Konto und die Daten des Nutzers – selbst wenn der Nutzer das Passwort des Cloud-Kontos ändert oder die Zwei-Faktor-Authentifizierung (2FA) verwendet.
Unsere Recherche ergab, dass viele OAuth-Apps für Office 365 über hohe Berechtigungen verfügen. Hier ist eine Auswahl unserer Ergebnisse:
- 30 % der untersuchten Office-365-Nutzer verfügten über Apps wie MailMerge365 mit der Berechtigung „E-Mails im Namen anderer senden“.
- 30 % der Nutzer verfügten über Apps wie TypeApp mit der Berechtigung „Exchange-Konfiguration verwalten“.
- 70 % der Nutzer verfügen im Durchschnitt über neun Apps, die die Berechtigung „E-Mails im Namen des Nutzers senden“ verwenden (z. B. Task in A Box).
- Microsoft-365-Kunden verfügten im Durchschnitt über 34 Apps mit der Berechtigung „Zugriff auf Nutzerdaten jederzeit“ (wie es bei OneSync der Fall ist).
- Google-Workspace-Kunden mit Drittanbieter-Apps in der Kategorie „Spiele“ verfügen im Durchschnitt über 10 Spiele.
Schädliche OAuth-Apps
Einige Apps und ihre OAuth-Berechtigungsanfragen sind offenkundig bösartig. Unsere Forscher haben beispielsweise eine Angriffskampagne namens OiVaVoii verfolgt, die schädliche Apps unter dem Deckmantel vertrauenswürdiger App-Herausgeber veröffentlicht. So funktioniert es:
- Der Angreifer übernimmt zunächst das Konto des legitimen App-Herausgebers.
- Der Angreifer gibt sich als vertrauenswürdiger Herausgeber aus, erstellt dann eine bösartige App und sendet Autorisierungsanfragen per E-Mail an Nutzer, darunter viele hochrangige Führungskräfte.
- Ahnungslose Nutzer autorisieren die App im Glauben, sie käme vom vertrauenswürdigen Herausgeber.
- Mit der Erteilung der OAuth-Berechtigungen übernimmt der Angreifer die Kontrolle über das Konto des Nutzers.
Im Rahmen dieser Kampagne haben wir die Übernahmen der Konten von CEOs, Geschäftsführern, ehemaligen Vorstandsmitgliedern und Präsidenten festgestellt. Typischerweise ist die Übernahme das Ergebnis bösartiger OAuth-Apps, die OAuth-Tokens oder Anmeldeinformationen stehlen.
Die scheinbar harmlose Identität der Herausgeberorganisation war ein wesentlicher Vorteil und verlockte mehrere ahnungslose Opfer, die bösartigen Apps zu autorisieren. Sie umfassten hauptsächlich den Postfachzugriff (Lesen und Schreiben), der ihnen Folgendes ermöglichte:
- Interne und externe schädliche E-Mails senden.
- Wertvolle Informationen stehlen.
- Postfachregeln erstellen, um Daten an den Angreifer zu senden und nach dem Angriff weiterhin E-Mails der Nutzer zu erhalten.
Abbildung 1: Screenshot der Berechtigungsanfrage einer böswilligen app.
Missbrauch legitimer OAuth-Apps
Contactually ist eine legitime Cloud-App, die Immobilienfachleuten bei der Verwaltung von Kunden und Verkäufen hilft. Doch in den falschen Händen machen es die leistungsstarken Funktionen möglich, dass sich Angreifer problemlos lateral in der Umgebung eines Opfers bewegen und den Zugriff über längere Zeit aufrechterhalten können.
Wir haben eine Kampagne entdeckt, die mit E-Mail-basiertem Phishing begann, um Nutzer innerhalb der Zielorganisationen zu kompromittieren. Mithilfe der kompromittierten Konten autorisierten Angreifer die Contactually-App und richteten Postfachregeln ein, die E-Mails umleiteten oder löschten. Die Regeln waren wahrscheinlich darauf ausgelegt, wertvolle E-Mails an externe Konten weiterzuleiten und Beweise für den Angriff zu löschen.
Contactually ist ein legitimer Herausgeber. Die App verfügt über einige umfassende App-Berechtigungsbereiche, z. B. vollständigen Zugriff auf Nutzerkontakte und Lese-/Schreibzugriff auf deren E-Mails. Diese ähneln jedoch denen, die von jedem E-Mail-Client verwendet werden, und liegen im Rahmen der beworbenen Funktionen der App.
Wenn Angreifer jedoch das Konto kompromittiert und die App in Ihrer Umgebung autorisiert haben – wie sie es in der von uns entdeckten Kampagne getan haben –, können sie diese Funktionen ausnutzen, um dauerhaften Schaden anzurichten.