Retrieving secrets from untrusted URIs can leak auth tokens

[Adam Harwell]

If a user (or more importantly, a service) attempts to fetch a Secret/Container/Order using a malicious URI, it will leak a valid user token to a potential bad actor.

Example:

A service allows a user to provide a Certificate and Private Key in the form of a Barbican Container URI.
Malicious user Tim stands up his own server at https://hacking.your.stuff.com/ which simply dumps all of the data from any reqest to a log file.
Tim provides a "properly formatted" yet malicious Container URI to the service: https://hacking.your.stuff.com/v1/containers/C7AC0DDA-468B-4910-AC75-10B9EB4F7F0A
The service generates a Keystone token and passes it in the headers of a GET request to the provided URI.
Tim retrieves the valid token from his logs, and uses the service's token to access other resources (either belonging to the service, or possibly other users depending on the access level of the service's account).

This can be mitigated by validating that any URI provided to the client matches one of the Barbican endpoints in the user's Service Catalog in Keystone (to which the client should already have access).

*Possibly* there could be an additional flag similar to '--insecure' to bypass this restriction, but it would by no means be the default option.

[Douglas Mendizábal (dougmendizabal)]

Marking this as "Won't Fix" after a conversation I had with Paul Kehrer a while back. In this scenario it is the responsibility of the service that receives the customer data to validate the data before acting on it.

[John Wood (john-wood-w)]

Hmmm, well I think it is Barbican's responsibility to verify that secret refs provided in containers really do resolve to that Barbican installation. Is there a use case for having secrets from other Barbican regions/locations in another Barbican's container? I added this question to the midcycle etherpad (https://etherpad.openstack.org/p/barbican-kilo-sprint).