Take the 2-minute tour ×
Information Security Stack Exchange is a question and answer site for Information security professionals. It's 100% free, no registration required.

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?

share|improve this question
1  
Related: 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. –  romkyns Apr 4 '13 at 14:17
    
There’s certainly nothing in the HTTPS protocol itself stopping browsers like Chrome from reporting every URL you visit to Google. –  Timwi Apr 4 '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 :) –  romkyns Apr 4 '13 at 14:22
    
notpron was a very well-known 'browser-game' back in the day, and it relied almost entirely on secret URLs. –  lynks Apr 4 '13 at 14:25

3 Answers 3

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.

share|improve this answer
    
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? –  romkyns Apr 4 '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 4 '13 at 14:55

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.

share|improve this answer

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.

share|improve this answer
2  
The HTTP standard 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 4 '13 at 14:24
    
Did not know that. Updating answer. –  Polynomial Apr 4 '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 4 '13 at 14:55

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.