Secret Location header can be modified by modifying request Host header

[Steve Heyman]

It appears that modifying the "Host" header changes the "Location" header returned on successful secret creation. This does not modify the actual stored secret_ref, as shown below.

POST /v1/secrets HTTP/1.1
Content-Length: 246
Accept-Encoding: gzip, deflate
X-Project-Id: 3793662244d04d2c96edb3a52808cd2b
Connection: keep-alive
Accept: */*
User-Agent: python-requests/2.5.1 CPython/2.7.5 Darwin/13.4.0
Host: google.com
X-Auth-Token: [VALID TOKEN]
Content-Type: application/json

{"name": "AES key", "algorithm": "aes", "payload_content_type": "application/octet-stream", "payload_content_encoding": "base64", "mode": "cbc", "bit_length": 256, "payload": "gF6+lLoF3ohA9aPRpt+6bQ==", "expiration": "2018-02-28T19:14:44.180394"}

HTTP/1.1 201 Created
Location: http://google.com/secrets/b257d5e1-a091-464f-badd-4c6a51b0d42b
Content-Length: 87
Content-Type: application/json; charset=UTF-8
Connection: close

{"secret_ref": "http://localhost:9311/v1/secrets/b257d5e1-a091-464f-badd-4c6a51b0d42b"}

GET /v1/secrets/b257d5e1-a091-464f-badd-4c6a51b0d42b HTTP/1.1
Content-Length: 0
Accept-Encoding: gzip, deflate
X-Project-Id: 3793662244d04d2c96edb3a52808cd2b
Accept: */*
User-Agent: python-requests/2.5.1 CPython/2.7.5 Darwin/13.4.0
Connection: keep-alive
X-Auth-Token: [VALID TOKEN]

HTTP/1.1 200 OK
Content-Length: 364
Content-Type: application/json; charset=UTF-8
Connection: close

{"status": "ACTIVE", "secret_ref": "http://localhost:9311/v1/secrets/b257d5e1-a091-464f-badd-4c6a51b0d42b", "updated": "2015-02-10T18:01:22.630023", "name": "AES key", "algorithm": "aes", "created": "2015-02-10T18:01:22.624558", "content_types": {"default": "application/octet-stream"}, "mode": "cbc", "bit_length": 256, "expiration": "2018-02-28T19:14:44.180394"}
=== Impact: ===
Could allow an attacker to maliciously redirect the user to a site that the attacker controls. This would have to be a second-order attack, e.g. it would have to cause a problem with some consumer of Barbican; it doesn't really create a vulnerability in Barbican itself.
=== Systems Vulnerable: ===
Local environment
=== Suggested Mitigation: ===
The fix would likely be simply using the same secret_ref in the Location header, rather than constructing it off of the "Host" header.
=== Further References: ===
No references given

[Steve Heyman (sheyman)]

the location header is updated by webob - see https://github.com/Pylons/webob/blob/master/webob/response.py#L1027

[OpenStack Infra (hudson-openstack)]

Reviewed: https://review.openstack.org/157231
Committed: https://git.openstack.org/cgit/openstack/barbican/commit/?id=d88f89f45b7022366cd24706058db691b96b7233
Submitter: Jenkins
Branch: master

commit d88f89f45b7022366cd24706058db691b96b7233
Author: Steve Heyman <email address hidden>
Date: Wed Feb 18 19:13:50 2015 -0600

    Fix security bug with host HTTP header field

    Previously a user could place any value the host header of their
    http request to Barbican and the result returned would have
    the correct URL in the body, but the response location header was
    built using the provided (and possibly malicious) host value from
    the request header.

    Resolved this by ensuring that the location header in the response
    field matches the URL returned in the body.

    Also added functional tests to ensure that this exposure won't
    reappear.

    Change-Id: I49a9e44be68b20f7602cf58202dd8e522a0c25c3
    Closes-Bug: 1421479