There are some great ideas here. I think we should create a feature
page for at least #1&2 and add it to the Security Roadmap. I also think
we can do #5.
To go into detail...
On 4/11/12 12:54 AM, Jesse Ruderman wrote:
1) If a site sends an STS header, and the user has any data (cookies,
passwords, etc) that are not https-only, immediately mark that data as
https-only. (This helps if a site uses STS, but the user's privacy
settings cause the password storage to outlive the STS storage.)
If a site is marked STS but a website (or by a user with ForceTLS), then
there is no reason to have http data for that site.
2) When clearing history, retain the STS bit if any other data
associated with the site is retained. For example, in the common case
of clearing all history other than passwords, retain the STS bits for
sites that have passwords stored. (This accomplishes roughly the same
thing as #1.)
If we are saving data from the site that can be used for fingerprinting
anyway, retaining the STS bit shouldn't cause any further fingerprinting
issues.
3) If you have a password stored for http, and you log into the same
site using https, move the password to https-only. (This helps if a
site moves from http to https, but does not set STS.)
This doesn't really work. Twitter and Facebook have login on both http
and https pages. So sometimes the users password will be auto-filled
and sometimes it won't. Hence, I think this proposal is out.
4) If an identical password is stored for both any http site and any
https site, stop autofilling it on the http site. Instead, provide a
way for users to instruct the browser to fill it in (e.g. an infobar).
I don't think this is going to fly either. Users will constantly get
this infobar on the http versions of facebook and twitter.
5) If an identical password is stored for both any http site and any
https site, and it is not used on the http site for 16 months, expire
the http version. (This helps in cases where the hostname has changed,
e.g. from mail.google.com to www.google.com, and the security level
has also changed.)
Sounds good.
6) When connected to an untrusted wireless network, don't fill in passwords.
We aren't sure what networks are trusted vs untrusted. Instead of
starting with a heuristic that tries to guess this, what if we start off
with including an "network untrusted" mode in Firefox. When a user
enables this mode, passwords aren't auto-filled and inactive tabs aren't
allowed to send/receive requests. This way, when I connect to wifi at
an airport/hotel and have 3 windows open with 10 tabs each, there are no
http requests going out from any of the tabs except for the 1 active tab
I'm using. The user is aware they are using the active tab and is aware
of what websites they are visiting via http (and hence which cookies
they are exposing).
(Whenever I connect to an untrusted network, I first turn firefox to
work offline mode. Then connect to the network and vpn in. Once I'm
vpn'ed, I take firefox off work offline mode. This way, no requests are
sent with my cookies from one of my open tabs before I have a chance to
vpn. Yes, I know I am paranoid).
7) When connected to an untrusted wireless network, refuse to make any
insecure connections. If the user really wants to open an insecure
search result, they can open it in a separate browsing session.
I also don't think this will fly.
Adding 8 from Justin Dolske:
8)
One additional mitigation: refuse to autofill within iframes. Bulk
harvesting would seem harder (or at least slower) if an attacker if
forced to cause new windows/tabs to open. Well, maybe... I guess if
you're allowing page modifications, one just needs a window.onload
handler to navigate to the next site on the list. [Insert side
discussion here about stealing login-cookies from site's you're already
logged into.]
What if a site allows login via an iframe widget (ex: twitter had a
widget that did this a little more than a year ago, and maybe still
does). This would break all sites that have their login form in an iframe.
~Tanvi
_______________________________________________
dev-security mailing list
dev-security@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security
