17

Imagine a service that makes sensitive information available under a secret URL via HTTPS only, without requiring any other authentication. In fact, these are already widespread.

What level of security does this offer, compared to, say, a traditional HTTPS login form using a username/password that's saved in the browser?

Do browsers leak the HTTPS URL (barring undiscovered vulnerabilities, of couse) or is it, theoretically, as safe as local files on the machine running the browser?

Example leak vectors: Firefox crash reporter; Chrome find-as-you-type; IE malware protection service. All of these can potentially leak the URL to a third party. Are HTTPS URLs secure from this?

RomanSt
  • 1,180
  • 9
  • 25
  • 1
    Related: [Can URLs be sniffed when using SSL](http://security.stackexchange.com/questions/30976/can-urls-be-sniffed-when-using-ssl) - but different; that question is about the data contained in the request, not whether the browser leaks it through other channels. – RomanSt Apr 04 '13 at 14:17
  • 1
    There’s certainly nothing in the HTTPS protocol itself stopping browsers like Chrome from reporting every URL you visit to Google. – Timwi Apr 04 '13 at 14:21
  • 1
    @Timwi nor is there anything in the HTTPS protocol preventing Chrome hosting a remote desktop server and uploading all your passwords to a third party; that's not the point :) – RomanSt Apr 04 '13 at 14:22
  • [notpron](http://notpron.org/notpron/) was a very well-known 'browser-game' back in the day, and it relied almost entirely on secret URLs. – lynks Apr 04 '13 at 14:25
  • Please don't mark this as a duplicate of a question that is itself marked as a duplicate of another one... Better still, don't mark it as a duplicate at all because this question asks specifically about browser leak vectors other than the HTTPS protocol traffic and the general "attitude" of the browser towards the secrecy of the URL. – RomanSt Jun 22 '18 at 23:55
  • 1
    My thrust in this security site just sunk further.. Some easy vectors not mentioned here yet: If that webpage loads a resource from another domain, these wil be told the secret URL by referer. Such as but not limited to a webfont, css, js-library, badge or image. Its how analytics works. Also DNS servers gets the hostname part of the URL, and other LAN devices often can see that networktraffic in plaintext. Then on a PC also look beyond the browser, such as AV / webscan software that actively intercepts and reports your URLs. – Barry Staes Sep 04 '18 at 08:19

3 Answers3

19

In HTTPS, the actual URL is sent only after the SSL handshake has been performed. What outsiders can observe is:

  • The server name (which is given plainly in the server certificate).
  • The length of the request from your browser, from which the length of the URL can usually be inferred to some extent.

One potential trouble with "secret URL" is that they can be bookmarked or copied by the user (e.g. sent by email), and are also displayed on the user screen (in the URL bar), thus potentially vulnerable to shoulder surfers. For passwords and also for secure cookies (cookies sent by servers with the "secure" flag), the involved applications (namely browsers) are supposed to be a bit more cautious than with URL. Human users are also a bit less careful with URL than with passwords. On the whole, secret URL are a valid security mechanism, but you have to remain aware of the details.

Thomas Pornin
  • 320,799
  • 57
  • 780
  • 949
  • Do any known browsers send HTTPS URLs to third parties, ever? For example, Firefox crash reporter, or Chrome search-as-you-type, or IE's malware protection service? – RomanSt Apr 04 '13 at 14:41
  • Also the duration of the request may allow the attacker to determine if the user is reading cached content, or writing new content, ... or even running a long running SQL query for example. – makerofthings7 Apr 04 '13 at 14:55
  • The server name can be obfuscated away in multiple-wildcards certs, but SNI still gives it away. Not to mention DNS traffic. – user Dec 03 '15 at 20:52
8

What level of security does this offer, compared to, say, a traditional HTTPS login form using a username/password that's saved in the browser?

As you've gathered from other answers, HTTPS hides the actual request itself. The full URL is not sent when connecting to the server - the document part of the url is set as a request that looks something like this:

GET /login/reallysecure/thisismypassword

or more traditionally:

POST /login

with the POST parameters sent later on in the HTTP request either in plain form or as part of a multipart mime body.

One consideration you have probably not thought of is that url access is typically logged by webservers, meaning at any point in time you'll have say 3 days' (adjust for your log retention policy) worth of username logins one grep away from your systems administrators. Whilst this is arguably immaterial since a modification to the application itself could dump out ordinary login credentials without much difficulty, there is now an added protection factor - do you back up your logs? What happens if these are stolen?

Worse, what happens if there is a way to manipulate your server to return the logs to an external client? This is a massive breach of security, but unlike returning a database of passwords which hopefully use good hashing technique to mitigate (and it is very much mitigate) the impact of this, a URL doesn't have the same protection - it is simply instant access to the account in question.

This is the server-side end of the client-side risk Thomas has already highlighted.

2

The plaintext URL will likely be stored in the browser's history and cache files, but the URLs themselves will not be transmitted in the clear over the network, since the SSL session begins before any HTTP traffic is sent.

One other side-channel is that any non-HTTPS content in the HTTPS page might cause the URL of the main page to be leaked via the referrer header. Turns out the previous is false. Referer is not sent from HTTPS pages to HTTP pages.

Polynomial
  • 132,208
  • 43
  • 298
  • 379
  • 2
    The [HTTP standard](https://tools.ietf.org/html/rfc2616#section-15.1.3) says that browsers should not send a Referer header when the link is from a HTTPS-obtained page to a plain HTTP page. – Thomas Pornin Apr 04 '13 at 14:24
  • Did not know that. Updating answer. – Polynomial Apr 04 '13 at 14:25
  • 2
    @ThomasPornin - any idea if all browsers follow that standard? Sure they shouldn't, but standards don't always happen. It's probably still worth mentioning that a poorly implemented browser may still send the referrer, though it is cool to know that they are not supposed to. I also learned something there. – AJ Henderson Apr 04 '13 at 14:55
  • 2
    @ThomasPornin However, browsers still send the URL in the Referer when going from an HTTPS page to another HTTPS page in general, even if that other HTTPS page is on a completely different host. – Bruno Feb 18 '15 at 23:32
  • @Bruno Are you sure about that? I was under the impression that modern browsers don't leak the referrer between entities as per the Same Origin Policy (SOP). – Polynomial Feb 19 '15 at 20:28
  • Yes, I've tried. There's a [draft spec to try to have a bit more control](http://w3c.github.io/webappsec/specs/referrer-policy/), but the default is still "*No Referrer When Downgrade*". (It's relatively easy to check if you have an `https://` link to another site from an `https://` page somewhere with your browser's dev tools open.) – Bruno Feb 19 '15 at 20:40