20

My hosting provider is offering an infrastructure-as-a-service (IaaS) product administered via a web interface, where the administrator can create and destroy virtual machines.

To access the web-based administration portal, I need to log in to the hosting provider's "service desk" (username & password over HTTPS), and then click on a generated link to access the IaaS administration portal (also HTTPS).

The link itself is most likely unguessable (it includes what looks like an md5 hash and 2 GUIDs), but anyone with access to that URL will have unrestricted access to the IaaS portal for several hours (the link seems to expire after that time).

I have tested that access via the link is not restricted to my specific IP address.

In short, anyone with the link could delete all of the VMs and my client's data, provided they get access to it within a couple of hours of it being generated.

Is this inadequate security for something like an IaaS portal (my gut feeling says no)? What specific concerns can I raise with the hosting provider?

Edit: I know that this question is similar to Is including a secret GUID in an URL Security Through Obscurity?, but that question relates to low-level HTTP clients, not browsers, which introduce additional concerns, like URL leaking, browser history, caching, etc.

Community
  • 1
Anonymous Ballstein
  • 311
  • 2
  • 6
  • i edited the question to highlight differences between that question and mine – Anonymous Ballstein Jun 17 '15 at 13:41
  • It's not really significantly different. It's also a material duplicate of https://security.stackexchange.com/q/58215/12 and https://security.stackexchange.com/q/83801/12 – Xander Jun 17 '15 at 13:47
  • 3
    Seems one simple implementation you could suggest would just be a Logout, which instantly expires/erases that URL instance. – Mike Guthrie Jun 17 '15 at 13:50
  • 1
    @AnonymousBallstein what about http://security.stackexchange.com/questions/89108/is-a-website-published-in-an-obscure-directory-comparably-secure-to-being-placed/89124#89124? I think it's (mostly) a duplicate except your own situation is not quite as bad. – Steve Dodier-Lazaro Jun 17 '15 at 15:02
  • Are it GUIDs or two 128 bit random numbers? GUIDs add an other problem: they are explicitly stated not suitable for cryptographic purposes, from your GUID you may be able to guess your neighbour's GUID. – Kasper van den Berg Jun 17 '15 at 16:01

1 Answers1

24

The problem with secret URLs is that they can be leaked in a variety of ways.

Images, Javascript, Stylesheets, and fonts can leak the URL of the webpage you are visiting. For example, if your secret page includes something like <img src="http://example.com" /> then when your browser grabs the image it may include the URL to the secret page in the Referer header. There are some use cases (https to http traffic, or browser overrides) that will prevent the browser from sending the header, but generally, this is a common way for your secret URL to be leaked.

While you can watch your own network traffic (use the "network profile" feature in Chrome or Firefox) when loading the page to see whether the URL is leaked, the main concern is that any change in the page could introduce a leak.

Two high profile cases of leaked secret URLs include Google Docs and Dropbox.

Is this inadequate security for something like an IaaS portal?

As I mentioned above, you could use the network profile feature of your browser to test whether the page is leaking the URL. However, the biggest concern is the fragility of this system. Unlike something like a password, the user has no control over the web page implementation, and accidentally including an external resource in a style sheet is far too easy. This isn't to say the system is insecure, just that it is a bit fragile.

If I were using the IaaS portal, I would ask that they include an additional access control mechanism beyond a URL that is easily leaked.

admin
  • 115
  • 5
amccormack
  • 3,971
  • 1
  • 15
  • 23
  • 1
    Usually, these links a "one time usage" links and once you follow it, you'll be given a cookie. Future third party usages by the same link won't be given the cookie and will be denied access. The authentication system used is probably OAuth . – Richy B. Jun 17 '15 at 13:55
  • In this case, its not a "one time usage" link - it can be used multiple times from different browsers & PCs, and navigating to the link provides full access. – Anonymous Ballstein Jun 17 '15 at 14:10
  • Isn't it true that the URL will be sent unencrypted over the local network ? So a proxyserver would get the unencrypted URL even if your connection to the server is HTTPS encrypted? So any man in the middle/dns spoof could access the URL ? – Falco Jun 17 '15 at 14:46
  • 2
    @Falco The DNS request will be sent in the clear. So the `subdomain.domain.com` portion of `http://subdomain.domain.com/secret-guid` would be exposed, but HTTPS protects the path and query string. MiTM would only pose a risk if HTTPS could be circumvented. – amccormack Jun 17 '15 at 14:49
  • @Falco unless there is a proxy that inspects SSL connections in the way, then no. You would detect such an attack by checking the certificate (unless you would have the rogue certificate installed in your system.) – Erbureth Jun 17 '15 at 14:50