Start the standard SAML authentication flow with the Identity Provider.
Standard SAML Authentication Easy
Three secure-by-default SAML flows. Use them to get a feel for how the protocol normally behaves before tackling the attack tabs.
Practice bypassing the Identity Provider's verification mechanisms.
Open Redirect Easy
The IdP doesn't validate where it sends the user after authentication.
💡 Hint?
How does the IdP decide where to redirect after authentication? Can you steer it somewhere else?
Challenge yourself with various Service Provider bypass techniques.
Replay Attacks Easy – Hard
Each verifier tracks different parts of the SAML response for replay detection — find the gap.
💡 Hint?
Login as
attacker on the IdP, then submit the same SAMLResponse again. What does the SP actually remember about that response?
Token Recipient Confusion (TRC) Easy – Hard
The SP accepts a SAMLResponse that was actually addressed to a different SP.
TRC Attack Scenario
- Scenario: You have successfully registered a malicious SP at the honest IdP — open it in a new tab and authenticate as the victim: 🎠Open malicious SP
- Step 1: You simulate a victim clicking on that link. Only in this TRC scenario are you allowed to login as victim (e.g. the victim wants to win a prize). After the victim authenticates on the IdP, your malicious SP receives the SAMLResponse. Tip: right-click the malicious-SP link and open in a private/incognito tab.
- Step 2: Copy that SAMLResponse and replay it against the honest SP below.
- Success: TRC succeeds when you authenticate as
victimusing a SAMLResponse minted for the attacker SP.
💡 Hint?
Whose SAMLResponse is it? What field on the response tells you, and does the SP check it against itself before accepting?
Signature Bypasses Medium
Weaknesses in the way the SP verifies the SAML response signature.
💡 Hint?
Where in the response does the signature actually live? Could you remove it, fake one, or splice in extra content that the SP processes but didn't sign? Login as
attacker on the IdP, then aim for user sigbypass1 (SigBypass 1) or sigbypass2 (SigBypass 2). SigBypass 3 is different — authenticate user acker.
XML Signature Wrapping (XSW) Hard – Master
XML-structure manipulation that bypasses signature verification. Login as attacker, target users xsw1…xsw4.
💡 Hint?
The SP signed one element, but it processes another. Can you inject a new element that survives signature validation but changes which subject the SP sees?