Mirrors/hacktricks
2
0
Fork 0
mirror of https://github.com/carlospolop/hacktricks synced 2024-11-26 22:52:06 +00:00
Code Issues Projects Releases Packages Wiki Activity
hacktricks/pentesting-web/saml-attacks/saml-basics.md
Translator workflow 6af5d4e1a0 Translated to German
2024-02-10 15:36:32 +00:00

10 KiB
Raw Blame History

Lernen Sie AWS-Hacking von Null auf Held mit htARTE (HackTricks AWS Red Team Expert)!

Andere Möglichkeiten, HackTricks zu unterstützen:

SAML-Übersicht

Security Assertion Markup Language (SAML) ermöglicht es Identitätsanbietern (IdP), Autorisierungsinformationen an Dienstanbieter (SP) zu senden und Single Sign-On (SSO) zu ermöglichen. Dieser Ansatz vereinfacht die Verwaltung mehrerer Anmeldungen, indem ein Satz von Anmeldeinformationen für mehrere Websites verwendet wird. Es nutzt XML für die standardisierte Kommunikation zwischen IdPs und SPs und verknüpft die Authentifizierung der Benutzeridentität mit der Dienstautorisierung.

Vergleich zwischen SAML und OAuth

  • SAML ist darauf ausgerichtet, Unternehmen eine größere Kontrolle über die Sicherheit der SSO-Anmeldung zu bieten.
  • OAuth ist darauf ausgelegt, mobiler zu sein, verwendet JSON und ist eine gemeinsame Anstrengung von Unternehmen wie Google und Twitter.

SAML-Authentifizierungsablauf

Für weitere Details lesen Sie den vollständigen Beitrag unter https://epi052.gitlab.io/notes-to-self/blog/2019-03-07-how-to-test-saml-a-methodology/. Hier eine Zusammenfassung:

Der SAML-Authentifizierungsprozess umfasst mehrere Schritte, wie im Schema dargestellt:

https://epi052.gitlab.io/notes-to-self/img/saml/saml-flow.jpg

  1. Ressourcenzugriffsversuch: Der Benutzer versucht auf eine geschützte Ressource zuzugreifen.
  2. Generierung der SAML-Anforderung: Der SP erkennt den Benutzer nicht und generiert eine SAML-Anforderung.
  3. Weiterleitung an IdP: Der Benutzer wird mit der SAML-Anforderung über den Browser des Benutzers an den IdP weitergeleitet.
  4. IdP empfängt Anforderung: Der IdP empfängt die SAML-Anforderung.
  5. Authentifizierung beim IdP: Der IdP authentifiziert den Benutzer.
  6. Benutzerüberprüfung: Der IdP überprüft die Legitimität des Benutzers, um auf die angeforderte Ressource zuzugreifen.
  7. Erstellung der SAML-Antwort: Der IdP generiert eine SAML-Antwort mit den erforderlichen Aussagen.
  8. Weiterleitung an SP's ACS-URL: Der Benutzer wird an die Assertion Consumer Service (ACS)-URL des SP weitergeleitet.
  9. Validierung der SAML-Antwort: Der ACS validiert die SAML-Antwort.
  10. Ressourcenzugriff gewährt: Zugriff auf die ursprünglich angeforderte Ressource wird gewährt.

Beispiel für eine SAML-Anforderung

Betrachten Sie das Szenario, in dem ein Benutzer Zugriff auf eine sichere Ressource unter https://shibdemo-sp1.test.edu/secure/ beantragt. Der SP erkennt das Fehlen einer Authentifizierung und generiert eine SAML-Anforderung:

GET /secure/ HTTP/1.1
Host: shibdemo-sp1.test.edu
...

Die rohe SAML-Anfrage sieht folgendermaßen aus:

<?xml version="1.0"?>
<samlp:AuthnRequest ...
</samlp:AuthnRequest>

Wichtige Elemente dieser Anfrage sind:

  • AssertionConsumerServiceURL: Gibt an, wohin der IdP die SAML-Antwort nach der Authentifizierung senden soll.
  • Destination: Die Adresse des IdP, an die die Anfrage gesendet wird.
  • ProtocolBinding: Definiert die Übertragungsmethode für SAML-Protokollnachrichten.
  • saml:Issuer: Identifiziert die Entität, die die Anfrage initiiert hat.

Nach der Generierung der SAML-Anfrage antwortet der SP mit einer 302-Weiterleitung, die den Browser zum IdP mit der SAML-Anfrage im HTTP-Antwort-Header Location leitet. Der Parameter RelayState enthält Informationen zum Zustand während der Transaktion und stellt sicher, dass der SP die ursprüngliche Ressourcenanfrage erkennt, wenn er die SAML-Antwort erhält. Der Parameter SAMLRequest ist eine komprimierte und codierte Version des Roh-XML-Snippets, die die Deflate-Komprimierung und die Base64-Codierung verwendet.

Beispiel für eine SAML-Antwort

Eine vollständige SAML-Antwort finden Sie hier. Die wichtigsten Bestandteile der Antwort sind:

  • ds:Signature: Dieser Abschnitt, eine XML-Signatur, gewährleistet die Integrität und Authentizität des Ausstellers der Aussage. Die SAML-Antwort im Beispiel enthält zwei ds:Signature-Elemente, eines für die Nachricht und eines für die Aussage.
  • saml:Assertion: Dieser Teil enthält Informationen zur Identität des Benutzers und möglicherweise andere Attribute.
  • saml:Subject: Es gibt den Hauptgegenstand aller Aussagen in der Aussage an.
  • saml:StatusCode: Stellt den Status des Vorgangs in Reaktion auf die entsprechende Anfrage dar.
  • saml:Conditions: Details zu Bedingungen wie der Gültigkeitszeit der Aussage und dem angegebenen Service Provider.
  • saml:AuthnStatement: Bestätigt, dass der IdP den Gegenstand der Aussage authentifiziert hat.
  • saml:AttributeStatement: Enthält Attribute, die den Gegenstand der Aussage beschreiben.

Nach der SAML-Antwort erfolgt eine 302-Weiterleitung vom IdP. Dies führt zu einer POST-Anfrage an die Assertion Consumer Service (ACS) URL des Service Providers. Die POST-Anfrage enthält die Parameter RelayState und SAMLResponse. Der ACS ist für die Verarbeitung und Validierung der SAML-Antwort verantwortlich.

Nachdem die POST-Anfrage empfangen und die SAML-Antwort validiert wurde, wird der Zugriff auf die geschützte Ressource gewährt, die vom Benutzer ursprünglich angefordert wurde. Dies wird mit einer GET-Anfrage an den Endpunkt /secure/ und einer 200 OK-Antwort veranschaulicht, die einen erfolgreichen Zugriff auf die Ressource anzeigt.

XML-Signaturen

XML-Signaturen sind vielseitig einsetzbar und können einen gesamten XML-Baum oder bestimmte Elemente darin signieren. Sie können auf jedes XML-Objekt angewendet werden, nicht nur auf Response-Elemente. Im Folgenden sind die wichtigsten Arten von XML-Signaturen aufgeführt:

Grundstruktur einer XML-Signatur

Eine XML-Signatur besteht aus den folgenden wesentlichen Elementen:

<Signature>
<SignedInfo>
<CanonicalizationMethod />
<SignatureMethod />
<Reference>
<Transforms />
<DigestMethod />
<DigestValue />
</Reference>
...
</SignedInfo>
<SignatureValue />
<KeyInfo />
<Object />
</Signature>

Jedes Reference-Element kennzeichnet eine bestimmte Ressource, die signiert wird und durch das URI-Attribut identifizierbar ist.

Arten von XML-Signaturen

  1. Enveloped Signature: Diese Art der Signatur ist ein Nachkomme der Ressource, die sie signiert, was bedeutet, dass die Signatur in der gleichen XML-Struktur wie der signierte Inhalt enthalten ist.

Beispiel:

<samlp:Response ... ID="..." ... >
...
<ds:Signature>
<ds:SignedInfo>
...
<ds:Reference URI="#...">
...
</ds:Reference>
</ds:SignedInfo>
</ds:Signature>
...
</samlp:Response>

Bei einer enveloped signature gibt das ds:Transform-Element an, dass es durch den enveloped-signature-Algorithmus umschlossen ist.

  1. Enveloping Signature: Im Gegensatz zu enveloped signatures umschließen enveloping signatures die signierte Ressource.

Beispiel:

<ds:Signature>
<ds:SignedInfo>
...
<ds:Reference URI="#...">
...
</ds:Reference>
</ds:SignedInfo>
<samlp:Response ... ID="..." ... >
...
</samlp:Response>
</ds:Signature>
  1. Detached Signature: Diese Art ist von dem Inhalt, den sie signiert, getrennt. Die Signatur und der Inhalt existieren unabhängig voneinander, aber eine Verbindung zwischen den beiden wird aufrechterhalten.

Beispiel:

<samlp:Response ... ID="..." ... >
...
</samlp:Response>
<ds:Signature>
<ds:SignedInfo>
...
<ds:Reference URI="#...">
...
</ds:Reference>
</ds:SignedInfo>
</ds:Signature>

Zusammenfassend bieten XML-Signaturen flexible Möglichkeiten, XML-Dokumente abzusichern, wobei jeder Typ unterschiedliche strukturelle und sicherheitstechnische Anforderungen erfüllt.

Referenzen

Lernen Sie AWS-Hacking von Grund auf mit htARTE (HackTricks AWS Red Team Expert)!

Andere Möglichkeiten, HackTricks zu unterstützen: