Auth Bypass with Saml

SAML (Security Assertion Markup Language) auth bypass vulnerabilities exploit weaknesses in the SAML protocol's trust model and implementation details. These bypasses allow attackers to authenticate as legitimate users without knowing their credentials.

The most common SAML auth bypass occurs through signature wrapping attacks. SAML assertions are XML documents signed by the identity provider (IdP). If the service provider (SP) only validates the signature on the outer element but not the inner assertion, an attacker can wrap a malicious assertion inside a valid signature. The SP validates the outer signature, trusts the entire document, and accepts the malicious assertion.

<samlp:Response xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol" ID="_id1" Version="2.0" IssueInstant="2024-01-15T10:00:00Z" Destination="https://serviceprovider.com/saml/acs" InResponseTo="_id2">
  <saml:Issuer>https://idp.example.com</saml:Issuer>
  <samlp:Status>
    <samlp:StatusCode Value="urn:oasis:names:tc:SAML:2.0:status:Success"/>
  </samlp:Status>
  <!-- Valid outer signature -->
  <ds:Signature>...</ds:Signature>
  <!-- Malicious inner assertion -->
  <saml:Assertion>
    <saml:Subject>
      <saml:NameID>[email protected]</saml:NameID>
    </saml:Subject>
    <saml:AuthnStatement AuthnInstant="2024-01-15T10:00:00Z"/>
  </saml:Assertion>
</samlp:Response>

Another critical bypass vector is SAML response injection. If the SP fails to validate the InResponseTo attribute, an attacker can replay valid SAML responses to authenticate as any user. The attacker captures a legitimate SAML response, modifies the NameID to target a different user, and submits it without the SP verifying it matches the original authentication request.

Time-based bypasses exploit clock skew between IdP and SP. SAML assertions contain NotBefore and NotOnOrAfter timestamps. If the SP's clock is significantly behind, an expired assertion might still be accepted. Conversely, if the SP's clock is ahead, a future assertion could be accepted before its valid time window.

Attribute manipulation bypasses occur when SPs trust SAML attributes without validation. An attacker can modify the AttributeStatement section to add administrative roles or escalate privileges. For example, changing role from user to admin grants unauthorized access.

<saml:AttributeStatement>
  <saml:Attribute Name="role" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:basic">
    <saml:AttributeValue>admin</saml:AttributeValue> <!-- Modified from 'user' -->
  </saml:Attribute>
</saml:AttributeStatement>

Metadata injection is another sophisticated bypass. SAML metadata files define trusted certificates and endpoints. If an attacker can modify the SP's metadata to include a malicious certificate, they can sign forged assertions that the SP will accept as valid.

Detecting SAML auth bypasses requires both static analysis of SAML configurations and dynamic testing of SAML endpoints. Start by examining SAML metadata files for weak signature algorithms (SHA-1, MD5) or missing WantAssertionsSigned flags that indicate the SP doesn't verify assertion signatures.

Verify that your SAML implementation validates all signature levels. Use XML parsing libraries that support secure canonicalization and don't allow external entity resolution. Test with tools like SAML-tracer to capture and analyze SAML messages in transit.

# Check SAML metadata for security issues
curl -s https://idp.example.com/saml/metadata | grep -E '(WantAssertionsSigned|WantAuthnRequestsSigned|SingleLogoutService)'

# Test signature validation
# A secure implementation should reject responses with wrapped assertions
curl -s https://serviceprovider.com/saml/acs --data-binary '@malicious_saml.xml' | grep -i 'invalid|error|rejected'

Validate timestamp handling by testing with assertions that have expired or future timestamps. Check if your SP accepts assertions outside their valid time window. Monitor clock synchronization between IdP and SP to ensure timestamps are within acceptable tolerances.

Attribute validation testing involves submitting SAML responses with modified AttributeStatement sections. A secure SP should validate that attributes match expected values for the authenticated user and not blindly trust SAML attributes for authorization decisions.

middleBrick's SAML security scanning specifically tests for these auth bypass patterns. The scanner sends crafted SAML responses with signature wrapping attempts, modified attributes, and timestamp manipulations to detect if your SP properly validates all SAML components.

middleBrick tests 12 security checks including authentication bypass detection, running in parallel to identify vulnerabilities in your SAML implementation. The scanner doesn't require credentials or agents—just submit your SAML endpoint URL for a 5-15 second security assessment.

For continuous monitoring, middleBrick's Pro plan automatically rescans your SAML endpoints on a configurable schedule, alerting you if auth bypass vulnerabilities are detected or if your security score drops below your threshold.

Remediate SAML auth bypasses by implementing comprehensive signature validation at all levels. Your service provider must validate both the outer response signature and the inner assertion signature. Use XML security libraries that properly handle XML canonicalization and prevent signature wrapping.

import xmlsec
from lxml import etree

def validate_saml_response(xml_data):
    # Parse XML securely
    parser = etree.XMLParser(resolve_entities=False)
    doc = etree.fromstring(xml_data, parser)
    
    # Validate outer signature
    if not xmlsec.check_signature(doc, key_store):
        raise ValueError('Invalid outer signature')
    
    # Find and validate inner assertion signature
    assertion = doc.find('.//{urn:oasis:names:tc:SAML:2.0:assertion}Assertion')
    if assertion is None or not xmlsec.check_signature(assertion, key_store):
        raise ValueError('Invalid or missing assertion signature')
    
    # Validate timestamps
    not_before = assertion.find('.//{urn:oasis:names:tc:SAML:2.0:assertion}Conditions').get('NotBefore')
    not_on_or_after = assertion.find('.//{urn:oasis:names:tc:SAML:2.0:assertion}Conditions').get('NotOnOrAfter')
    
    current_time = datetime.utcnow()
    if not (not_before <= current_time <= not_on_or_after):
        raise ValueError('Assertion timestamp invalid')
    
    return doc

Implement strict InResponseTo validation to prevent response injection. Store the InResponseTo value from your authentication request and verify the SAML response contains the matching value before processing.

def validate_in_response_to(response, expected_id):
    in_response_to = response.get('InResponseTo')
    if in_response_to != expected_id:
        raise ValueError('InResponseTo mismatch - possible replay attack')
    return True

Attribute validation should be strict and deny-by-default. Never use SAML attributes directly for authorization decisions. Instead, map SAML attributes to internal user roles and validate against your application's authorization system.

def validate_attributes(assertion, allowed_roles):
    attributes = {}
    for attr in assertion.findall('.//{urn:oasis:names:tc:SAML:2.0:assertion}Attribute'):
        name = attr.get('Name')
        values = [v.text for v in attr.findall('.//{urn:oasis:names:tc:SAML:2.0:assertion}AttributeValue')]
        attributes[name] = values
    
    # Validate role against allowed values
    user_roles = attributes.get('role', [])
    if not any(role in allowed_roles for role in user_roles):
        raise PermissionError('Invalid user role')
    
    return True

Configure your SAML metadata with WantAssertionsSigned and WantAuthnRequestsSigned set to true. This ensures your SP requires signatures on both assertions and authentication requests, adding defense in depth.

Implement proper clock synchronization using NTP to minimize timestamp-related bypasses. Set reasonable clock skew tolerances (typically 5 minutes) and reject assertions outside this window.

middleBrick's remediation guidance includes specific recommendations for SAML implementations, mapping findings to OWASP API Top 10 categories and providing code examples for fixing identified vulnerabilities. The scanner's findings help you prioritize fixes based on severity and exploitability.