User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_12_3) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/56.0.2924.87 Safari/537.36 Steps to reproduce: (sorry for lack of example server in these steps) 1. Initiate a JSONP request containing sensitive params 2. Assume the response header will be `Cache-Control: no-cache, no-store` (indicating sensitivity) 3. Check `about:cache?storage=memory` for sensitive URL Actual results: The JSONP URL containing sensitive params is visible in an easily accessible page `about:cache?storage-memory`. But it is not cached to disk. Expected results: I think extra care should be taken to not show these sensitive URLs (where no cache was requested). Despite them not being cached to disk, they are still readily available in the memory cache view. For example, at a public terminal, it would be trivial for an attacker to peruse this memory cache for sensitive URLs if the previous user had not exited firefox.
FYI: bug 328835, bug 441751, bug 619376, bug 876431.
Component: Untriaged → Networking: Cache
Product: Firefox → Core
I agree no-store should not show up in about:cache.. honza disagrees and he owns it :) honza wontfix it you like
(In reply to Patrick McManus [:mcmanus] from comment #2) > I agree no-store should not show up in about:cache.. honza disagrees and he > owns it :) > > honza wontfix it you like It's cached (more and more subject to change my mind about this bit, tho), we use that entry. It has to be visible in about:cache, unless the caching schematics changes for no-store (or any combination of it). I'll WONTFIX this for now, but I'll start a discussion about changing how we handle no-store response cache directive.
Status: UNCONFIRMED → RESOLVED
Last Resolved: 2 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.