9.7 KiB
{% hint style="success" %}
Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
Support HackTricks
- Check the subscription plans!
- Join the 💬 Discord group or the telegram group or follow us on Twitter 🐦 @hacktricks_live.
- Share hacking tricks by submitting PRs to the HackTricks and HackTricks Cloud github repos.
SAML Overview
Security Assertion Markup Language (SAML) permet aux fournisseurs d'identité (IdP) d'être utilisés pour envoyer des informations d'autorisation aux fournisseurs de services (SP), facilitant ainsi l'authentification unique (SSO). Cette approche simplifie la gestion de plusieurs connexions en permettant d'utiliser un seul ensemble d'identifiants sur plusieurs sites web. Elle utilise XML pour une communication standardisée entre les IdP et les SP, liant l'authentification de l'identité de l'utilisateur à l'autorisation de service.
Comparison between SAML and OAuth
- SAML est conçu pour offrir aux entreprises un meilleur contrôle sur la sécurité des connexions SSO.
- OAuth est conçu pour être plus adapté aux mobiles, utilise JSON et est un effort collaboratif d'entreprises comme Google et Twitter.
SAML Authentication Flow
Pour plus de détails, consultez le post complet de https://epi052.gitlab.io/notes-to-self/blog/2019-03-07-how-to-test-saml-a-methodology/. Voici un résumé :
Le processus d'authentification SAML implique plusieurs étapes, comme illustré dans le schéma :
- Tentative d'accès à la ressource : L'utilisateur essaie d'accéder à une ressource protégée.
- Génération de la demande SAML : Le SP ne reconnaît pas l'utilisateur et génère une demande SAML.
- Redirection vers l'IdP : L'utilisateur est redirigé vers l'IdP, la demande SAML passant par le navigateur de l'utilisateur.
- L'IdP reçoit la demande : L'IdP reçoit la demande SAML.
- Authentification à l'IdP : L'IdP authentifie l'utilisateur.
- Validation de l'utilisateur : L'IdP valide la légitimité de l'utilisateur à accéder à la ressource demandée.
- Création de la réponse SAML : L'IdP génère une réponse SAML contenant les assertions nécessaires.
- Redirection vers l'URL ACS du SP : L'utilisateur est redirigé vers l'URL du Service Consommateur d'Assertions (ACS) du SP.
- Validation de la réponse SAML : L'ACS valide la réponse SAML.
- Accès à la ressource accordé : L'accès à la ressource initialement demandée est accordé.
SAML Request Example
Considérons le scénario où un utilisateur demande l'accès à une ressource sécurisée à https://shibdemo-sp1.test.edu/secure/. Le SP identifie l'absence d'authentification et génère une demande SAML :
GET /secure/ HTTP/1.1
Host: shibdemo-sp1.test.edu
...
La requête SAML brute ressemble à ceci :
<?xml version="1.0"?>
<samlp:AuthnRequest ...
</samlp:AuthnRequest>
Key elements of this request include:
- AssertionConsumerServiceURL: Spécifie où l'IdP doit envoyer la réponse SAML après l'authentification.
- Destination: L'adresse de l'IdP à laquelle la demande est envoyée.
- ProtocolBinding: Définit la méthode de transmission des messages du protocole SAML.
- saml:Issuer: Identifie l'entité qui a initié la demande.
Following the SAML Request generation, the SP responds with a 302 redirect, directing the browser to the IdP with the SAML Request encoded in the HTTP response's Location header. The RelayState parameter maintains the state information throughout the transaction, ensuring the SP recognizes the initial resource request upon receiving the SAML Response. The SAMLRequest parameter is a compressed and encoded version of the raw XML snippet, utilizing Deflate compression and base64 encoding.
SAML Response Example
You can find a full SAML response here. The key components of the response include:
- ds:Signature: Cette section, une signature XML, garantit l'intégrité et l'authenticité de l'émetteur de l'assertion. La réponse SAML dans l'exemple contient deux éléments
ds:Signature
, un pour le message et l'autre pour l'assertion. - saml:Assertion: Cette partie contient des informations sur l'identité de l'utilisateur et éventuellement d'autres attributs.
- saml:Subject: Elle spécifie le sujet principal de toutes les déclarations dans l'assertion.
- saml:StatusCode: Représente le statut de l'opération en réponse à la demande correspondante.
- saml:Conditions: Détails des conditions comme la durée de validité de l'assertion et le fournisseur de services spécifié.
- saml:AuthnStatement: Confirme que l'IdP a authentifié le sujet de l'assertion.
- saml:AttributeStatement: Contient des attributs décrivant le sujet de l'assertion.
Following the SAML Response, the process includes a 302 redirect from the IdP. This leads to a POST request to the Service Provider's Assertion Consumer Service (ACS) URL. The POST request includes RelayState
and SAMLResponse
parameters. The ACS is responsible for processing and validating the SAML Response.
After the POST request is received and the SAML Response is validated, access is granted to the protected resource initially requested by the user. This is illustrated with a GET
request to the /secure/
endpoint and a 200 OK
response, indicating successful access to the resource.
XML Signatures
XML Signatures are versatile, capable of signing an entire XML tree or specific elements within it. They can be applied to any XML Object, not just Response elements. Below are the key types of XML Signatures:
Basic Structure of XML Signature
An XML Signature consists of essential elements as shown:
<Signature>
<SignedInfo>
<CanonicalizationMethod />
<SignatureMethod />
<Reference>
<Transforms />
<DigestMethod />
<DigestValue />
</Reference>
...
</SignedInfo>
<SignatureValue />
<KeyInfo />
<Object />
</Signature>
Chaque élément Reference
signifie une ressource spécifique signée, identifiable par l'attribut URI.
Types de signatures XML
- Signature enveloppée : Ce type de signature est un descendant de la ressource qu'il signe, ce qui signifie que la signature est contenue dans la même structure XML que le contenu signé.
Exemple :
<samlp:Response ... ID="..." ... >
...
<ds:Signature>
<ds:SignedInfo>
...
<ds:Reference URI="#...">
...
</ds:Reference>
</ds:SignedInfo>
</ds:Signature>
...
</samlp:Response>
Dans une signature enveloppée, l'élément ds:Transform
spécifie qu'il est enveloppé par l'algorithme enveloped-signature
.
- Signature enveloppante : Contrairement aux signatures enveloppées, les signatures enveloppantes enveloppent la ressource à signer.
Exemple :
<ds:Signature>
<ds:SignedInfo>
...
<ds:Reference URI="#...">
...
</ds:Reference>
</ds:SignedInfo>
<samlp:Response ... ID="..." ... >
...
</samlp:Response>
</ds:Signature>
- Signature détachée : Ce type est séparé du contenu qu'il signe. La signature et le contenu existent indépendamment, mais un lien entre les deux est maintenu.
Exemple :
<samlp:Response ... ID="..." ... >
...
</samlp:Response>
<ds:Signature>
<ds:SignedInfo>
...
<ds:Reference URI="#...">
...
</ds:Reference>
</ds:SignedInfo>
</ds:Signature>
En conclusion, les signatures XML offrent des moyens flexibles de sécuriser les documents XML, chaque type répondant à différents besoins structurels et de sécurité.
Références
{% hint style="success" %}
Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
Support HackTricks
- Check the subscription plans!
- Join the 💬 Discord group or the telegram group or follow us on Twitter 🐦 @hacktricks_live.
- Share hacking tricks by submitting PRs to the HackTricks and HackTricks Cloud github repos.