If internal.company.com Redirects You To SSO e.g. auth.company.com, Do FUZZ On Internal.company.com
If company.com/internal Redirects You To SSO e.g. Google login, Try To Insert public Before internal e.g. company.com/public/internal To Gain Access to Internal
Try To Craft a SAML Request With a Token And Send It To The Server And Figure Out How the Server interacts with This
If There Is AssertionConsumerServiceURL In Token Request Try To Insert Your Domain e.g. http://me.com As Value To Steal The Token
If There Is AssertionConsumerServiceURL In Token Request Try To Do FUZZ On Value Of AssertionConsumerServiceURL If It Is Not Similar To Origin
If There Is Any UUID, Try To Change It To the UUID Of the Victim Attacker e.g. Email Of an Internal Employee Or Admin Account, etc
Try To Figure Out If The Server is Vulnerable To XML Signature Wrapping OR Not?
Try To Figure Out If The Server Checks The Identity Of The Signer OR Not?
Try To Inject XXE Payloads At The Top Of The SAML Response
Try To Inject XSLT Payloads Into The Transforms Element As A Child Node Of The SAML Response
If Victim Can Accept Tokens Issued By The Same Identity Provider That Services Attacker, So You Can Takeover Victim Account
While Testing SSO Try To search In Burp Suite About URLs In Cookie Header e.g. Host=IP; If There Is Try To Change IP To Your IP To Get SSRF
Last updated 2 years ago