hunt-saml

Intercept the SAMLResponse, inject a second assertion with an attacker-controlled NameID before the legitimately signed assertion, and re-encode it in base64. If the service provider processes the first assertion while the signature validates the second, you achieve account takeover.

SAMLRaider, a Burp Suite extension, automates XSW testing on intercepted SAMLResponses. Manual workflows use base64 decoding, xmllint for formatting, and direct XML editing before re-encoding and submitting to the assertion consumer service.

Decode the SAMLResponse, delete the entire Signature element, change the NameID to an admin email, and re-encode. If the service provider does not enforce signature presence, it accepts the forged assertion and issues an admin session.

An attacker uses a NameID like [email protected]<!-- -->.evil.com where canonicalization strips the comment before signing, but the application's parser reads only the text before the comment. The signed value and the effective identity differ, enabling admin impersonation.

Probe common paths such as /saml/acs, /sso/saml, /adfs/ls/IdpInitiatedSignOn.aspx, /saml2/idp/metadata.php, and /auth/realms/master/protocol/saml. Responses with HTTP 200 or 302 indicate exposed ADFS, Shibboleth, Keycloak, or SimpleSAMLphp deployments.

If XML manipulation only alters non-security attributes like display name or locale without changing NameID, AuthnContext, or role-bearing AttributeStatements, it does not cross an authorization boundary. Such findings are Informational rather than Critical.