These posts are meant to provide a background and testing methodology. However, a methodology should not be confused with a strict checklist. We’ve discussed a lot of different SAML vulnerabilities and ways to exploit them, but bug discovery can often require creativity and applying different variations on existing techniques.

A great example is Owning SAML. In the post, the author, Rick Osgood, found an open redirect vulnerability in the RelayState parameter passed alongside the normal SAML Response. Recall that the RelayState parameter is sent along with the SAML Request. It is state information sent by the Service Provider (SP) to the Identity Provider (IdP) so that the SP knows who initially asked for the resource when the SAML Response comes back.

If Mr. Osgood only tested vulnerabilities that we discussed in this series of posts, he would not have discovered the open redirect hiding in the RelayState parameter. He used knowledge of other vulnerabilities and applied them to the SAML implementation he tested.

The Methodology

The methodology mirrors the vulnerabilities that we discussed in Part II. If you found your way here without reading the earlier posts in this series, feel free to reference the material therein when necessary.

• Test whether or not the SP accepts an Assertion without a Signature (Signature Exclusion)
• Test whether or not the SP is susceptible to XML Signature Wrapping (XML Signature Wrapping)
• Test whether or not the SP verifies that the Assertion came from a trusted IdP (Certificate Faking)
• Test whether or not the SP creates more than a single session per Assertion (Assertion Replay - may or may not be considered a bug by itself)
• Test whether or not the SP is vulnerable to XXE (XML eXternal Entity via SAML)
• Test whether or not the SP is vulnerable to XSLT (Extensible Stylesheet Language Tranformation via SAML)
• If the target SP is serviced by an IdP to which you have a legitimate account on a different SP serviced by the same IdP, test whether or not the target SP accepts a valid Assertion meant for the valid SP (Token Recipient Confusion)

There we have it. A simple set of checks to perform against any SAML deployment you test. It is not exhaustive, as there are additional permutations of XSW that could be applied manually, as well as attacks against the XML Canonicalization of Comments. However, it is complete enough to provide a solid foundation for testing.

Additional Resources

Recall from Part I that this series was compiled from multiple sources. The most useful of those sources are listed below. The resources below may provide additional clarity if some is needed, as they generally go into more depth about the particular SAML vulnerability on which they focus.

General SAML Resources

• The Beer Drinker’s Guide to SAML
• Shibboleth Demo
• An Introduction to XML Digital Signatures

White Papers

• On Breaking SAML: Be Whoever You Want to Be
• The Curse of Namespaces in the Domain of XML Signature
• Your Software at my Service

XML Signature Wrapping Write-ups

• XML Signature Element Wrapping Attacks and Countermeasures
• The road to your codebase is paved with forged assertions
• Bypassing SAML 2.0 SSO with XML Signature Attacks
• Attacking SSO: Common SAML Vulnerabilities and Ways to Find Them

XML Signature Exclusion Write-ups

• The road to your codebase is paved with forged assertions

XML eXternal Entity via SAML Write-ups

• Detecting and exploiting XXE in SAML Interfaces
• Out of Band XML External Entity Injection via SAML SSO
• Truncation of SAML Attributes in Shibboleth 2

Extensible Stylesheet Language Transformation via SAML Write-ups

• Security Analysis of SaaS Single Sign-On Solutions in the Cloud

Extensible Stylesheet Language Tranformation Payloads

• XML Signature – XSLT Code Execution
• XSLT Injection
• The hidden dangers of XSLTProcessor – Remote XSL injection
• XSLT Server Side Injection Attacks

Certificate Faking Write-ups

• SAML SP Authentication Bypass Vulnerability in nevisAuth

Token Recipient Confusion Write-ups

• The road to hell is paved with SAML Assertions
• Slack SAML Authentication Bypass

SAML Disclosed Vulnerability Reports

• [rev-app.informatica.com] - XXE via SAML
• Samlify is vulnerable to signature wrapping
• OneLogin authentication bypass on WordPress sites
• SSO Authentication Bypass