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 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.
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.
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.