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.)
Seems reasonable, because if STS is in effect the browser shouldn't ever
be talking to it over plain-old http, right? [At least to a first
approximation, sounds like there may be some details to think though?]
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.)
This will probably be hard to implement in practice, since we don't have
a singular or fast way to check if we know anything about site X.
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 is likely to be a problem... For example, as Twitter was in the
process of adding SSL I had frustrations where there were different ways
to login, some SSL and some not. And because the password manager
strictly enforces protocol matching, you'd be SOL.
OTOH, this is a frequent enough problem that I would like to look into
ways of having the password manager give the user a way to use an
existing login when similar enough. eg https://site.com vs
http://site.com, www.foo.com vs foo.com, etc.
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).
Possibly... Though I suspect most people will see it as a "whatever button."
I wonder if this should just be more general: if we see history for the
SSL version of the site, offer to redirect over to SSL. Though that
probably doesn't work for a lot of sites. So perhaps offer if you're (1)
on not-SSL and (2) there's SSL history and (3) there's any password
field (stored or not).
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.)
We store time-of-last-use, so this wouldn't be too hard to implement.
6) When connected to an untrusted wireless network, don't fill in passwords.
Someone needs to define "untrusted", but sure. ISTR Windows 7+ already
has such a notion. Might be able to usefully approximate this in the
browser by keeping track of which networks you've used in the last X
days, and treating new networks as untrusted.
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.
That's going to be a hard sell! :)
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.]
Justin
_______________________________________________
dev-security mailing list
dev-security@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security
