381572 - RFE: Allow users to override the “Secure” attribute of cookies from “not set” to “set” (via the GUI)

Status: RESOLVED WONTFIX

(Firefox :: Security, enhancement)

Description

[Nico R.]

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; de; rv:1.8.1.3) Gecko/20070403 Firefox/2.0.0.3
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; de; rv:1.8.1.3) Gecko/20070403 Firefox/2.0.0.3

HTTP cookies have a “Secure” attribute, which is specified in RFC 2965, section 3.2.2, at the top of page 7. The intent of setting this attribute is that the user agent does not send the cookie back over a connection which is less secure than the one which was used when the cookie was initially set.

Unfortunately, many web sites do not set this attribute at all even in cases when it would be useful. For example, the Bugzilla login cookie(s) for Bugzilla at <URL:https://bugzilla.mozilla.org/> do not have the attribute set. Another example is the login cookie set by SourceForge.net servers <URL:https://sourceforge.net/> on login.

When you first (securely) log in to a website via HTTPS, but later (for example, by accidentally following a link) use HTTP to retrieve something on the same website, this causes your login information to be transmitted in plain over the wire.

The problem is even more severe for mixed-mode (secure+insecure) web pages. Log in to mozdev.org’s Bugzilla using the exact address <URL:https://www.mozdev.org/bugs/index.cgi?GoAheadAndLogIn=1> (and run a traffic monitor) to see the problem. Ordinary users can hardly do anything to prevent this from happening (okay, there is bug 321022, of course, which might get fixed someday …).

So I propose to allow users to manually override the “Secure” attribute, at best using the GUI. This setting could take into account the host/domain, path, and/or cookie name (must evaluate what is actually useful). Users should only be able to /set/ “Secure” if it is not set, not the other way round.

By using this feature, users could make sure they don’t expose private information through their cookies if they normally use HTTPS for doing whatever they do which needs a cookie on the respective website, even if the website is not secured properly.

Reproducible: Always

Steps to Reproduce:
Example which uses a Bugzilla account on mozdev.org:
1. Go to <URL:https://www.mozdev.org/bugs/index.cgi?GoAheadAndLogIn=1>.
2. Start a traffic monitor.
3. Log in to mozdev.org’s Bugzilla and see your login cookie be transmitted in plain.
Actual Results:  
Exposure of login information due to misconfigured webserver/scripts.

Expected Results:  
User could have set “Secure” for mozdev.org or for “all sites which I access via HTTPS” first.

Browser would not have sent the cookie via HTTP, but only via HTTPS.

There is bug 165334, which takes another approach, but can also help in the situation described above.

Comment 1

[Samuel Sidler (old account; do not CC)]

Not sure if this is a dupe, so not confirming, but seeing what johnath thinks.

Comment 2

[Johnathan Nightingale [:johnath]]

I think, prima facie, that this kind of decision is well beyond the capabilities of the large majority of our user base.  That isn't an instant deal-killer, we have lots of hidden areas that exist for power users, and this idea is obviously a nice-to-have in that regard, but I do see it as a pretty specialized capability.

To me it falls into the same realm as other cookie editing requests like bug 355048 which are really all just subsets of bug 87296.  Bug 87296 is WONTFIX, in theory a smaller, more containable subset might be acceptable, but it's not clear to me that this rises to the level of being that much more important than general purpose editing.  

When I see a really good idea for a feature that is unlikely to be used by the majority of users, I think "add-on."  There are, of course, multiple cookie-editor addons out there.  I think that's the right place for this to live, vs adding code to the browser everyone gets to support a good-but-rare idea.