21 Financial Sites Found To Store Sensitive Data In Browser Disk Cache 118
An anonymous reader writes "The LA Times mentions that after visiting well known sites such as ADP, Verizon Wireless, Scottrade, Geico, Equifax, PayPal and Allstate, sensitive data remains in the browser disk cache despite those sites using SSL. This included full credit reports, prescription history, payroll statements, partial SSNs, credit card statements, and canceled checks. Web servers are supposed to send a Cache-Control: no-store header to prevent this, but many of the sites are sending non-standard headers recognized only by Internet Explorer, and others are sending no cache headers at all. While browsers were once cautious about writing content received over SSL to the disk cache, today, most do so by default unless the server specifies otherwise."
Re: (Score:2)
Yep, being the very first company involved in the Prism surveillance system, I'm sure Microsoft knows this "snooping" Google does on your privacy well...
Reading fail (Score:3, Insightful)
but many of the sites are sending non-standard headers recognized only by Internet Explorer
Still, you got paid, what do you care?
Re: (Score:3)
The fail is your monkeyboy. (Score:2, Interesting)
Re:The fail is your monkeyboy. (Score:5, Informative)
Seems like it's mentioned there to me...
Re: (Score:2)
Re: (Score:2)
Re: (Score:1)
Maybe you missed it the first time it was pointed out [slashdot.org]... So I'm gonna jump in and help out a little, for those in the viewing audience who don't like to click links, and maybe you personally:
14.9.2 What May be Stored by Caches
no-store
The purpose of the no-store directive is to prevent the inadvertent release or retention of sensitive information (for example, on backup tapes). The no-store directive applies to the entire message, and MAY be sent either in a response or in a re
And that my friends (Score:3, Interesting)
Re: (Score:1, Informative)
Apple refusing to allow addons in their Webkit
Apple's browser's name is Safari. WebKit is the rendering engine.
Re: (Score:3)
Re: And that my friends (Score:1)
Chrome was based on WebKit up until a month ago so up until a month ago Chrome didn't allow plugins to address this? Pedantic may be pedantic, but wrong is still wrong.
Re: (Score:3)
Apple not allowing the what now? http://extensions.apple.com/ [apple.com]
Re: (Score:1)
Re: (Score:2)
But no caches suck for people with slow Internet like dial-up users. :(
"Despite Using SSL" (Score:3, Insightful)
What does SSL have to do with what happens to the data once it's local?
I understand that most people are clueless, but this is slashdot still, right? I haven't stumbled upon some other site on which to dig up TFA (not that I've read it).
Re: (Score:2, Informative)
As the summary says, browsers were once cautious about writing content received over SSL to the disk cache. The use of SSL provides a hint to the browser that the data is sensitive, but now browsers choose -- despite the use of SSL -- to store the unencrypted data anyway.
Re:"Despite Using SSL" (Score:5, Interesting)
That has never been the standard. And it would have violated several standards if you arbitrarily decided to not cache any ssl delivered data. Ssl was for protection of data in transit, not before or after the transmission is complete. The protection was not intended to outlive the actual connection.
You are confusing the recommendations for caching proxies with the recommendation for the intended endpoint.
Shift-reload every time you switch away (Score:3)
The standards don't *require* you to cache anything.
But if web browsers were to routinely do the equivalent of a Shift+reload every time the user switches away from and back to a browser tab because there is no cache, web server operators would likely be up in arms over bandwidth "abuse". They'd end up putting in a module to provide an intentionally low-bandwidth experience to users that don't cache, identified by their user agent or by a session cookie.
Re: (Score:3)
The standards don't *require* you to cache anything.
But if web browsers were to routinely do the equivalent of a Shift+reload every time the user switches away from and back to a browser tab because there is no cache, web server operators would likely be up in arms over bandwidth "abuse". They'd end up putting in a module to provide an intentionally low-bandwidth experience to users that don't cache, identified by their user agent or by a session cookie.
Ding ding ding! What has happened is the unintended consequence of sites using SSL as a blanket instead of a pinpoint. It used to be that the burden of encryption was only placed on the most sensitive of data, like a banking session or a protected site log-in, so caching it was de facto a bad idea since the user isnt likely to visit those specific pages often, and is never likely to want to see what was there the last time they visited. Now, with CPU cycles so cheap that we might as well encrypt everythin
HTTPS to avoid session cookie cloning (Score:4, Informative)
It used to be that the burden of encryption was only placed on the most sensitive of data, like a banking session or a protected site log-in [but there are] websites that dont have the need (encrypting your google searches? come on, they are spying on you anyway)
If you allow users to log in at all but don't encrypt everything, an attacker who can see a user's packets can snoop the user's session cookie and issue requests as that user for several minutes to several hours. The "Firesheep" plug-in, which allowed cloning the Facebook sessions of other users connected to the same wireless network, was the first widely reported incident of this.
Re: (Score:2)
It used to be that the burden of encryption was only placed on the most sensitive of data, like a banking session or a protected site log-in [but there are] websites that dont have the need (encrypting your google searches? come on, they are spying on you anyway)
If you allow users to log in at all but don't encrypt everything, an attacker who can see a user's packets can snoop the user's session cookie and issue requests as that user for several minutes to several hours. The "Firesheep" plug-in, which allowed cloning the Facebook sessions of other users connected to the same wireless network, was the first widely reported incident of this.
Technically you could do it with a lightweight hashing algorithm (have the login session put a private key in RAM and use it to sign whatever is sent back) but yes switching to all SSL is an easier and more complete way to prevent MITM attacks. Good thing SSL is ubiquitous now that we have so many important things to do on Facebook...
Re: (Score:2)
You've got RAM, use it.
Re: (Score:2)
You've got RAM
True on desktop, not nearly as much on mobile.
Re: (Score:2)
My phone has 800mb of RAM. 8 years ago my desktop had half that.
Social widget filled monstrosities (Score:2)
Re: (Score:3)
And it would have violated several standards if you arbitrarily decided to not cache any SSL delivered data.
What part of the standard? Last I knew, you're not required to cache any data, and what data you choose to cache and not cache is up to you, unless the headers tell you otherwise.
Re: (Score:1)
Re: (Score:2)
There is no reason to decrypt the data before caching. It's a flawed design.
Clearly you know nothing about how decryption works.
Once you close the session, the decryption key is lost. You won't be able to decrypt it later unless you also save the session key.
Using your line of reasoning, The person reading the screen is just another node along the chain. Perhaps their knowledge should be
scrambled as soon as they step away from the screen?
Simple (Score:3)
Make all you sensitive transaction from a live read-only image of the OS.
...
My apologies: I forgot that, in this imperfect world, there are hardware/OS-es which can't be booted from a live image.
(ducks)
Re: (Score:2)
Overcomplex solution. Use a crypted partition/LVM volume/whatever to store your personal data: this will also helps if your computer is stolen.
Overcomplex solution. This is cache data; not data you wish to keep for its own sake. Just set your browser to keep its cache in /tmp and it will be cleared at every boot.
Re: (Score:2)
Overcomplex solution for this specific problem (you might have other reasons)
As the article states, if you don't want anything cached Use Private Window/Incognito mode.
Or Safari, Safari doesn't cache at all for HTTPS.
Bandwidth bill (Score:3)
Safari doesn't cache at all for HTTPS
Perhaps this is why certain web sites don't support HTTPS at all: because Safari users would run up their bandwidth bill.
Re: (Score:2)
I don't understand why all OS's are read only.
Why haven't we broken the OS down into a read only and configuration/data sections yet? OS's themselves only get updates occasionally. a secure reboot install updates, and reboot again into read only mode.
Now if you do get a virus you reboot, if it manages to stay around in your data you can purge it easier.
Re: (Score:2)
Most system files are only writable by the root user. What is the difference between `read-only' and `only writable by root' in practice?
Hm, the practice of "lets put this button in front of the user that they can click to become root!" might be part of it...
Re: (Score:2)
Privilege escalation, for one.
Re: (Score:2)
"root" may not be the highest authority, and the read-only state of the files could be enforced above that. (since we are talking about theoreticals, we don't have to limit ourselves to the way things are typically done currently)
Re: (Score:2)
java and firefox are userspace applications, not operating system components (contrary to what Oracle or Mozilla would want to convince you)
Reboot every few days (Score:2)
OS's themselves only get updates occasionally.
For one thing, "occasionally" has tended to mean every couple days. Unlike Windows security updates, Ubuntu security updates don't wait until the operating system is on its period [wikipedia.org] to correct known defects. For another, some applications get updates on a schedule that doesn't line up with operating system updates. Would you want to have to disconnect from chat channels, pause your streaming music, log out all users, and reboot the system every time one of the many applications on your system gets an update?
Re: Reboot every few days (Score:1)
I said OS not applications. I didn't even mention The GUI layer which could go on either side.
The problem we have is applications require direct hardware access. You have a broken OS when a web browser plugin requires direct hardware access(flash).
Your use of "direct hardware access" confuses me (Score:2)
The problem we have is applications require direct hardware access. You have a broken OS when a web browser plugin requires direct hardware access(flash).
What sort of kernel-level "direct hardware access" does Flash Player perform? I wasn't aware that Flash Player was making disk writes at the sector level (not the file level) or writing to individual I/O ports or anything. What sort of indirect hardware access would you recommend instead?
Re: (Score:1)
From the article to which you linked.
Re: (Score:2)
If anything, the binaries are the lesser risk - binaries can be signed, signing configuration is not so easy.
Safari doesn't cache at all (Score:5, Informative)
From the securityevaluators.com document (2nd reference in the base article): Safari. Apple Safari does not cache HTTPS-delivered content to disk, regardless of any headers sent by the server. ISE tested the mobile version of Safari on an iPad 2, and the HTTPS caching behavior was identical to the desktop version.
This is actually a very bad idea, if true (Score:3, Interesting)
Re:This is actually a very bad idea, if true (Score:4, Insightful)
Re: (Score:2)
It would be interesting if caching could be defined per element - so you could cache everything on a page except for the sensitive elements (without relying on framesets or other kludgery)
Re:This is actually a very bad idea, if true (Score:5, Insightful)
Note that the claim is that Safari doesn't cache to DISK, not that Safari doesn't cache. I.e., Safara doesn't store information that was deemed sensitive enough to require a secure channel on a long-term (probably unencrypted) storage medium.
Re: (Score:2)
Given that disk caching is the real concern, I don't see your point.
Scaremongering (Score:2, Insightful)
Re: (Score:1)
If someone's using a shared computer, or if they let someone else use their computer, they might reasonably expect their banking information to be inaccessible after they've logged out of the bank's website.
If it turns out that information is accessible when people don't expect it to be, that's a real security problem, and neither "scaremongering" nor "BS".
Re: (Score:3)
A shared computer should not let users see other users' private files (and browser caches are most definitely not world-readable). This is what happens with Android multi-login, Chrome OS and traditional Linux distros. I'm fairly certain the same is also true for Windows and Mac OS X.
If I temporarily let someone use my computer with my account, I sure as hell keep an eye on what they are doing, because the thing contains stuff about me that's much more sensitive than anything that paypal or my bank will eve
Re: (Score:1)
You are thinking about a multi user system, where each person has his own login.
That's not the case if you use a shared computer e.g. at the library.
Re: (Score:1)
Not everyone can afford their own computer and internet access. Public libraries are still a very valued asset by many people.
Re: (Score:2)
Bring your own device (Score:2)
Re: (Score:2)
Yes! Let them eat cake!
Re: (Score:2)
Re: (Score:3)
If you're not using your computer, you should expect keyloggers and never sign into anything which doesn't have 2-factor authentication.
ineffective (Score:2)
Re: (Score:1)
Not true. Just because the attacker has full access to an incorrectly configured /tmp directory (or equivalent) doesn't mean they have full access to everything you do.
Re: (Score:2, Interesting)
Well considering the general quality of networks, improperly secured routers, and secondary infection points via home networks and 'open disk' access that things like Windows love to do when you use that lovely auto-config tool. Chances of leaving a wide-open door, and letting them win are pretty good.
Re: (Score:2)
The point is, if all this data is cached to disc, if you hardware is EVER compromised... now or in the future... they have it. If it weren't cached, then they'd have to attempt to circumvent the banks security system. I think the most likely scenario here is your laptop gets stolen, the thieves search for images and find all kinds of pictures of old checks in your cache folder.
AES cache (Score:3)
if all this data is cached to disc, if you hardware is EVER compromised... now or in the future... they have it
Then encrypt the cache with a secret key that changes every time the browser is restarted. A key won't last very long in a powered down system unless the attacker does the highly visible operation of physically freezing the RAM.
Re: (Score:2)
That is BS. There are plenty of scenarios in which an attacker having read access to your browser cache is significantly less privileged than the sensitivity of information discussed here.
Re: (Score:2)
not looking hard enough (Score:2)
Hmmm (Score:2)
This is my first rule. The solution.. whole drive encryption. The tinfoil hat of secondary storage.
Re: (Score:2)
That protects you against someone stealing your hard drive -- which is a pretty reasonable fear if you have a laptop. It does nothing against malware, which is enormously more common.
Re: (Score:2)
Interesting second link (Score:5, Interesting)
With a well-written and refreshingly non-partisan review of why and how this happened, showing that, as with many cluster-fsuks, it's the result of a chain of decisions where each seemed sensible at the time.
Everybody dropped the ball here:
- website owners & authors too incompetent or lazy to keep abreast of standards and changing conditions,
- Microsoft for being, well, Microsoft (not really respecting standards),
- Google (Chrome) & Mozilla for changing the default behaviour of their browsers to store https traffic instead of not, (although this, ironically, is the standard unless the site properly says "do not store"; see point 1.)
Raises the interesting question; who on earth thought, in this era of increasing bandwidth, that it would be a good idea to store https data locally?
Re: (Score:3)
Cap (Score:2)
in this era of increasing bandwidth
What "era of increasing bandwidth"? ISPs have tended to switch home Internet plans from uncapped to capped. Satellite and cellular, for example, usually have a cap of 10 GB/mo or less.
Long story (Score:1)
I recall many years ago spending almost an entire day trying to really understand what is up with the caching headers. There is what you read in the RFCs and there is reality.
The early dialup days brought with it some creative tweaking of meaning of headers during the great IE/mozilla wars in persuit of the fastest browser in all the world...Insanity propogated by caching proxy vendors thrown into the mix lead to none of this shit actually working the way it was supposed to.
No-store wins but to this day I
It's Chase now (Score:2)
Bank One as their "basic" security scan open every TCP request on your server
Would this happen to be a bank that got bought by Chase [wikipedia.org]?
Disk cache (Score:2)
Simple: a web browser should not save any content from encrypted sources.
Additionally: why do we even have browser disk cache in place anymore? Most of the pages of modern web are dynamic (cgi-bin), so you never want old copies anyway.
Re: (Score:2)
Page load time, you really want to download all the images, css, js, etc. all over again every time you visit a site ?
Static files really are static files:
http://yuiblog.com/blog/2007/01/04/performance-research-part-2/ [yuiblog.com]
Re: (Score:2)
Additionally: why do we even have browser disk cache in place anymore? Most of the pages of modern web are dynamic (cgi-bin), so you never want old copies anyway.
Web servers tell the browser not to cache dynamic pages. (So, for dynamic pages, it's like there is no disk cache!) But the bulk of the data is in static resources used by those dynamic pages, like images and Javascript libraries.
This is why I still use IE from time to time (Score:2)
.
Confirms what I've suspected ... (Score:4, Interesting)
This pretty much confirms what we've all known for a long time -- the security of these things is largely written by people who are unqualified to write secure applications, and people who write IE specific stuff write shit code.
Your financial information is being handled by people who are either lazy or incompetent, and the company is more interested in the spinning, flaming logo than anything like security.
It would be a mistake ... (Score:2)
Firefox fix (Score:2)
With Firefox you can make the cache stay in RAM with the following about:config settings:
browser.cache.memory.enable =True
browser.cache.disk.enable = False
browser.cache.memory.capacity = 512000 (or whatever you prefer)
The alternative for all browsers is to put the disk cache on a RAM drive.