Blog

How to Hunt Bugs in SAML; a Methodology - Part III

Apr 24, 2019 | 4 minutes read

Tags: bug bounty, saml, methodology, xsw, how to, saml raider, xxe, xslt, sso

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

White Papers

XML Signature Wrapping Write-ups

XML Signature Exclusion Write-ups

XML eXternal Entity via SAML Write-ups

Extensible Stylesheet Language Transformation via SAML Write-ups

Extensible Stylesheet Language Tranformation Payloads

Certificate Faking Write-ups

Token Recipient Confusion Write-ups

SAML Disclosed Vulnerability Reports


comments powered by Disqus