What is SAML Injection? Ways to Exploit, Examples and Impact

Security Assertion Markup Language (SAML) is the backbone of modern enterprise Single Sign-On (SSO) systems. While it provides a seamless user experience across multiple platforms, its reliance on complex XML structures makes it a prime target for attackers. In this guide, we will dive deep into what SAML injection is, how it can be exploited to bypass authentication, and the steps you can take to secure your infrastructure.

What is SAML and How Does It Work?

Before we can understand SAML injection, we must understand the protocol itself. SAML is an XML-based open standard used for exchanging authentication and authorization data between two parties: the Identity Provider (IdP) and the Service Provider (SP).

In a typical SSO scenario, the Identity Provider (like Okta, Azure AD, or OneLogin) is the source of truth for user identities. The Service Provider is the application the user wants to access (like Slack, GitHub, or a custom internal dashboard). Instead of the user providing a password directly to the SP, the SP trusts an "Assertion" (a signed XML document) provided by the IdP.

The SAML Authentication Flow

1. Request Access: The user attempts to access a protected resource on the Service Provider.
2. SAML Request: The SP redirects the user to the IdP with a SAML AuthnRequest.
3. Authentication: The user logs into the IdP (e.g., via username/password and MFA).
4. SAML Response: The IdP generates a SAML Response, which contains an XML Assertion. This assertion includes the user's identity (NameID) and attributes (like roles or email). Crucially, this assertion is digitally signed by the IdP.
5. Validation: The user's browser forwards this SAML Response to the SP. The SP verifies the digital signature using the IdP's public key. If the signature is valid, the user is logged in.

What is SAML Injection?

SAML Injection is a class of vulnerabilities where an attacker manipulates the XML content of a SAML Assertion to trick the Service Provider into granting unauthorized access. Because SAML relies on XML, it is susceptible to classic XML-related attacks, as well as logic flaws in how the XML is parsed and how signatures are verified.

In a successful SAML injection attack, an adversary might change their user ID from guest to admin or impersonate another user entirely without knowing their password. The vulnerability usually lies in the Service Provider's implementation of the SAML consuming logic, specifically how it handles untrusted input within the XML document.

Common SAML Injection Techniques

There are several ways an attacker can perform SAML injection. Let's explore the most common technical methods used in the wild.

1. XML Comment Injection

XML Comment Injection is one of the most straightforward yet effective SAML exploits. It occurs when a SAML implementation uses a library that strips XML comments before processing the data, but the signature validation logic sees the comments as part of the data.

Imagine an attacker has an account with the email admin<!-- -->@company.com. When the IdP generates the assertion, it looks like this:

<saml:NameID Format="urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress">
    admin<!-- -->@company.com
</saml:NameID>

The IdP signs this exact string. When the Service Provider receives it, two things happen:

1. Signature Verification: The SP checks the signature. The signature is valid because the content (admin<!-- -->@company.com) matches what the IdP signed.
2. User Identification: The SP extracts the NameID. However, if the SP's XML parser is configured to ignore comments, it might interpret the string as admin@company.com.

By injecting a comment into their own username, the attacker successfully impersonates the administrator. This specific vulnerability gained fame when it was discovered in several major SAML libraries (like python3-saml and ruby-saml) in 2018.

2. SAML Signature Wrapping (SSW) Attacks

SAML Signature Wrapping (SSW) is a more complex and dangerous technique. It exploits the fact that an XML document can have multiple elements with the same name, and the logic used to verify the signature might look at a different part of the document than the logic used to extract user data.

In a standard SAML Response, the <Signature> element protects the <Assertion> element. An attacker can modify the response by:

1. Moving the original, validly signed <Assertion> to a different location in the XML tree (e.g., inside an extension field).
2. Inserting a new, malicious <Assertion> in the original location.

If the SP's logic verifies the signature on the moved assertion but then processes the malicious assertion for login, the attack succeeds.

Consider this simplified payload structure:

<samlp:Response>
   <!-- Malicious Assertion (Not Signed) -->
   <saml:Assertion ID="FakeID">
      <saml:Subject>
         <saml:NameID>admin@target.com</saml:NameID>
      </saml:Subject>
   </saml:Assertion>

   <!-- Original Assertion (Signed) moved here -->
   <saml:Extensions>
      <saml:Assertion ID="OriginalID">
         <ds:Signature>...</ds:Signature>
         <saml:Subject>
            <saml:NameID>attacker@evil.com</saml:NameID>
         </saml:Subject>
      </saml:Assertion>
   </saml:Extensions>
</samlp:Response>

If the SP is poorly configured, it may see a valid signature in the Extensions block and assume the entire document is trustworthy, then proceed to log the user in as admin@target.com based on the first assertion it finds.

3. XML External Entity (XXE) within SAML

Since SAML is XML, it is often vulnerable to XML External Entity (XXE) injection. This happens when the XML parser at the Service Provider allows the definition of external entities in the DOCTYPE declaration.

An attacker can craft a SAML Response that includes a malicious DTD:

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE root [
  <!ENTITY xxe SYSTEM "file:///etc/passwd">
]>
<samlp:Response ...>
    <saml:Assertion>
        <saml:AttributeStatement>
            <saml:Attribute Name="username">
                <saml:AttributeValue>&xxe;</saml:AttributeValue>
            </saml:Attribute>
        </saml:AttributeStatement>
    </saml:Assertion>
</samlp:Response>

When the SP parses this assertion, it might read the /etc/passwd file from its own filesystem and reflect the contents back to the attacker (e.g., in an error message or a profile page), leading to sensitive data disclosure or even Server-Side Request Forgery (SSRF).

Impact of Successful SAML Injection

The impact of a SAML injection vulnerability is almost always critical. Because SAML is used for authentication, a successful exploit typically results in:

• Authentication Bypass: An attacker can gain access to an application without a valid password or MFA token.
• Privilege Escalation: An attacker with a low-privileged account can impersonate an administrator by changing their attributes or NameID in the assertion.
• Full Account Takeover: By injecting the NameID of a specific target user, the attacker gains complete control over that user's session and data.
• Data Exfiltration: In the case of XXE-based SAML injection, attackers can steal configuration files, credentials, or internal network data from the Service Provider's server.

Real-World Examples of SAML Exploitation

One of the most notable real-world examples occurred in 2018 when researchers discovered that many SAML implementations were vulnerable to the XML Comment Injection mentioned earlier. This affected major platforms and libraries, including those used by large cloud service providers.

Another common scenario found in bug bounty programs involves "Signature Exclusion." Some Service Providers, when presented with a SAML Response that has no signature at all, simply default to trusting the data if the signature check is skipped in the code logic. While not strictly an "injection," it involves manipulating the XML structure (removing the signature block) to achieve the same goal of authentication bypass.

How to Prevent SAML Injection Vulnerabilities

Securing a SAML implementation requires a defense-in-depth approach. Here are the most effective mitigation strategies:

1. Use Well-Vetted Libraries

Never attempt to write your own SAML parsing logic from scratch. Use established, actively maintained libraries. Ensure these libraries are updated to their latest versions to protect against known vulnerabilities like the 2018 comment injection flaw.

2. Strict Schema Validation

Before processing a SAML Assertion, validate it against the official SAML XSD (XML Schema Definition). This ensures the document structure is exactly what is expected and prevents attackers from adding unexpected elements (like those used in Signature Wrapping attacks).

3. Disable External Entities

Configure your XML parser to strictly disallow DTDs and external entity resolution. This is the primary defense against XXE attacks. In most modern languages, this must be done explicitly (e.g., factory.setFeature("http://apache.org/xml/features/disallow-doctype-decl", true); in Java).

4. Implement Robust Signature Verification

Ensure your Service Provider verifies the signature of the entire SAML Response or the Assertion element. More importantly, ensure that the code extracting the user's identity (NameID) is operating on the exact same XML node that was cryptographically verified.

5. Use Canonicalization (C14N) Correctly

XML can be represented in multiple ways that are logically equivalent but textually different. Digital signatures rely on a process called Canonicalization to ensure the text doesn't change after signing. Ensure your SP and IdP use consistent C14N algorithms (like Exclusive Canonicalization) to prevent attackers from exploiting differences in how white space or comments are handled.

Conclusion

SAML Injection remains a significant threat because of the inherent complexity of XML and the critical role SSO plays in modern infrastructure. By understanding the mechanics of Comment Injection, Signature Wrapping, and XXE, developers and security professionals can better defend their systems. Always prioritize the use of secure, updated libraries and enforce strict validation on every SAML Assertion your application consumes.

To proactively monitor your organization's external attack surface and catch exposures before attackers do, try Jsmon.