search

IdentityPython / pysaml2

Python implementation of SAML2
Apache License 2.0
564 stars 423 forks source link

Lowercase URL encoding in IdP response or request results in an IncorrectlySigned error. #957

Open landron opened 7 months ago

landron commented 7 months ago

EntraID (formerly Azure) sends a LogoutRequest via GET method in the form of /logout?SAMLRequest=...&Signature=...&SigAlg=... (respectively, LogoutResponse in the format of /logout?SAMLResponse=...&Signature=...&SigAlg=...). The function parse_logout_request can be utilized to parse and validate the request, including its signature, using the sigalg and signature parameters. The issue arises because the parameters are URL encoded, and the signature is computed after encoding. EntraID encodes in lowercase, for instance: http%3a%2f%2fwww.w3.org%2f2001%2f04%2fxmldsig-more%23rsa-sha256. However, verify_redirect_signature in pysaml2 uses parse.urlencode, which encodes in uppercase regardless of the input. Consequently, _do_redirect_sig_check fails and raises IncorrectlySigned("Request was not signed correctly"). I found no solution within pysaml2, so I replicated the code in our application (similar to here, for example: https://stackoverflow.com/questions/56277719/python-url-encoding-with-lowercase-letters). A solution would be for pysaml2 to utilize the encoding found in the input.

Code Version

Version: 7.1.2 in production, but I am reviewing using tag v7.5.0, from Jan 30 2024.

Expected Behavior

parse_logout_request should succeed.

Current Behavior

Instead it throws IncorrectlySigned("Request was not signed correctly").

Possible Solution

Check the case in the input URL encoding, by example: re.compile(r'%([a-f]\d|\d[a-f])').search(url).

Steps to Reproduce

  1. Make an EntraID enterprise application.
  2. Configure SAML.
  3. Login, than logout from https://portal.microsoft.com/
  4. process the received /logout?SAMLRequest=...&Signature=...&SigAlg=... with parse_logout_request.
landron commented 5 months ago

A better possible solution seems to be keeping the original query parameters when validating the signature.

Notice the MUST: 

Further, note that URL-encoding is not canonical; that is, there are multiple legal encodings for a given
value. The relying party MUST therefore perform the verification step using the original URL-encoded
values it received on the query string. It is not sufficient to re-encode the parameters after they have been
processed by software because the resulting encoding may not match the signer's encoding.

https://groups.oasis-open.org/higherlogic/ws/public/download/56779/sstc-saml-bindings-errata-2.0-wd-06.pdf/latest 3.4.4.1 DEFLATE Encoding