Häufige SAML-Schwachstellen und wie Sie sie beheben

Security Assertion Markup Language (SAML) ist ein XML-basiertes Framework, das eine zentrale Rolle bei der sicheren Identitäts- und Zugriffsverwaltung spielt. Es fungiert als vertrauenswürdiger Vermittler zwischen verschiedenen Entitäten in einem digitalen Ökosystem, etwa Identitätsanbietern, Service Providern und Nutzern. SAML dient in erster Linie dazu, Single Sign-on (SSO) zu ermöglichen – einen nahtlosen und effizienten Authentifizierungsprozess, bei dem Nutzer mit einem einzigen Satz an Anmeldedaten auf mehrere Anwendungen und Dienste zugreifen können. SAML bietet zwar viele Vorteile gegenüber der herkömmlichen Authentifizierung mit Nutzername und Passwort, doch abhängig von den folgenden Faktoren können weiterhin Schwachstellen auftreten:

1. der von einem Entwickler verwendeten SAML-Bibliothek

2. den von einem Entwickler verwendeten SAML-Einstellungen

Dieser Blogbeitrag gibt einen kurzen Überblick über häufige SAML-Schwachstellen und zeigt anhand einiger Beispiele, wie Sie diese beheben können.

Häufige SAML-Schwachstellen

Signaturvalidierung und Nachrichtensignierung

Die Validierung von XML-Assertions kann XML-Manipulationsangriffe verhindern. Sie bestätigt die Authentizität von XML-Nachrichten innerhalb von SAML-Assertions. XML Signature Wrapping ist eine Schwachstelle, bei der Schwächen in der Verarbeitung von XML-Signaturen ausgenutzt werden. Dadurch können Daten böswillig manipuliert werden.

Im folgenden Beispiel (VulnerableSAMLApp) werden nach der Authentifizierung als normaler Nutzer die folgenden Informationen im Nutzerprofil angezeigt.

Die Berechtigungen dieses Nutzers lassen sich erweitern, indem die SAML-Anfrage geändert und die Gruppenzugehörigkeit auf Administratoren gesetzt wird.

Um ein solches Problem zu beheben, müssen mehrere Maßnahmen ergriffen werden:

1. Assertions müssen signiert werden. Dadurch wird Ihrem Assertion-Attribut eine Signatur hinzugefügt, die mit dem vertrauenswürdigen Zertifikat signiert ist.

2. Die Werte der Assertions müssen validiert werden, um sicherzustellen, dass die Signaturen mit den Daten in der gesamten Nachricht, einschließlich der Assertion, übereinstimmen.

Die meisten modernen SAML-Bibliotheken bieten Einstellungen, die aktiviert werden können, um das Signieren und Validieren von Nachrichten zu ermöglichen. Ein Beispiel dafür in samlify finden Sie hier: https://github.com/tngan/samlify/blob/master/docs/sp-configuration.md

Schwache Verschlüsselung

Bei der SAML-Authentifizierung müssen bestimmte Teile der SAML-Nachricht verschlüsselt werden, um die Sicherheit und Vertraulichkeit sensibler Daten zu gewährleisten. Insbesondere müssen die SAML-Assertions verschlüsselt werden, da sie Informationen über den Nutzer und dessen Attribute enthalten. Diese Assertions werden zwischen dem Identity Provider (IdP) und dem Service Provider (SP) ausgetauscht, um die Identität und Berechtigungen des Nutzers zu überprüfen.

1const idp = IdentityProvider({
2  isAssertionEncrypted: true,
3  metadata: fs.readFileSync('./metadata_idp.xml'),
4  dataEncryptionAlgorithm: 'http://www.w3.org/2001/04/xmlenc#aes256-cbc',
5  keyEncryptionAlgorithm: 'http://www.w3.org/2001/04/xmlenc#rsa-1_5' 
6});
7An example on setting the encryption on an IdentityProvider when using Samilify: https://github.com/tngan/samlify/blob/master/docs/encrypted-saml-response.md

Ablauf von Nachrichten

SAML-Nachrichten sind standardmäßig anfällig für Replay-Angriffe. Bei einem Replay-Angriff wird eine gültige, abgefangene SAML-Nachricht unbefugt erneut verwendet, um eine legitime SAML-Aktion vorzutäuschen, etwa Single Sign-on (SSO) oder Single Logout (SLO). Mit „NotBefore“ und „NotOnOrAfter“ lassen sich diese Angriffe verhindern.

• NotBefore (Attribut): Dieses Attribut gibt den frühesten Zeitpunkt an, ab dem die SAML-Assertion als gültig betrachtet werden kann. Mit anderen Worten: Die Assertion darf vor dem angegebenen Zeitpunkt „NotBefore“ nicht zur Authentifizierung oder Autorisierung verwendet werden. So wird verhindert, dass die Assertion vorzeitig zum Einsatz kommt – besonders wichtig bei zeitkritischen Vorgängen. Vor dem Zeitpunkt „NotBefore“ gilt die Assertion in der Regel als ungültig.

• NotOnOrAfter (Attribut): Dieses Attribut gibt den spätesten Zeitpunkt an, bis zu dem die SAML-Assertion gültig bleibt. Nach Ablauf des Zeitpunkts „NotOnOrAfter“ darf die Assertion nicht mehr zur Authentifizierung oder Autorisierung verwendet werden. Diese zeitliche Begrenzung hilft, den Missbrauch veralteter Assertions zu verhindern, die möglicherweise abgefangen oder auf böswillige Weise erlangt wurden.

Offene Weiterleitungen

SAML ist von Natur aus ein asynchrones Protokoll. Wenn ein vom SP initiierter Anmeldevorgang beginnt, erstellt der SP eine SAML-Authentifizierungsanfrage und leitet sie an den Identity Provider (IdP) weiter. Dabei speichert der Service Provider keine Informationen über die Anfrage. Wenn die SAML-Antwort vom IdP eintrifft, weiß der Service Provider daher nicht, welcher ursprüngliche Deep Link die Authentifizierungsanfrage ausgelöst hat. SAML löst dieses Problem mit einem wichtigen Parameter namens „RelayState“.

RelayState ist ein HTTP-Parameter, der sowohl in die SAML-Anfrage als auch in die SAML-Antwort aufgenommen werden kann. Bei einem vom SP initiierten Anmeldevorgang kann der SP den Parameter RelayState verwenden, um zusätzliche Informationen in die SAML-Anfrage einzubetten. So bleiben wichtige Kontextinformationen und Daten während des asynchronen Vorgangs erhalten. Ein Angreifer kann den Parameter RelayState jedoch für offene Weiterleitungsangriffe missbrauchen.

Um offene Weiterleitungsangriffe zu verhindern, müssen Sie vor der Weiterleitung prüfen, ob der Wert von RelayState eine vertrauenswürdige URL ist. Ein Beispiel finden Sie in der Dokumentation der Maintainer der Bibliothek python3-saml.

Fazit

In diesem Beitrag haben wir uns einige Beispiele für häufige SAML-Schwachstellen und deren Behebung angesehen. Je nach verwendeter SAML-Bibliothek und verwendetem Identity Provider können die Maßnahmen jedoch unterschiedlich aussehen oder in manchen Fällen gar nicht möglich sein. Prüfen Sie daher die Dokumentation dieser Bibliotheken und Drittanbieter, um herauszufinden, wie sich solche Schwachstellen wirksam verhindern lassen.

SAML bietet zwar ein Framework für die sichere Identitäts- und Zugriffsverwaltung, doch OpenID Connect (OIDC) kann eine gute Alternative zu SAML sein, da es kein XML verwendet. OIDC ist eine moderne Identitätsschicht auf Basis von OAuth 2.0 und JWT. Statt XML-basierter Assertions nutzt OIDC JSON Web Tokens (JWTs), um Identitätsinformationen zu übermitteln. Dadurch eignet es sich besser für moderne Web- und Mobilanwendungen. OIDC vereinfacht die Integration und bietet Funktionen wie das Abrufen von Nutzerprofilinformationen. Das macht es zu einer attraktiven Option für Entwickler, die sich nicht mit XML-Sicherheit befassen möchten. Viele der in diesem Blogbeitrag erwähnten Angriffe sind auf OIDC nicht anwendbar. Daher könnte OIDC eine sinnvolle Alternative sein, die Sie in Betracht ziehen sollten, denn mit seiner Einführung lassen sich einige der mit SAML verbundenen Komplexitäten vermeiden.