Bundesamt für Sicherheit in der Informationstechnik

M 4.456 Authentisierung bei Web-Services

Verantwortlich für Initiierung: IT-Sicherheitsbeauftragter, Verantwortliche der einzelnen Anwendungen, Leiter IT

Verantwortlich für Umsetzung: Administrator, Entwickler

Um den Zugriff auf einen Web-Service auf einen berechtigten Personenkreis einzugrenzen oder unterschiedliche Berechtigungen innerhalb eines Web-Service zu realisieren (vergleiche M 4.455 Autorisierung bei Web-Services ) ist es notwendig, die Benutzer, die auf den Dienst zugreifen, eindeutig zu identifizieren und zu authentisieren. Umgekehrt muss der Benutzer eines Web-Service sicherstellen können, dass er tatsächlich mit dem gewünschten Dienst kommuniziert.

Die Authentisierung muss dabei erfolgen, bevor schützenswerte Informationen übertragen werden. Dies bedeutet, dass der Benutzer eines Web-Service sicherstellen muss, dass er tatsächlich mit dem gewünschten Web-Service kommuniziert, bevor er eine Anfrage mit vertraulichen Informationen an den Dienst sendet. Umgekehrt muss ein Web-Service die Identität des anfragenden Benutzers oder Web-Services prüfen, bevor er vertrauliche Informationen an diesen zurücksendet oder dem Benutzer Berechtigungen zum Aufruf von Funktionen erteilt (siehe M 4.455 Autorisierung bei Web-Services ).

Die Authentisierung von Kommunikationspartnern kann auf unterschiedlichen Ebenen umgesetzt werden. Eine Möglichkeit ist etwa die Authentisierung auf Transportebene mittels SSL-/TLS . Dies wird häufig auch als Transport Layer Authentication bezeichnet. Eine andere Möglichkeit ist die Authentisierung auf Nachrichtenebene, zum Beispiel mittels der Mechanismen aus den WS-Security-Standards. Sollen nicht nur einzelne Nachrichten, sondern ein komplexerer Nachrichtenaustausch authentisiert werden, so empfiehlt es sich, ein entsprechendes Session-Management einzuführen (vergleiche M 4.394 Session-Management bei Webanwendungen und Web-Services ).

Identitätsmanagement

Um die Benutzer von Web-Services zu authentisieren, ist es notwendig, Benutzerdaten zu erfassen und die zugehörigen Identifikationsmerkmale zu hinterlegen. Diese Vorgänge sind Teil des sogenannten Identitätsmanagements (engl. Identity Management).

Der klassische Anwendungsfall ist dabei, dass jeder Anbieter eines Web-Service seine eigene Benutzerverwaltung betreibt und die Authentisierung selbst vornimmt. Hierbei spricht man von isoliertem Identitätsmanagement. Bei diesem Modell kommuniziert der Benutzer ausschließlich mit dem gewünschten Web-Service. Bei der Nutzung weiterer Web-Services muss seine Identität dort jeweils eigenständig verwaltet werden.

Kommen Web-Services in service-orientierten Architekturen ( SOA ) zum Einsatz, so handelt es sich zumeist um komplexe Systeme, die oft nicht mehr der Kontrolle einer einzelnen Institution unterliegen. Es ist dann meistens nicht mehr möglich, die Identitäten durch die Betreiber der einzelnen Dienste verwalten zu lassen. Diese Aufgabe wird stattdessen von spezialisierten Organisationen oder Organisationseinheiten, den Identitätsanbietern (engl. Identity Providers) übernommen.

Beim zentralisierten Identitätsmanagement existiert ein solcher Identitätsanbieter, der das Identitätsmanagement für eine Vielzahl an Dienstanbietern übernimmt. Beispiele für diese Art von Identitätsmanagement sind Dienste von Anbietern wie Microsoft, Facebook oder Google, oder aber der Einsatz eines zentralen Authentisierungssystems innerhalb eines Unternehmens. Zentralisierte Identitätsmanagementsysteme bieten oftmals Single-Sign-On-Funktionalität: Der Benutzer muss sich lediglich gegenüber einem Identitätsanbieter authentisieren, um die Dienste verschiedener Dienstanbieter in Anspruch zu nehmen.

Die dritte Variante des Identitätsmanagements ist das föderierte Identitätsmanagement (engl. Federated Identity Management). In dieser Variante existieren mehrere Identitätsanbieter. Die Authentisierung der Benutzer erfolgt über standardisierte Schnittstellen und Protokolle. Für Web-Services ist hier vor allem die Spezifikation WS-Federation von Bedeutung. Konkrete Technologien, die zur Umsetzung dieser Spezifikation verwendet werden können, sind die Security Assertion Markup Language ( SAML ) und OpenID.

Art der eingesetzten Indikatoren

Die Authentisierung der Teilnehmer an einer Web-Service-Kommunikation erfolgt über den Nachweis von eindeutig einer Identität zuzuordnenden Merkmalen, sogenannten Identifikatoren. Übliche Identifikatoren sind dabei Benutzernamen mit Passwörtern, Zertifikate und Signaturen, sowie kryptographisch gesicherte Datensätze (Token) eines Identitätsanbieters oder eines Security-Token-Services, wie er im Rahmen von WS-Trust spezifiziert ist (vergleiche M 4.453 Einsatz eines Security Token Service (STS) ). Verschiedene Authentisierungsverfahren sind im Folgenden dargestellt. Für den Web-Service muss hier ein Verfahren ausgewählt werden, dessen Sicherheit dem Schutzbedarf gerecht wird.

Ein Beispiel für eine sehr einfache Authentisierung mit Hilfe von Benutzernamen und Passwörtern ist der Einsatz von HTTP Basic Authentication. Diese lässt sich sowohl für Web-Services auf Basis von REST als auch für SOAP -basierte Web-Services verwenden, bietet allerdings nur ein geringes Maß an Schutz der Authentisierungsdaten und muss daher durch zusätzliche Sicherheitsmaßnahmen wie etwa eine Transportverschlüsselung ergänzt werden. Ein weiteres Beispiel ist die Verwendung eines Username Tokens beim Einsatz von WS-Security.

Besseren Schutz bieten verschiedene Möglichkeiten, um Web-Service-Nachrichten mittels Zertifikaten und Signaturen zu authentisieren. Zumeist kommen XML-Signaturen gemäß der XMLDSIG-Spezifikation zum Einsatz. Einer der Vorteile des Einsatzes von Signaturen zur Authentisierung ist, dass die Authentisierung auf Nachrichtenebene stattfindet. Dadurch kann gegebenenfalls auf eine Sitzungsverwaltung (Session Management) verzichtet werden, da jede Nachricht einzeln durch eine Signatur authentisiert werden kann. Der Nachteil dieser Vorgehensweise sind Leistungseinbußen durch die Erzeugung, Übertragung und Verifikation einer Signatur für jede einzelne Nachricht. Darüber hinaus erfordert der Einsatz von Signaturen die Nutzung einer Public Key Infrastruktur ( PKI ).

Bei XML-Signaturen muss sichergestellt werden, dass sich die Signatur tatsächlich auf die vom Dienst zu verarbeitenden Daten bezieht. Ist dies nicht der Fall, werden so genannte XML Signature Wrapping-Angriffe möglich (siehe G 5.183 Angriffe auf XML ). Bei diesem Angriff werden gültige, signierte XML -Daten in ein von einem Angreifer manipuliertes XML -Dokument eingebettet. Wenn nun die Funktionen zur Verifikation der Signatur und die eigentliche Anwendungslogik die XML -Daten auf unterschiedliche Art und Weise verarbeiten, kann eine Situation entstehen, bei der die Signatur für die ursprünglichen eingebetteten Daten überprüft wird, auf Anwendungsebene aber die manipulierten Daten verarbeitet werden.

Eine weitere Möglichkeit zur Authentisierung der Teilnehmer einer Web-Service-Kommunikation ist die Authentisierung mittels Token, die von vertrauenswürdigen Dritten ausgestellt wurden. Als Token wird hierbei eine Datenstruktur bezeichnet, die die Identität des Tokeninhabers bestätigt. Die Integrität und Authentizität des Tokens selbst muss wiederum durch kryptografische Maßnahmen sichergestellt werden. Beispiele für häufig im Rahmen von Web-Service-Kommunikation eingesetzte Token sind SAML oder OAuth-Token.

Beim Zugriff von Benutzern auf Web-Services mit erhöhtem Schutzbedarf kann es erforderlich sein, eine starke Authentisierung unter Verwendung mehrerer Authentisierungsmerkmale (zum Beispiel der Besitz einer Chipkarte und die Kenntnis der dazugehörigen PIN) zu realisieren. Werden für eine solche Mehrfaktorauthentisierung voneinander unabhängige Authentisierungsmerkmale verwendet, so wird die Wahrscheinlichkeit, dass ein Angreifer alle erforderlichen Merkmale unter seine Kontrolle bekommt, stark verringert.

Werden kryptografische Algorithmen zur Authentisierung eingesetzt, beispielsweise für Hashing-Verfahren oder Signaturen, muss sichergestellt werden, dass diese dem Stand der Technik entsprechen. Hierzu sollten die entsprechenden Maßnahmen des Bausteins B 1.7 Kryptokonzept umgesetzt werden.

Gesicherte Übertragung von Authentisierungsdaten

Die Übertragung von Identifikatoren muss auf angemessene Art und Weise geschützt werden, sodass ein Angreifer die Identifikatoren nicht nutzen kann, um sich als legitimier Benutzer oder Anbieter eines Web-Service auszugeben. Die notwendigen Schutzmechanismen hängen von der Art des genutzten Identifikators ab. Bei der Übertragung von Benutzernamen und Passwörtern muss die Vertraulichkeit gewährleistet werden, beispielsweise durch eine Transportverschlüsselung oder eine Verschlüsselung der einzelnen Web-Service-Nachrichten.

Darüber hinaus müssen die Authentisierungsdaten vor Wiedereinspielung (Replay-Angriffe) und Weiterleitung (Relay-Angriffe) geschützt werden. Dies erfolgt üblicherweise durch Zeitstempel in der Nachricht, beispielsweise über ein wsu:Timestamp- Element beim Einsatz von WS-Security, oder durch die Verwendung von Einmal-Zufallszahlen (Nonce), beispielsweise in Form eines wsse:Nonce- Elements. Bei der Verwendung von Noncen muss sichergestellt werden, dass die Zufallszahlen keinesfalls mehrfach verwendet werden. Ein Schutz vor Relay-Angriffen kann durch explizite, vor Manipulationen geschützte Angabe des Empfängers einer Nachricht realisiert werden.

Prüffragen:

  • Erfolgt in der Kommunikation zwischen Web-Service und Web-Service-Nutzer eine gegenseitige Authentisierung, bevor der Gegenseite vertrauliche Informationen übermittelt oder Zugriffe auf Funktionen gewährt werden?

  • Werden ausreichend starke Verfahren zur Authentisierung eingesetzt?

  • Werden Passwörter ausschließlich verschlüsselt übertragen?

  • Wird beim Einsatz von XML-Signaturen sichergestellt, dass sich die Signatur tatsächlich auf die auf der Anwendungsebene verarbeiteten Daten bezieht, um XML Signature Wrapping-Angriffe zu verhindern?

  • Sind für die Authentisierung genutzte kryptographische Verfahren im Kryptokonzept der Institution berücksichtigt?

  • Sind Schutzmaßnahmen gegen die Wiedereinspielung und Weiterleitung von Identifikatoren umgesetzt?

Stand: 14. EL Stand 2014