SAML Security Pitfalls
Part 4 of the SAML From First Principles series
SAML is secure when implemented correctly. But there are well-known attacks that exploit implementation mistakes. Understanding these helps you verify that your SAML setup is solid.
XML Signature Wrapping (XSW)
This is the most famous SAML attack. The attacker modifies the SAML Response XML, moving the legitimately signed portion to a different location in the document and injecting malicious content where the SP expects to find the assertion.
The signature is still valid because the signed content hasn't changed. But the SP reads the attacker's injected content instead of the signed content.
Imagine a signed contract. Someone photocopies just the signature page and attaches it to a completely different contract. If you only check "is there a valid signature somewhere in this document?" without checking "is the signature on this specific page?", you get tricked.
The fix: The SP must verify that the signature covers the exact assertion it's processing. It needs to check that the signed element and the element it's reading are the same node in the XML tree.
Replay Attack
An attacker captures a valid SAML Response and re-sends it to the SP to gain access. Someone records you saying "Open sesame" and plays it back later.
The fix: Two parts. First, assertions have NotBefore and NotOnOrAfter timestamps that create a short validity window (typically 5 minutes). Second, the SP should track assertion IDs and reject any assertion it has seen before. Each assertion should be used exactly once.
Man-in-the-Middle
If the connection between the browser and the IdP or SP isn't over HTTPS, someone on the network can intercept the SAML Response and read or modify it.
The fix: Always use TLS/HTTPS for every endpoint involved in the SAML flow. For additional protection, encrypt the assertion itself.
Open Redirect on Relay State
The Relay State parameter tells the SP where to redirect the user after login. If the SP doesn't validate this URL, an attacker could set it to a phishing site. The user authenticates legitimately, then gets redirected to a malicious page.
The fix: The SP should whitelist allowed Relay State URLs and reject any URL that doesn't match.
Certificate Rollover Issues
When the IdP rotates its signing certificate, the SP must update its copy. If the SP still has the old certificate, all signature verifications fail and users get locked out.
The fix: Support multiple certificates during rollover periods. The IdP publishes both old and new certificates in its metadata. Monitor certificate expiry dates and plan rollovers in advance.
The Common Thread
Most SAML vulnerabilities come from implementation mistakes, not protocol flaws. The protocol is well-designed. The problems arise when SPs don't validate signatures correctly, don't check timestamps, don't enforce one-time use, or don't validate Relay State URLs.
← Back to all posts