Skip to content

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
merged 35 commits into from
Apr 30, 2025
Merged

Conversation

tobiashort
Copy link

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:

d0ge and others added 30 commits March 21, 2025 10:56
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
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
@Hannah-PortSwigger Hannah-PortSwigger merged commit 5cef120 into PortSwigger:master Apr 30, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

Successfully merging this pull request may close these issues.

3 participants