Sicherer Zugriff auf Web-APIs durch das OAuth-Protokoll
Kommentare

Prüfen eines Requests
Für die Prüfung berechnet der Server seinerseits die Signatur und vergleicht sie mit dem mitgelieferten Wert. Bei Verwendung der Signaturmethoden HMAC-SHA1 und RSA-SHA1 wird außerdem

Prüfen eines Requests

Für die Prüfung berechnet der Server seinerseits die Signatur und vergleicht sie mit dem mitgelieferten Wert. Bei Verwendung der Signaturmethoden HMAC-SHA1 und RSA-SHA1 wird außerdem geprüft, ob ggf. übergebene Werte für Nonce, Timestamp und Token bisher nicht verwendet wurden. Wurde ein Token übergeben, wird der Gültigkeitsbereich und der Status der damit verknüpften Client-Autorisierung überprüft. Ist der Parameter oauth_version vorhanden, wird geprüft, ob sein Wert „1.0“ ist.

Die Sicherheit von OAuth

In der OAuth-Spezifikation RFC 5849 wird eine Reihe von Sicherheitsüberlegungen aufgeführt. Einige davon betreffen tatsächlich mögliche Angriffe, einige dienen eher der „Defense in Depth“-Strategie. Im Folgenden werden nur die möglichen Angriffe behandelt. Die zusätzlichen Maßnahmen werden im zweiten Teil aufgeführt.

Ein in der Praxis nicht zu unterschätzender Punkt fehlt in RFC 5849: Die OAuth-Autorisierung ist unabhängig von den Zugangsdaten des Resource Owners. Ändert er sein Passwort, bleiben die Token Credentials von OAuth weiterhin gültig. Das ist durchaus so gewollt, stellt aber in mindestens zwei Fällen eine mögliche Gefahr dar:

  • Ein Angreifer, der den Account des Resource Owners auf dem Server kompromittiert hat, kann seine eigene Anwendung über OAuth für den Zugriff auf den Account autorisieren. Ändert der Resource Owner später sein Passwort und bemerkt dies die untergeschobene OAuth-Autorisierung nicht, behält der Angreifer den darüber freigegebenen Zugriff.
  • Verwendet eine Organisation OAuth, um ihren Mitgliedern Zugriff auf Bereiche oder Funktionen eines Servers zu gewähren, muss diese Autorisierung für jedes ausscheidende Mitglied widerrufen werden. Wird das vergessen, hat der entsprechende Benutzer weiterhin Zugriff auf die geschützte Resource. Ein Beispiel wäre ein Unternehmen, das einen Mitarbeiter entlässt und dabei vergisst, dessen OAuth-Autorisierung für das CMS der Unternehmenswebsite zu widerrufen. Der Mitarbeiter kann dann weiter Änderungen an der Website seines ehemaligen Arbeitgebers vornehmen.

Aber nun zu den bereits in der Spezifikation aufgeführten möglichen Angriffspunkten:

  • OAuth kümmert sich nicht um die Vertraulichkeit der Requests, lediglich die Integrität wird geschützt. Jeder, der die Request belauschen kann, hat vollen Zugriff auf die übertragenen Daten. Besonders gefährlich sind in dieser Hinsicht offene WLANs, in denen ein Angreifer die Kommunikation leicht belauschen kann. Daher sollte die OAuth-Kommunikation immer über TLS oder SSL geschützt werden. Aber das sollte selbstverständlich sein. Es käme wohl niemand auf die Idee, die Authentifizierungsdaten für den Server ungeschützt zu übertragen. Warum sollte man also bei den Autorisierungsdaten dieses Risiko eingehen?
  • OAuth prüft die Authentizität des Servers nicht. Ein im Rahmen eines Man-in-the-Middle-Angriffs eingeschleuster, gefälschter Server kann daher Schaden anrichten. Auch hier schützen z. B. TLS und SSL vor einem Angriff.
  • Die Redirections können Phishing-Angriffe erleichtern, da sie die Resource Owner an Redirections gewöhnen. Der Serverbetreiber sollte seine Benutzer über diese Gefahr aufklären.
  • Die Autorisierung muss (wie jedes sicherheitsrelevante Formular) vor Cross-Site Request Forgery und Clickjacking geschützt werden. Ohne diesen Schutz besteht die Gefahr, dass ein Angreifer einen Resource Owner durch einen entsprechenden Angriff unerwünschte Autorisierungen für einen bösartigen Client vornehmen lässt.
Unsere Redaktion empfiehlt:

Relevante Beiträge

Meinungen zu diesem Beitrag

X
- Gib Deinen Standort ein -
- or -