Potential open redirect vulnerability

[riney]

Hello - I'm a software engineer with NERSC, the National Energy Research Scientific Computing Center operated by Lawrence Berkeley National Laboratory. We use thiss-js as part of our Federated Identity stack to allow scientific users to access center resources with credentials from their home institutions.

Recently, our lab-wide security organization contracted with a penetration testing company to identify potential vulnerabilities in our infrastructure. They identified an open redirect in the /ds endpoint - URLs of the form https://login-selector-dev.nersc.gov/ds/index.html?entityID=injected+title&return=https://www.google.com can send the user to any desired URL, along with a fake title.

This is seen as a roadblock for our continued FedID rollout - are there any possible remediations, including whitelisting, to limit where the identity selector is allowed to redirect the user?

Thanks in advance!

[leifj]

This is how the SAML discovery protocol works. The whitelist you are talking about is the SAML metadata that is used to limit who can actually talk to the endpoints. It is possible to use the SAML metadata to also limit what the ds will display but this is almost never implemented. If you can control the SAML metadata in use in your deployment this would be an option for a more strict implementation. The thiss-js code is implemented to support the SeamlessAccess where there is no chance to control all the metadata and therefore the UX would be pretty bad if we only limited the metadata to those entities that are able to provide discovery information in metadata. Iirc the dev version of thiss-ds will notify the user if the entityID isn't in the whitelist. I will ask @sunetzacharias to add some info here.

[leifj]

of course it is always possible to add options to thiss-js to allow a deployment to turn on more strict processing of SAML metadata... I'm just not sure it would result in a service that would work for you. This is really a fundamental problem with current SAML deployments and would affect any implementation of the SAML discovery service protocol equally. In a closed ecosystem where you control all SAML metadata this is relatively easy to solve and perhaps thiss-js should allow for that option...

[leifj]

For reference: https://docs.oasis-open.org/security/saml/Post2.0/sstc-saml-idp-discovery.pdf and in section 2.5 the metadata extension is described that would have to be present for this problem to be solved. This extension is almost never present but could of course be easily included in a closed ecosystem.

[sunetzacharias]

Hello @riney! Thanks for reaching out, and nice to hear about your use case. What you're pointing to is known to us. We have been made aware of this from our community, and have looked into it.

The background we have seen:

• It is up to the service provider to set the return URL - the URL the user should come back to after a successful login at the IdP. Setting the return URL can be viewed as an extra step of assurance, because the URL has been set beforehand; and has been set by someone with the ability to update the metadata with their federation operator.
• The use of return URL isn't mandated in the SAML specification, and though there is a de facto standard for it this isn't widely adopted among the service providers we have looked at in the metadata we have access to.
• SeamlessAccess is built and distributed in a way for the Standard and Limited integration that any service provider can use it without our knowledge and without a written agreement to follow some specific guidelines, i.e. we don't consider it our mandate to set any additional requirements for the community.
• Because of how lax the use of return url (from the SP:s we have looked at), this would mean a wide range of SP:s in our community would be unreachable by users

With this is mind, we have looked at how SeamlessAccess can help the users access while still being made aware of the lack of specified return url. Our best course of action looks a little something like this

• Return url specified (and correct)
  • don't show a warning
• Return url is specified but incorrect (SP is trying to return the user to a different URL than specified in the metadata)
  • show a warning indication to the user (and link to more information to make an informed choice if to proceed)
• Return url missing
  • show a warning indication to the user (and link to more information to make an informed choice if to proceed)

[enriquepablo]

Done in version 2.0.1