Validate acs url

[jphenow]

Matching standard (line 2063) so that IDP performs validation on the AssertionConsumerServiceURL field to match Metadata Host or some other configured Host to prevent MitM attacks

[jphenow]

@ikkisoft @itstehkman does this make sense? I have to update docs before merging, but basically this would make it so ACS URLs are whitelisted based on the Host of the metadata URL or the list from config.assertion_consumer_service_hosts - based on what you know does it make more sense to configure it on a per-service-provider basis? Should we not even assume based on metadata URL? I'm also considering make this an enabled feature that's disabled by default for now to prevent breaking changes for this version.

[ikkisoft]

My understanding of the Destination (saml 2 core lines 1477-1482) vs AssertionConsumerServiceURL (saml 2 core lines 1483-1488) is that they're the same value, but just used for different purposes:

• Destination is the URL of the endpoint where the Service Provider is expecting the response
• AssertionConsumerServiceURL is the same URL within the IDP request, where peer IDP must send the response to

So, I think you can simply use the value you already have in the config for the service_provide and not the metadata URL.

some-issuer-url.com/saml --> some-issuer-url.com

service_providers = {
    "some-issuer-url.com/saml" => {
      fingerprint: "9E:65:2E:03:06:8D:80:F2:86:C7:6C:77:A1:D9:14:97:0A:4D:F4:4D",
      metadata_url: "http://some-issuer-url.com/saml/metadata"
    },
  }

If you allow override via config file (as implemented), I think is safe enough to enforce it since people can change the config after the new deployment. Especially, if it's clear in the README.

Btw, reading the standard (http://docs.oasis-open.org/security/saml/v2.0/saml-core-2.0-os.pdf line 2063) they are actually saying that the IDP is required to perform validation on the AssertionConsumerServiceURL field:

The responder MUST ensure by some means that the value specified is in fact associated
with the requester.

[ikkisoft]

ruby-saml (https://github.com/onelogin/ruby-saml) seems to have three separate fields for those items:

• settings.assertion_consumer_service_url = "http://#{request.host}/saml/consume"
• settings.issuer = "http://#{request.host}/saml/metadata"
• settings.idp_sso_target_url = "https://app.onelogin.com/saml/signon/#{OneLoginAppId}"

So, this is probably the safest / most flexible option.

[ikkisoft]

For this issue, you can use CVE-2018-18604 (in case you will send out security update notices, etc.)

[itstehkman]

I agree with @ikkisoft. I think this PR is mostly good. The only issue I see is if you've configured the IdP with N acceptable_response_hosts, where one of these could maliciously accept a response meant for another host:

EG:

acceptable_response_hosts = [A, B]

I make a SAMLRequest for host A, and it gets maliciously modified such that its Destination / ACS URL is sent to B instead. In the unlikely case that B would accept the assertion, this is an issue.

I think it is simpler and more accurate to just have this on a per-service-provider configuration level without checking a set of acceptable hosts.

[itstehkman]

also small nit: typo -> acceptable_response_hosts

[itstehkman]

@jphenow is this ready? I think this implementation should suffice.

[jphenow]

Updated to set on per-service-provider basis with a list just for flexibility. If that's a security hole I deem that a hole on their configuration, not the lib. Let me know what you think and I can make a minor version release later today or tomorrow

[itstehkman]

@jphenow this looks great! Thanks for the updates. LGTM.

[jphenow]

Released as 0.8.0