handnot2 / esaml Goto Github PK

Just an observation over xmerl usage. When it parses data, every tag and attribute is converted to an atom. Even if schema validation is applied, at least the root element tag and attributes are still parsed and converted to atoms.

So as the SAML endpoints are normally externally available, an attacker can feed the service with data containing random tags and attributes filling BEAM atom table and eventually crashing the node.

To be constructive, I can suggest to use some other safer xml parsing library, for example erlsom. Of course replacing xmerl with anything would be a significant work, but this is a serious security issue that needs to be tackled somehow.

Microsoft Azure is responding with success there seems to be a problem in parsing the response.

I've tried changing the metadata.xml file with no luck.

Something seems like it is not standard to me in the Azure response as it is failing to find the requested element using the xpath expression in code; but I cannot spot the issue yet.

We're getting an error in xmerl_dsig.erl on line 168.

I'm going to fork the library just to see if we can get things working by changing a few namespaces; but I also wanted to make you aware and see if you had any ideas or have ran into this before and have a way around it.

Here is a full response from one of our test instance and a link to the MetaData

https://login.microsoftonline.com/0adaa849-fc71-472a-9520-2f0da7f74422/FederationMetadata/2007-06/FederationMetadata.xml

Thanks,

Jason

sample_azure_response.txt

My Samly LogoutRequest is not creating valid markup in https://www.samltool.com/validate_xml.php

<?xml version="1.0"?>
<samlp:LogoutRequest
    Destination="https://dev-455970.oktapreview.com/app/heimdall_heimdall_3/exkga21ozaP0T2pcG0h7/slo/saml"
    ID="id153704109584333124814146" IssueInstant="2018-09-15T19:52:28Z"
    ProtocolBinding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST"
    Reason="urn:oasis:names:tc:SAML:2.0:logout:user" Version="2.0"
    xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion"
    xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol">
    <ds:Signature xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
        <ds:SignedInfo><ds:CanonicalizationMethod Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/><ds:SignatureMethod Algorithm="http://www.w3.org/2001/04/xmldsig-more#rsa-sha256"/>
            <ds:Reference URI="#id153704109584333124814146">
                <ds:Transforms><ds:Transform Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature"/><ds:Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/></ds:Transforms><ds:DigestMethod Algorithm="http://www.w3.org/2001/04/xmlenc#sha256"/>
                <ds:DigestValue>4tDSZaOzXbmXi3BCqaiYC2WY5V1wLyPuh5xmAdJK6mg=</ds:DigestValue>
            </ds:Reference>
        </ds:SignedInfo>
        <ds:SignatureValue>GPYcJ7VSenb/P43/bUYi/8dtLTVlGkHT88l7xB+Eea+zY2bOiUraPTqtbWavDvb0yd6qwdwWCDypNLS3CA/Z1d2LWriv9c23S002PjhxubnbFn0MolcDVWpY/kGnN2h6PJOJLXjHSFbnYAFvPejflHTGur11YJtg7lqrZJ2shxZoER2W1/uS2tj/iVhPIf+OyqHjAkOt2KfYlWDoIemiOwvMmz6uu84sp1wEvfYi8tW42GHHHgJFdSL9k9JdOhlDH0MlhUWF6rzm2DIfZJyRZMg5kgzQiRLAYs1ygGC6NkO2g5IQckWrej0KxyEBaXebwMD0w94xKp3iDivwl/mfudhRNCtIyMThtZw7qfT/PzuSH125MdY0krhWvZCXAZ1DR1fBhzw6/RoZFk/Eq7+iBV+GrRAcgBLv7BOaDUXGuFJIIp1g3TfYtxLRJuiC0rRMV8gEiKXiH0Rm9Wh8jw+pn8A/8/KMRVrcndpzQsla3MJ1BN7HRE5TzsL18SlAS2hMhb+Pj6JNBF6KSoEWZivqGfbwrspjzAg1Xx/ZCrBu7HkrF/+9bt+W9xAuQ6JzNHJFZxg9lufvQYBhvJOfQ3ea0wUCRsHkrb5eEDtndeQ4wPf+g9ncW62zDooQDXyYw0OMHY4IE3iNy8JJt+Up+IUB64tRDYbg6VVxM0Uu6nMSS9g=</ds:SignatureValue>
        <ds:KeyInfo>
            <ds:X509Data>
                <ds:X509Certificate>MIIDpDCCAoygAwIBAgIGAWXOODnmMA0GCSqGSIb3DQEBCwUAMIGSMQswCQYDVQQGEwJVUzETMBEGA1UECAwKQ2FsaWZvcm5pYTEWMBQGA1UEBwwNU2FuIEZyYW5jaXNjbzENMAsGA1UECgwET2t0YTEUMBIGA1UECwwLU1NPUHJvdmlkZXIxEzARBgNVBAMMCmRldi00NTU5NzAxHDAaBgkqhkiG9w0BCQEWDWluZm9Ab2t0YS5jb20wHhcNMTgwOTEyMTQzNzM2WhcNMjgwOTEyMTQzODM1WjCBkjELMAkGA1UEBhMCVVMxEzARBgNVBAgMCkNhbGlmb3JuaWExFjAUBgNVBAcMDVNhbiBGcmFuY2lzY28xDTALBgNVBAoMBE9rdGExFDASBgNVBAsMC1NTT1Byb3ZpZGVyMRMwEQYDVQQDDApkZXYtNDU1OTcwMRwwGgYJKoZIhvcNAQkBFg1pbmZvQG9rdGEuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAlveqreKkBgHRsCbxLCYAyEWydeqzbzNZ9MWElnE89n/Ums2CpWBh9b9lFZlJXr1eb+07E3jKROZQuzPV8z6Ds2G7jDv92apXJ1so2SZ7DVdE4kC8Z11ujbMW+F3WWeGK+vASdGYkIbcpXdgy42Whi7MWqw8vwFIC4rxJ7HffwSpQvc87+tICDO2jn/iVupoqTQhjyKg0iuJV4vli5D7ne7n0E5sn3AE0R3hLn+88Ufm7MZD8AXVEdna8t8/kqGYVrol7yLYlOPp8u+pNd0bkAQ3lBRJb6f/kch8ommlywzv7lZA9+d02xaHd0G2x/KJt6xqVHTBazK5fdbCKgV7fXQIDAQABMA0GCSqGSIb3DQEBCwUAA4IBAQBvb5Raz1XYOSVV7scdOwSzhf0r0GOBl9V2YNmLD8gCID5VknJHBD+riI8vHu2UkIh39s2c+4LISTQ9Gu0KCcI2LU8nXz9Xy3oGMEgYEUz7ZwmcZGU/bMIANjfdyhJ1kURMG0vQcjNMVpAvqna+mb1idFTwjK7ArEgaOxh/XoCNIZ9t1tkZh69DX09nUYTn1G3RIbyGGZ/7GY2dfSJubuhZnvK528QaowvRG/zGHYbwUdwgbJIMTX2eR1jHKTi3L5xM/hED/fPkbF880fheumiR9AAS3OB71DdiUM3LMc8iaZkTd7PTXvfw7TeSM9rf62Caimx0DhBjJhsuI6PyXxC4</ds:X509Certificate>
            </ds:X509Data>
        </ds:KeyInfo>
    </ds:Signature>
    <saml:Issuer>heimdall</saml:Issuer>
    <saml:NameID Format="urn:oasis:names:tc:SAML:2.0:nameid-format:transient">[email protected]</saml:NameID>
    <samlp:SessionIndex>id153704105052115878813602</samlp:SessionIndex>
</samlp:LogoutRequest>

Validation Errors:

Line: 8 | Column: 0  --> Element '{urn:oasis:names:tc:SAML:2.0:protocol}LogoutRequest', attribute 'ProtocolBinding': The attribute 'ProtocolBinding' is not allowed.

Line: 23 | Column: 0  --> Element '{urn:oasis:names:tc:SAML:2.0:assertion}Issuer': This element is not expected. Expected is one of ( {urn:oasis:names:tc:SAML:2.0:protocol}Extensions, {urn:oasis:names:tc:SAML:2.0:assertion}BaseID, {urn:oasis:names:tc:SAML:2.0:assertion}NameID, {urn:oasis:names:tc:SAML:2.0:assertion}EncryptedID ).

Sorry if this is wrong, I come from the elixir side which is why I'm not submitting a PR and testing.

{deps, [
    cowboy,
    {cowboy, "1.1.2"},
    {cowboy, "2.*"}
]}.

Failed load SP certfile

Shibboleth 3.3.2

• NameIDPolicy not used when Authn request is sent, NameID is missing in the reponse because of this.
• SLO request does not include NameQualifier and SPNameQualifier. Shibboleth is unable to match the session and returns error.

Is there are reason esaml is pinned specifically to Cowboy 2.6.0?

Can we update the constraint to allow Cowboy 2.7 as well?

The generate_metadata/1 has a type case error with the uppercasing of the HTTP-REDIRECT binding method. Correcting it to HTTP-Redirect passes this metadata validator and the builtin validator within the CA Siteminders suite.

The all uppercase binding method is not found in the the SAML 2.0 Metadata spec.

It would be nice to have support for Attribute Encryption. Attribute encryption is turned on by default in testshib.org. Since esaml does not support it, it fails to handle the success response for the authn request.

xmerl_dsig:verify/2 accepts the atom any (instead of a list of fingerprints). I think it would make sense for esaml_sp to accept this as a config option too. @handnot2 what do you think?

The auth response for SP initiated requests include the request ID (InResponseTo). Make this available in the esaml records. Expose the request ID in the assertion subject InResponseTo attribute. Make this available in the assertion subject record.

-record(esaml_subject, {
....
	notonorafter = "" :: esaml:datetime(),
	in_response_to = "" :: string()}).

This combined with notonorafter can be used during validations. This new field will be an empty string in case of IDP initiated flows.

As discussed here: handnot2/samly#28

I would like to be able to use samly with AAF - Australian Access Federation. However registration for AAF requires support for Artifact resolution - at least being my understanding.

The only recommended solution by AAF is to use the Apache shib module, which is a lot of overhead for a docker container and gets confused easily with a Docker environment (been there done that). I would like to be able to attempt to simplify this.

@handnot2 I've noticed merge requests have been sitting open a for a while, and with OTP 24 out now deprecated some functions used here, are you still interesting in maintaining this project moving forward? If not, would you consider letting others help out in some fashion?

I know this work has been hugely valuable for me to do some SSO integrations I would not have been able to do (via samly) otherwise, and am willing to pitch in to make sure both remain viable going foward.

According to the SAML RFC when using redirect binding and encoding method DEFLATE there should be no signature in SAMLRequest. It should be put in the url parameter.

[1] https://docs.oasis-open.org/security/saml/v2.0/saml-bindings-2.0-os.pdf (section 3.4.4.1)

Add an optional nonce parameter to encode_http_post function. When a nonce is passed in, include it in the script tag that handles auto form submission.

esaml currently uses tuple calls in a few places. As mentioned in OTP/21 release notes, support for tuple calls is removed from the runtime system.

I haven't looked too closely, but it seems like most "infractions" are in esaml_cowboy.

Since the allowed record type is already enforced to be only esaml_sp in the specs, it seems like replacing SP:some_fun(a, b, c) calls with esamp_sp:some_fun(a, b, c, SP) would do the trick and be entirely backwards compatible.