yahoo-eng-team team mailing list archive

[OpenStack Infra <2048493@xxxxxxxxxxxxxxxxxx>]

Reviewed:  https://review.opendev.org/c/openstack/horizon/+/914104
Committed: https://opendev.org/openstack/horizon/commit/ccef197e038a2cd3aa36fd0961686163c8524306
Submitter: "Zuul (22348)"
Branch:    master

commit ccef197e038a2cd3aa36fd0961686163c8524306
Author: Radomir Dopieralski <openstack@xxxxxxxxxxxxxx>
Date:   Mon Mar 25 12:10:11 2024 +0100

    Don't pass the auth_key for volume transfer in the URL
    
    Instead we pass it as data in the POST request.
    
    Closes-Bug: #2048493
    
    Change-Id: I9085eb146b8f013909f6369b731c076aba3216ab


** Changed in: horizon
       Status: In Progress => Fix Released

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to OpenStack Dashboard (Horizon).
https://bugs.launchpad.net/bugs/2048493

Title:
  Horizon exposes secrets via volume transfer URL

Status in OpenStack Dashboard (Horizon):
  Fix Released
Status in OpenStack Security Advisory:
  Incomplete

Bug description:
  Hey folks,

  During our latest annual penetration test of our OpenStack based
  cloud, it was discovered that Horizon, when creating a volume transfer
  to another project, provides a link to download the transfer
  credentials to a file which can then be saved. This link includes the
  transfer secret aka authorisation key, and is sent as a GET to the
  server.  The server code parses the URL, pulls out the UUID and
  authorisation key and the renders a template to be returned. The use
  of GET here exposes the authorisation key.

  As you're no doubt aware, sensitive information contained within URLs
  can be recorded in multiple locations, including the user’s web
  browser, the web server, and any forward or reverse proxy servers
  situated between the two endpoints. In addition, URLs are commonly
  displayed on-screen, bookmarked, or shared via email by users. When
  users follow off-site links, these URLs may also be revealed to third
  parties through the Referrer header. Therefore, inserting credentials
  into a URL heightens the vulnerability of them being intercepted and
  subsequently exploited by potential attackers (in this case the
  Referrer header is unlikely).

  To reproduce:

  1. Configure a browser to use an intercepting proxy such as Burp.
  2. Log in to Horizon as a user with privileges to manager volumes.
  3. Navigate to: ”Volumes” > ”Volumes”.
  4. Choose a volume then select the ”Create Transfer” action.
  5. Provide a transfer name then click the ”Create Volume Transfer” button.
  6. Observe that the ”Transfer ID” and ”Authorisation Key” are populated.
  7. Click the ”Download transfer credentials” button to download the credentials.
  8. Observe a URL like the following in Burp:
      GET / project / volumes /98fd<<redacted >>66b0/ download_creds /363e<< redacted >>27c1 HTTP /1.1
      Host: dashboard.example.com

  This is made worse by the fact that Cinder doesn't expire transfer requests:
      https://opendev.org/openstack/cinder/src/commit/4ee1bdaf648064adb6ad9f0e4fda6adc6ad1cbb6/cinder/transfer/api.py#L164

  Path match in Horizon:
      https://opendev.org/openstack/horizon/src/commit/fb1a3e88daf479b8fc5edcf26995fb860c76d05c/openstack_dashboard/dashboards/project/volumes/urls.py#L66 (and is present in master)

  Code in Horizon which generates the result:
      https://opendev.org/openstack/horizon/src/commit/fb1a3e88daf479b8fc5edcf26995fb860c76d05c/openstack_dashboard/dashboards/project/volumes/views.py#L672 (and is present in master)

  Ideally the generation of creds file would be fully in the browser,
  there is no need for a round trip to the server. If a round trip is
  necessary, then it should be via a POST and not include the transfer
  key in the URL.

  Kind regards,
  Andrew

To manage notifications about this bug go to:
https://bugs.launchpad.net/horizon/+bug/2048493/+subscriptions