Security Assertion Markup Language (SAML) is an XML standard for exchanging authentication and authorization data between a Service Provider (SP) and an Identification Provider (IdP). SAML is used in many Single Sign-On (SSO) implementations, when a user is authenticated once by IdP to access multiple related SPs. When a user requests to access a SP, it creates a SAML Authentication Request and redirects the user to IdP to be authenticated according to this authentication request. If the user is successfully authenticated, IdP creates a SAML authentication response and sends it back to SP through the user’s browser.
SAML authentication request can be added by SP to the redirect request in two ways. The first is HTTP Redirection Binding, when the SAML authentication request is sent in the URL. In this case, the authentication request is deflated (compressed) due to the limited length of URL, then it is Base64 and URL encoded. The second way is HTTP POST Binding, when the authentication request is sent as a POST request parameter. In this case, it is only URL and BASE64 encoded.
SAML Raider is an excellent Burpsuite extension for testing SAML authentication responses, but it does not process SAML requests. Therefore there is no chance to pentest SAML authentication requests using Burp. SAML ReQuest extension adds this feature to Burp. So instead of copying SAML authentication requests from Burp, decoding,
decompressing, modifying then compressing and encoding the request back using external tools, this extension does all these transformations automatically on Burp. This enables pentesters to test IdP against manipulated or malformed requests faster, more conveniently and without any conflict with SAML Raider.
SAML ReQuest Burpsuite checks the existence of “SAMLRequest” parameter in every request. If it exists, it does the following:
Checks HTTP request method
if method is GET, then authentication request is deflated, therefore it:
URL decodes the parameter
base64 decodes the result of point 1
decompresses (inflates) the result of point 2
if it is a POST request, then the authentication request is not deflated.
URL decode the parameter
base64 decode the result of point 1
Display the SAML Authentication request in a new “sub-tab” in Intercept tab as shown in Figure 1.
If you modify the authentication request in the “sub-tab”, the “SAMLRequest” parameter in the original request will be updated accordingly.
After sending the request, you can still see the decoded SAML request in Proxy history, as shown in Figure 2.
You can download SAMLReQuest here. I will be delighted if you try it and kindly feel free to leave a comment if you have any suggestion on how to develop this extension or even have any comment.
I just installed this and it correctly finds the SAML Request and decodes it in the SAML ReQuest subtab, but I cannot edit the contents of that subtab.
Thanks for your comment. To help me to troubleshoot, Could you tell me where you face this problem? I mean Proxy: Intercept or Repeater? Also the version of your Burpsuite would be helpful.
A cool bit would be to be able to provide certificate and keys and have a dummy IdP to generate dummy AuthResponses, for testing apps independently of the IdP.
I like your suggestion. I think it’s not a simple modification of the current extension, but I might add it to the next version.
In the meanwhile, you can manipulate the original AuthResponses using Proxy’s intercept or create dummy ones using Repeater or Intruder.
Thanks for your suggestion,