forked from CompassSecurity/SAMLRaider
-
Notifications
You must be signed in to change notification settings - Fork 8
Release v2.3.0 #9
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Merged
Hannah-PortSwigger
merged 35 commits into
PortSwigger:master
from
CompassSecurity:master
Apr 30, 2025
Merged
Release v2.3.0 #9
Hannah-PortSwigger
merged 35 commits into
PortSwigger:master
from
CompassSecurity:master
Apr 30, 2025
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
An error occurs when SAML Raider tries to decompress an empty SAMLRequest parameter. Specifically, the following code: ``` Inflater inflater = new Inflater(gzip); inflater.setInput(data); ``` ...enters an infinite loop because inflater.finished() never returns true on empty input, and inflate() returns 0 indefinitely, causing the UI to freeze. To prevent this, you may consider updating the decompression logic to explicitly handle empty input — for example, by returning new byte[0] early or throwing an exception. This might require some additional safeguards or refactoring depending on usage.
I find semantically more correct to return byte[0] when decompressing byte[0] instead of throwing an exception. But this has the consequence that I had to add some changes to the SAMLMessageDecode as well. A good exmaple why using try-catch for flow-control is a bad idea. But I don't see a better way.
I think it is semantically more correct to let it throw a NullPointerException when someone tries to compress or decompress null. Null check should be handled by the caller
Infinity loop at compression fix
The parsing in getRequest seems to be unnecessary and also incorrect when trying to apply XXE content
Implement applyXSW10 XSW attack with Response/Assertion wrapping, entity-based ID spoofing, and injected DOCTYPE. Known limitations: - Doctype declaration was extracted into applyDOCTYPE method, because of org.w3c.dom.Document limitations - Entities can't be injected into attribute values, so simple match and replace was implemented instead - Ruby requires 0 indent, so for test purposes it is 0 now, planning to add new settings for it
certificate tests were broken
This flag is missleading. It descibes as 'if line breaks should be inserted'. But it translates to whether the XML document shall be formatted with identations (the flag is passed to format.setIndenting(...)). getStringOfDocument(doc, 0, false) is the same as getStringOfDocument(doc, 0, true) Also the indenting flag in getString(Document document, Boolean indenting, int indent) is unnessecary and missleading. getString(doc, false, 2) is the same as getString(doc, true, 0) From the documentation of 'setIndent(int indent)' Sets the indentation. The document will not be indented if the indentation is set to zero. Calling setIndenting will reset this value to zero (off) or the default (on).
As we discussed, we agreed that the "Raw" checkbox was quite unintuitive and should be eliminated. After removing this checkbox, I discovered that one of our SAML challenges in HackingLab could no longer be resolved (the Signature Cloning Certificate attack). Upon investigation, I found that after applying attacks or actions, such as "Re-sign assertions," the corresponding method formatted the XML with indentation, which disrupts signature validation. In previous versions, this issue did not occur because when the "Raw" checkbox was unchecked, the indentation was removed again before sending. To address this, I have implemented a solution that eliminates any indentation when attacks or actions are applied to the XML. The only exception is for display purposes, such as in the information tab. The challenge can now be resolved once again.
getStringOfDocument method returns incorrect xml document indent, replaced with correct getString method
Thort/issue90
Clarify instructions for bypassing authentication
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Hello,
We have a new SAMLRaider version published (v2.3.0) and would be greatful if it will be release to BApp store.
The changes includes two bug fixes, a NullPointerException and an Infinit Loop, some UI improvments and a new attack vector (CVE-2025-23369).
Thanks to:
References: