Checking for signature wrapping attacks resilience?

[mauromol]

I was wondering whether, along with that long list of (often useless, although necessary for onboarding) checks for SPID compliance, spid-sp-test could also check for the resilience of the SP implementation against Signature Wrapping attacks, as described, for instance, at:
https://www.netspi.com/blog/technical/web-application-penetration-testing/attacking-sso-common-saml-vulnerabilities-ways-find/
(see "Common Implementation Mistakes & Testing Tips" - "Signature Wrapping" section)
A more thorough source of information might be:
https://www.usenix.org/system/files/conference/usenixsecurity12/sec12-final91.pdf

This is just an idea, probably worth more in-depth analysis.

[peppelinux]

I already proposed these additional checks in the past and I am quite sure that also @damikael would agree with that.

We could start from non normative checks in extra until agid Will define them in the spid QAD.

Very good idea and I'm Happy to have a chance to talk again about this topic, thank you

[peppelinux]

A popular resource
https://cheatsheetseries.owasp.org/cheatsheets/SAML_Security_Cheat_Sheet.html

another aged but still interesting paper
https://www.nds.ruhr-uni-bochum.de/media/ei/arbeiten/2014/12/04/SAMLAttacker.pdf

Lead saml pentest tool
https://github.com/portswigger/saml-raider

A good way to drive SP implementers would be give to them a standard SPID xsd to validate the SAML2 Responses

[mauromol]

Not sure I understand your last point, but from a very quick overview of the links I posted above, the malicious responses do pass the XSD validation, but may deceive parsing if not performed in the right way.

[peppelinux]

A wrapping Attack should be prevented with a good response xsd.

Anyway that's something very interesting, I believe that those attacks MUST be implemented in the response checks

[peppelinux]

I tested all the XWS from 1 to 8 and they all being blocked by signature checks, here.

for getting them working the SP MUST fails the validation of the response against a valid signature but an attacker CAN only remove signature or change signature with a different private key in a way that the SP should validate the response with a different signature value.

because of this I'm moving to have the possibility to render the "alternative" x509 certificate in the Response, thanks to this:
#99

all the responses with the wrapping attacks MUST expose the alternative x509, otherwise they will be blocked by check # 4

[peppelinux]

https://epi052.gitlab.io/notes-to-self/blog/2019-03-13-how-to-test-saml-a-methodology-part-two/

[peppelinux]

I'm doing XSW wrapping attacks here

to test howw the final result is, use this test command, for example

spid_sp_test --metadata-url https://localhost:8000/spid/metadata/ --authn-url https://localhost:8000/spid/login/?idp=https://localhost:8080 -tr -tn xsw3 -nsr

[peppelinux]

here
#99