CompassSecurity
SAMLRaider Causes Old Data in HTTP History, RAW, and SAMLRaider tabs
Using v1.4.1 of SAMLRaider in Burp Suite Pro v2023.5.2 (although the bug has shown up in versions before 2023.5.2, as well).
When the SAMLRaider extension is enabled and the proxy is set to intercept, I observe the following undesired behavior during intercept (i.e. when the request is "paused") that does not happen when the extension is disabled.
- In the Proxy > HTTP history, when I click on the paused request, the request displayed in both the Raw and SAML Raider tab is from a previous request. If I click on the paused request a second time, the info in the Raw and SAML Raider tab is suddenly updated to the correct info.
- In the Intercept > Raw tab, the request info displayed is also from a previous request. Clicking twice in the HTTP history tab only causes the correct info to be displayed in the HTTP history tab itself, it does not cause the correct info to display in the Intercept > Raw tab
- In the Intercept > SAML Raider tab, the info in the SAML Attacks and SAML Message Info is also incorrect. It is the same info that's displayed in the Intercept > Raw tab.
As soon as the extension is disabled, the HTTP history and Intercept > Raw info displays correctly / normally.
The only workaround available is to:
- Do the "2 click" trick in the Proxy > HTTP history to get the correct request to display
- Copy the info from the Proxy > HTTP history tab and paste it into the Intercept tab
I can reproduce this at will. There's actually no way that I CAN'T reproduce it-
More odd behavior... if I intercept a request and apply an XSW attack, everything is fine.
But the next time I intercept a request, when I go to the SAML Attacks tab, it says "XSW Attack applied", even though I haven't yet touched anything with the currently paused request.
Even more odd... when the request is intercepted/paused, if I copy the HTTP history > Raw tab data to the Intercept > Raw tab, then go to the SAML Raider > SAML attacks and do Apply XSW, the resulting attack is the modified request, as you'd expect.
However, if I instead copy the HTTP history > SAML Raider > SAML Message Info and paste it into the Intercept > SAML Raider > SAML Attacks page, when I do "Apply XSW", the resulting attack is a modified version of a previous request, not of the request that's actually been pasted into the SAML Attacks page.
I did some investigation into this issue.
First, I can reproduce all issues provided by @edmacke on Burp Suite Professional & Burp Suite Community.
I debugged the latest version from the repo and debugged with burpsuite_community_v2023.5.2.jar and reproduced the issues. I also debugged with burpsuite_community_v2022.9.2.jar and was NOT able to reproduce these issues.
Additionally, I updated my local pom.xml file to reference the latest Burp Extender API Version (2.3).
The issue is very likely on the Burp or Java end. When I reproduce the issue locally, I hit no breakpoints when viewing the interceptor tab when intercepting the SAML response. I do hit breakpoints when clicking on the SAML message from HTTP History (specifically in the SamlTabController.Java "setMessage" function). AFTER clicking on the record in the HTTP History, and going BACK to the Intercept Tab, I hit all of the breakpoints locally.
After the steps in the above paragraph, the data available in the setMessage function is outdated in the intercept tab's setMessage function, which comes from the "content" parameter. The data is not outdated when viewing from HTTP History. I can't debug any further as that data is passed from the API.
I had a similar issue today. It happened when only the SAMLResponse was intercepted and no other requests. The workaround was to create another intercept rule which intercepts just another arbitrary request before the SAMLResponse. Then, in this request, the display view has to be changed to "hex" and back to "raw", so that after pressing forward, the SAMLResponse is also loaded in raw view. If you then switch back to the SAMLRaider tab, the extension should work.
I know it's a strange & ugly workaround :/. Maybe I'll have some time in the future to look into this issue.
