Hacktricks-skills saml-basics

Security Assertion Markup Language (SAML) reference for security testing and analysis. Use this skill whenever you need to understand SAML authentication flows, analyze SAML requests/responses, work with XML signatures, or investigate SAML-based SSO implementations. Trigger this skill for any SAML-related security assessment, SSO testing, or when examining SAML protocol messages in pentesting scenarios.

install

source · Clone the upstream repo

git clone https://github.com/abelrguezr/hacktricks-skills

manifest: skills/pentesting-web/saml-attacks/saml-basics/SKILL.MD

source content

SAML Basics

What is SAML

Security Assertion Markup Language (SAML) enables identity providers (IdP) to send authorization credentials to service providers (SP), facilitating single sign-on (SSO). This approach simplifies managing multiple logins by allowing a single set of credentials across multiple websites.

SAML leverages XML for standardized communication between IdPs and SPs, linking user identity authentication with service authorization.

SAML vs OAuth

SAML: Tailored for enterprise SSO login security control
OAuth: Mobile-friendly, uses JSON, collaborative effort from companies like Google and Twitter

SAML Authentication Flow

The SAML authentication process follows these steps:

Resource Access Attempt: User tries to access a protected resource
SAML Request Generation: SP doesn't recognize the user and generates a SAML Request
Redirect to IdP: User is redirected to the IdP with the SAML Request passing through the browser
IdP Receives Request: IdP receives the SAML Request
Authentication at IdP: IdP authenticates the user
User Validation: IdP validates the user's legitimacy to access the requested resource
SAML Response Creation: IdP generates a SAML Response containing necessary assertions
Redirect to SP's ACS URL: User is redirected to the SP's Assertion Consumer Service (ACS) URL
SAML Response Validation: ACS validates the SAML Response
Resource Access Granted: Access to the initially requested resource is granted

Analyzing SAML Requests

When a user requests access to a secure resource, the SP generates a SAML Request. The raw SAML Request is XML:

<?xml version="1.0"?>
<samlp:AuthnRequest
  AssertionConsumerServiceURL="https://shibdemo-sp1.test.edu/acs"
  Destination="https://idp.example.com/saml"
  ProtocolBinding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST"
  ID="_request-id"
  IssueInstant="2024-01-15T10:30:00Z">
  <saml:Issuer>https://shibdemo-sp1.test.edu</saml:Issuer>
  <samlp:NameIDPolicy Format="urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress"/>
</samlp:AuthnRequest>

Key SAML Request Elements

AssertionConsumerServiceURL: Where the IdP should send the SAML Response post-authentication
Destination: The IdP's address to which the request is sent
ProtocolBinding: Defines the transmission method of SAML protocol messages
saml:Issuer: Identifies the entity that initiated the request

SAML Request Transmission

After 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:

RelayState: Maintains state information throughout the transaction, ensuring the SP recognizes the initial resource request upon receiving the SAML Response
SAMLRequest: A compressed and encoded version of the raw XML, utilizing Deflate compression and base64 encoding

Analyzing SAML Responses

The SAML Response contains several key components:

<samlp:Response
  ID="_response-id"
  Version="2.0"
  IssueInstant="2024-01-15T10:30:05Z"
  Destination="https://shibdemo-sp1.test.edu/acs">
  
  <ds:Signature>
    <!-- XML Signature for message integrity -->
  </ds:Signature>
  
  <saml:Issuer>https://idp.example.com</saml:Issuer>
  
  <samlp:Status>
    <samlp:StatusCode Value="urn:oasis:names:tc:SAML:2.0:status:Success"/>
  </samlp:Status>
  
  <saml:Assertion ID="_assertion-id">
    <saml:Subject>
      <saml:NameID Format="urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress">
        user@example.com
      </saml:NameID>
    </saml:Subject>
    
    <saml:Conditions NotBefore="2024-01-15T10:30:00Z" NotOnOrAfter="2024-01-15T11:30:00Z">
      <saml:AudienceRestriction>
        <saml:Audience>https://shibdemo-sp1.test.edu</saml:Audience>
      </saml:AudienceRestriction>
    </saml:Conditions>
    
    <saml:AuthnStatement AuthnInstant="2024-01-15T10:30:00Z">
      <saml:AuthnContext>
        <saml:AuthnContextClassRef>urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport</saml:AuthnContextClassRef>
      </saml:AuthnContext>
    </saml:AuthnStatement>
    
    <saml:AttributeStatement>
      <saml:Attribute Name="email">
        <saml:AttributeValue>user@example.com</saml:AttributeValue>
      </saml:Attribute>
    </saml:AttributeStatement>
    
    <ds:Signature>
      <!-- XML Signature for assertion -->
    </ds:Signature>
  </saml:Assertion>
</samlp:Response>

Key SAML Response Elements

ds:Signature: XML Signature ensuring integrity and authenticity of the issuer. SAML responses often contain two
```
ds:Signature
```
elements - one for the message and one for the assertion
saml:Assertion: Holds information about the user's identity and possibly other attributes
saml:Subject: Specifies the principal subject of all statements in the assertion
saml:StatusCode: Represents the status of the operation in response to the corresponding request
saml:Conditions: Details conditions like validity timing of the Assertion and the specified Service Provider
saml:AuthnStatement: Confirms that the IdP authenticated the subject of the Assertion
saml:AttributeStatement: Contains attributes describing the subject of the Assertion

SAML Response Transmission

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: State parameter
SAMLResponse: The encoded SAML Response

The ACS is responsible for processing and validating the SAML Response. After validation, access is granted to the protected resource.

XML Signatures in SAML

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.

Basic XML Signature Structure

<Signature>
  <SignedInfo>
    <CanonicalizationMethod Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>
    <SignatureMethod Algorithm="http://www.w3.org/2001/04/xmldsig-more#rsa-sha256"/>
    <Reference URI="#assertion-id">
      <Transforms>
        <Transform Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature"/>
        <Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>
      </Transforms>
      <DigestMethod Algorithm="http://www.w3.org/2001/04/xmlenc#sha256"/>
      <DigestValue>base64-encoded-digest</DigestValue>
    </Reference>
  </SignedInfo>
  <SignatureValue>base64-encoded-signature</SignatureValue>
  <KeyInfo>
    <X509Data>
      <X509Certificate>base64-encoded-certificate</X509Certificate>
    </X509Data>
  </KeyInfo>
  <Object/>
</Signature>

Each

Reference

element signifies a specific resource being signed, identifiable by the URI attribute.

Types of XML Signatures

1. Enveloped Signature

The signature is a descendant of the resource it signs, contained within the same XML structure as the signed content.

<samlp:Response ID="_response-id">
  ...
  <ds:Signature>
    <ds:SignedInfo>
      ...
      <ds:Reference URI="#_response-id">
        <ds:Transforms>
          <ds:Transform Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature"/>
        </ds:Transforms>
      </ds:Reference>
    </ds:SignedInfo>
  </ds:Signature>
  ...
</samlp:Response>

The

ds:Transform

element specifies that it's enveloped through the

enveloped-signature

algorithm.

2. Enveloping Signature

The signature wraps the resource being signed.

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

3. Detached Signature

The signature is separate from the content it signs. The signature and content exist independently, but a link between them is maintained.

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

Security Testing Considerations

When analyzing SAML implementations for security testing:

Decode SAMLRequest/SAMLResponse parameters: These are Deflate-compressed and base64-encoded
Validate XML signatures: Check if signatures are properly verified by the SP
Examine signature types: Different signature types have different security implications
Check assertion conditions: Look at NotBefore, NotOnOrAfter, and AudienceRestriction elements
Review attribute statements: These may contain sensitive user information
Analyze the ACS endpoint: This is where SAML responses are processed and validated

References

How to Test SAML - A Methodology