What versions are protected against XML Signature Wrapping attacks?
https://blog.netspi.com/attacking-sso-common-saml-vulnerabilities-ways-find/
We recently got scanned by a client and they found some issues, specifically regarding XSW3, XSW4, XSW5, XSW6, XSW6a, XS7, XSW8 and XSW8a.
The client is only signing the assertion. If we request/require that they sign the entire response, that should eliminate the threat, correct? I think signing the entire response is more secure than signing only the assertion (when having to choose one versus the other). Would you concur?
TIA!
I agree that signing the SAML response removes the attack vectors associated with the SAML assertion (ie those listed) and therefore is more secure.
Any changes to the SAML response (eg adding SAML assertions etc) will invalidate the XML signature.
However, signing the SAML assertion should be fine too as long as the necessary precautions are taken, as they our by our products.
Any product version from 2012 onward should not be vulnerable to XSW attacks.
In recent releases, if the SAML response contains more than one assertion this is treated as invalid and an exception is thrown.
Prior to that, if the SAML configuration specifies WantAssertionSigned = true, the signed SAML assertion’s signature is verified and it’s this SAML assertion that’s processed. Any other SAML assertions are ignored.
You’re welcome to email us the report and we can take a closer look.
[quote][/quote]
I agree that signing the SAML response removes the attack vectors associated with the SAML assertion (ie those listed) and therefore is more secure.
Any changes to the SAML response (eg adding SAML assertions etc) will invalidate the XML signature.
However, signing the SAML assertion should be fine too as long as the necessary precautions are taken, as they our by our products.
Any product version from 2012 onward should not be vulnerable to XSW attacks.
In recent releases, if the SAML response contains more than one assertion this is treated as invalid and an exception is thrown.
Prior to that, if the SAML configuration specifies WantAssertionSigned = true, the signed SAML assertion's signature is verified and it's this SAML assertion that's processed. Any other SAML assertions are ignored.
You're welcome to email us the report and we can take a closer look.
Any changes to the SAML response (eg adding SAML assertions etc) will invalidate the XML signature.
However, signing the SAML assertion should be fine too as long as the necessary precautions are taken, as they our by our products.
Any product version from 2012 onward should not be vulnerable to XSW attacks.
In recent releases, if the SAML response contains more than one assertion this is treated as invalid and an exception is thrown.
Prior to that, if the SAML configuration specifies WantAssertionSigned = true, the signed SAML assertion's signature is verified and it's this SAML assertion that's processed. Any other SAML assertions are ignored.
You're welcome to email us the report and we can take a closer look.
So, it would seem there isn't an XSW issue. The issue was only apparent when a separate issue was raised; the fact that we weren't properly validating the signatures with a separate certificate, but using the embedded certificate. Once we validated the assertion signature separately, the XSW vulnerability was no longer possible.
Thanks for the update. I’m glad everything has been resolved.