Closed Bug 162582 Opened 22 years ago Closed 22 years ago

need to hide some URLs from about:cache

Categories

(Core :: Networking: Cache, defect, P2)

Product:
Core
Component:
Networking: Cache
Type:
defect

Tracking

()

Status:
VERIFIED WONTFIX
Milestone:
mozilla1.3alpha

People

(Reporter: darin.moz, Assigned: gordon)

References

(
URL
)

Details

this bug results from the cache security review... there are probably some URL strings that we should hide from about:cache. for example, global history hides certain URL strings because they may contain sensitive data. global history is obviously a much more visible way of looking at visited URLs, but an attacker with physical access to a user's machine could just as easily load about:cache to see all visited URLs, including those hidden from global history. also along these lines, we might want to hide password data encoded in URL strings used as cache keys.
see bug 102043 for details on the URLs global history hides.
I think this bug should be public. It relies on physical access to the machine, so it's not really exploitable. Also, anyone who's reasonably savvy and has physical access can just get a copy of the cache files themselves and totally bypass our access control (unless we decide to encrypt the cache using the wallet master password, or something like that). So keeping this bug secret isn't really protecting anyone from anything.
roc: we were blocked at one point by some major sites because we would expose certain URLs via global history (in particular URLs that result in a redirect). that bug was fairly bogus and was really a problem with the sites. they should not be storing sensitive data in URLs! but, since we can't "fix the world" we've had to deal with this sort of stuff. so, while i totally agree with your assessment, i think we should be careful before we open this up. cc'ing arun for his take since he was involved with the global history issue from the evangelism side. arun: do you think we'd get the same sort of reaction from exposing these URLs via about:cache?
It requires physical access to the machine --OR-- taking advantage of a second security flaw that allows local file reading. And we just happen to have one of those at the moment.
Darin, could you please set a target milestone for a fix? Let's get this fixed before we make it public, to avoid any more evangelism hassles.
Whiteboard: [sg:publish]
i'd really like to know how important it is to fix this before we try to fix it. it is very useful to be able to see cache information for redirects and the like, so fixing this would hurt usability for developer types. it would start appearing as though we don't cache redirects when we clearly do. should about:cache be an add-on instead of a built-in feature? i'd almost like to WONTFIX this bug, unless evangelism can argue that it will be regarded as a problem.
Dare I say hidden pref? Since we are not sure what the reaction would be from certain website maintainers, and know that our developers would like to see them, how about hiding them by default but showing them if this pref is set?
Hidden pref sounds fine to me. We could even keep it off by default, with the option of turning it on if some stone-throwing site were to call us on it.
ok, a hidden pref sounds fine to me, but we might need help from the cache service for this... or maybe we can just invent a meta data tag ("hidden: true"). gordon: what are your thoughts on this?
mitch: please let me know if mozilla 1.3 alpha is not soon enough. do we want this fixed on the 1.0 branch?
Status: NEW → ASSIGNED
Keywords: mozilla1.3
Target Milestone: --- → mozilla1.3alpha
I'd rather add a flag to nsCacheEntry. It looks like we still have 15 bits left in mFlags. It might take less space than a metadata tag, depending on the percentage of entries thus flagged. I can take this bug.
Assignee: darin → gordon
Status: ASSIGNED → NEW
Priority: -- → P2
OK, it's hard for me to predict the existence of stone-throwing sites, but I still think we should do the fix (also cc'ing bclary for a second opinion). It is fair to note that "about:cache" and other "about:" URLs have traditionally been an NS/Mozilla thing which major sites don't know about/don't care about. As Darin mentioned, the fact that our history contained redirect URLs that were "sensitive" became an escalation between a well-known site and Mozilla browser(s). dveditz mentions that we're prone to an attack by some secondary flaw allowing third parties to access local files. Darin, if you recall, it was in fact the worry about an attack that exposes global history (for sensitive 302'd data) to third parties that caused the initial flare up way back when! Can someone explain why we *should NOT* do a fix that prevents sensitive URLs from being in about:cache? What can this fix hurt (other than time loss by a developer)? Isn't "about:cache" typically used as a diagnostic by developers anyway? If they wanted to see senstive URLs, they can toggle the pref. to see them. My vote: let's have a pref, but keep it ON by default, so sensitive URLs are NOT shown in about:cache by default. Developers who want to see what's going on in cache at all levels can turn it off and then tinker away.
agreed.
How are we meant to know what is 'sensitive'? (I presume we're talking https, since http requests are subject to interception/logging by a proxy server/etc) "we might want to hide password data encoded in URL strings used as cache key." is the closest anyone has come to a spec for this. Are you refering to <input type="password"> stuff? Are you planing to do with via some sort of 'sensitive-param: Foo' cache attribute which the form submission code sets, and about:cache reads, replacing the value for any params listed with XXXXX? That feels ugly to me. The fact that we're talking about adding a hidden pref to turn this off doesn't fill me with joy either :) Can't we introduce people who care about this to the HTTP POST method? Thats (partly) what its there for: Authors of services which use the HTTP protocol SHOULD NOT use GET based forms for the submission of sensitive data, because this will cause this data to be encoded in the Request-URI. Many existing servers, proxies, and user agents will log the request URI in some place where it might be visible to third parties. Servers can use POST-based form submission instead (RFC2616, 15.1.3/3, under "Encoding Sensitive Information in URI's") POST doesn't have any backwards compatabilty concerns, and it fixes this 'problem' in all clients, too. Re comment #4, anyone who can read about:cache + the local file system can get at the cache index file anyway, and read data that way - the cache path is given in about:cache, and thats a subdirectory of the salted profile path for almost everyone (see bug 162585). It is a fair bit more work, though, and not necessarily possible for any exploits (since you couldn't use DOM stuff on the binary index file, I suspect)
The site that gave us hard time last time knew about POST, but they had built on GET and changing it would be a massive investment they did not want to take at that point. Evangelising POST in an early enough phase could help, but we rarely have that luxury.
in the case of the site we were previous block from, it was also as a result of a 302 redirect.. so I don't know how/if we cache redirects, but we should hide those (as we hide them from global history)
alec: yeah, those are the URLs in question here. (we cache _all_ redirects for the purposes of offline browsing.)
Tree closes for 1.3alpha next Tuesday - can we get a patch by then?
Wontfix - we're going to propose removing about:cache from standard builds, in another bug
Status: NEW → RESOLVED
Closed: 22 years ago
Resolution: --- → WONTFIX
Clearing security flag for wontfix bug (see comment 2)
Group: security
V/WONTFIX.
Status: RESOLVED → VERIFIED
QA Contact: tever → benc
You need to log in before you can comment on or make changes to this bug.