Comment 9 for bug 1980349

Revision history for this message
Brian Rosmaita (brian-rosmaita) wrote :

Just want to note that the WEBSSO_USE_HTTP_REFERER option was introduced by change I9c5c8d59c5f5a8570dbb5 and is present in all stable branches. Unfortunately, its default value is True. Plus, it only works for a single Keystone URL. But it's there.

Since the source of the exploit seems to be this:

curl -v 'http://horizon-name:8080/auth/websso/' -X POST -H 'Referer: https://referer:5001/' -H 'Content-Type: application/x-www-form-urlencoded' --data-raw 'token=mytoken'

I agree with Swen's suggestion that the quickest way to fix this would be to configure the webserver hosting horizon to only accept requests to /auth/sso from known IP ranges from which the external federated horizons will be making requests. Whether this will be effective depends on how tightly the IPs are controlled in the federated clouds ... if it's the entire IP range of Cloud X, then it's only going to be of limited use.

Another option would be a Horizon change to add an allowlist of keystone URLs, and then the horizon sso code will only use a HTTP_REFERER value that's in the list. I'm not sure where this would fit in the priorities of horizon developers, though.