Open Himself132 opened 3 years ago
Hi there,
The example provided makes it unclear whether or not the ID
defined by the Response is shared by both the Signature attached to the Response and in the Assertion. Can you provide an example with consistent scrubbing, possibly keying different scrubbed fields with different redactions (i.e. <SCRUBBED 1>, <SCRUBBED 2>, ...
) to avoid ambiguity? Alternatively, is there a way to set up a small example to demonstrate this? Or, is there an example from https://developers.onelogin.com/saml/examples/response that aligns with what you've provided as an example?
Hello, i think it might be more valuable to take a step back and look at it this way. There are signatures for the assertion and signatures for the message. Anything outside of the assertion can be modified and does not invalidate the signature as it was originally sent, or it can be stripped entirely. There are a number of attack scenarios here as a result of that fact.
is this vulnerability still open or should the issue be closed?
I would imagine that if no new code was introduced to handle the logic around validating the signature outside of the assertion/in the envelope
In the SAML source below which constitutes the SAMLReponse parameter value the message can be modified and the first signature is not marked as invalid and passes authentication by saml2-js on the SP during SP initiated SSO via SAML2.0
Anything outside of the assertion can be changed and is accepted by the SP. I do not see a way to configure saml2-js to validate the signature outside of the assertion in addition to the assertion? My understanding is that this can lead to same man-in-the-middle attacks and potentially some signature wrapping issues. I do know the specification does not require both signatures to be validated, but in this case I'd like to ensure it is. I have scrubbed any id/session/personal information in the XML.