Bundesamt für Sicherheit in der Informationstechnik

G 5.181 Angriffe auf das Identitäts- und Zugriffsmanagement bei Web-Services

Um angebotene Web-Services vor einem missbräuchlichen Zugriff zu schützen, müssen entsprechende Zugriffsschutzmechanismen umgesetzt sein, die die Identität eines aufrufenden Benutzers oder Dienstes prüfen und den Zugriff wirksam verwehren, wenn dem Benutzer oder Dienst die Berechtigung zum Aufruf des Dienstes fehlt. Dabei kann die Berechtigung auch abhängig sein von den übergebenen Parametern: So ist es zum Beispiel denkbar, dass ein Kunde nur Daten zu den eigenen Aufträgen abfragen darf, oder ein Berechtigungsverwalter nur Mitarbeiter seiner eigenen Institution mit Berechtigungen ausstatten kann.

Der erste mögliche Ansatzpunkt für einen Angreifer ist das verwendete Zugriffsschutzsystem selbst. Findet der Angreifer Fehler in der Berechtigungsprüfung, so kann er diese ausnutzen, um sich unbefugten Zugriff zu verschaffen. Dies ist insbesondere der Fall, wenn Berechtigungsprüfungen nicht umgesetzt werden, weil die Entwickler implizite Annahmen darüber machen, wer die Services in welchem Kontext aufruft. Dass eine Funktion innerhalb einer Anwendung erst nach erfolgreicher Anmeldung zur Verfügung steht, heißt aber nicht, dass der dahinterstehende Web-Service von einem Angreifer nicht auch außerhalb des Anwendungskontextes aufgerufen werden kann.

Wird innerhalb einer serviceorientierten Architektur ( SOA ) die Zugriffskontrolle manipuliert, können Angreifer unberechtigte Informationen über Dienste der SOA -Infrastruktur erhalten.

Nutzt das Zugriffsschutzsystem für die Berechtigungsprüfung Informationen aus einer externen Quelle, zum Beispiel einem Verzeichnisdienst, so kann ein Angreifer auch versuchen, die Berechtigungsinformationen in der externen Quelle zu manipulieren oder dem Zugriffsschutzsystem falsche oder manipulierte Berechtigungsdaten unterzuschieben, zum Beispiel durch einen Man-in-the-Middle-Angriff (siehe G 5.143 Man-in-the-Middle-Angriff ).

Ein zweiter Angriffspunkt ist die Identität des aufrufenden Benutzers oder Dienstes. Gelingt es dem Angreifer, einen Dienstaufruf mit der Identität eines berechtigten Benutzers oder Dienstes zu initiieren, so kann er effektiv dessen Berechtigungen für die Durchführung seines Angriffs missbrauchen.

Ein solcher Identitätsdiebstahl kann beispielsweise durch eine schwache Implementierung des Sitzungsmanagements möglich werden: "Session Hijacking" oder "Session Fixation" (siehe G 5.169 Unzureichendes Session-Management von Webanwendungen und Web-Services ). Ziel eines Session-Hijacking-Angriffs ist es, Nutzerprivilegien für ein System, einen Dienst oder eine Anwendung zu erhalten. Manche Web-Services verwenden für ihre Sessions eine eindeutige Identifikationsnummer. Gelingt es einem Angreifer, Nachrichten mit einer solchen Session-ID abzufangen, kann er an der entsprechenden Transaktion teilnehmen.

Andere Angriffsarten umfassen das Mitschneiden von Nachrichten und das Wiedereinspielen der aufgezeichneten Nachrichten (mit gültigen Authentisierungsinformationen des originalen Absenders) in einem anderen Kontext ("Replay-Attacken"). Bei einer Replay-Attacke werden Nachrichten, die von einem Web-Service akzeptiert wurden, nochmals verwendet. Ein Angreifer fängt dazu in der Regel valide Nachrichten von Benutzern ab und sendet sie erneut an den Web-Service. Replay-Angriffe werden meist als Basis für weitere Angriffe wie zum Beispiel Denial-of-Service- oder Man-in-the-Middle-Attacken benutzt. Häufig dienen sie Angreifern dazu, Authentisierungsmechanismen zu umgehen. Sofern hiergegen keine Schutzmaßnahmen vorgesehen sind, kann der Angreifer dabei gegebenenfalls sogar verschlüsselte Nachrichten abfangen und verwenden, ohne dass er die eingesetzte Verschlüsselung brechen muss.

Schließlich können auch externe, vom Web-Service genutzte Identitätsmanagement-Dienste angegriffen werden mit dem Ziel, sich gegenüber dem Web-Service wirksam als ein berechtigter Service-Consumer auszuweisen. Bei fehlenden Mechanismen zur Diensteauthentisierung kann der Angreifer dabei auch entweder gegenüber dem Web-Service oder dem Service-Consumer einen eigenen Identitäts-Dienst einsetzen und so entweder dem Dienst eine falsche Identität vorgaukeln oder den legitimen Benutzer zur Preisgabe von Authentisierungsdaten bewegen.

Stand: 15. EL Stand 2016