Testing with short NotOnOrAfter

[floyd-fuh]

In real-world cases, the SAMLResponse is often only valid for 10 seconds or similar. It would be nice to have a way to use the XSW attacks in an automated way. How do you test with short NotOnOrAfter times?

The full automation of a login and receiving the SAMLResponse is now easy due to the Stepper Burp extension. With Hackvertor we also have options to encode things dynamically. What would be really cool is if SAMLRaider would also support some kind of dynamic marker. I propose something similar to Hackvertor: If the SAMLRaider extension sees some tag (via looking at the traffic in the processHttpMessage Burp API) such as <_@_SAMLRaider_XSW1>PD94bWwgdmVyc2lvbj0iMS4w....Pg%3D%3D<_@/_SAMLRaider_XSW1>, it would take the passed base64 and apply the XSW1 transformation.

However, that's just an idea, I'm open to any suggestions how you test the XSW attacks with very short NotOnOrAfter times.

[emanuelduss]

Hi

This would be nice, I agree!

I have never used the Stepper extension. It looks nice, I'll definitively have a look at it.

I usually do it like this:

• Perform a normal login to see how everything should look like.
• I send the assertion from the history to the repeater and check if I can use the same assertion multiple times. If so, this is the best case, so I can do everything from the repeater tab if there is no short NotOnOrAfter time limit.
• If an assertion can only be used once or there is a short NotOnOrAfter time limit, I configure the proxy to only intercept the SAMLResponse message which contains the assertion and perform a login.
• Then I switch to proxy / intercept mode and perform a login. Then, the SAML message pops up in burp and I can then directly modify the assertion. These modifications can usually be done within less than 10 seconds.
• To repeat the process I only delete the cookies on the SP so I can quickly use the IdP session to get a new assertion I can tamper with.

Do you think this process is too slow / error prone?