Slashdot Mirror
21 Financial Sites Found To Store Sensitive Data In Browser Disk Cache
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."
would be why I have no Internet Cache. Disabled immediately after install. What is also concerning is the myriad of other client side data storage techniques (to include the newer ones with HTML5) Firefox does a pretty good job with plugins and Chrome to some extent as well, but with Apple refusing to allow addons in their Webkit and Microsoft doing whatever it does with IE, this issue is likely to get worse as technology continues to evolve.
Select from tblFriends where interesting >= 4;
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).
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)
Questions raise, answers kill. Raise questions to stay alive.
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.
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 ever know.
There's a hidden treasure in Python 3.x: __prepare__()
If you're not using your computer, you should expect keyloggers and never sign into anything which doesn't have 2-factor authentication.
Help I am stuck in a signature factory!
This actually decreases security. Browser caching is strictly necessary to make the web work fast, disabling it for HTTPS means discouraging websites from using secure connections for anything where it's not strictly necessary (like money). And $DEITY knows we live in a world where every website should be secure by default. You wouldn't use telnet even for a completely non-sensitive server, so why accept unencrypted HTTP to post on slashdot or anywhere else?
There's a hidden treasure in Python 3.x: __prepare__()
but many of the sites are sending non-standard headers recognized only by Internet Explorer
Still, you got paid, what do you care?
systemd is Roko's Basilisk.
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?
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.
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.
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.
Lost at C:>. Found at C.
Maybe you should try reading the second link from the summary and take a look at the standard heads. What you would find is that the standard is "no-cache". Chrome and Firefox use the non-standard "no-store". But, guess which browser supports three different headers, and the only one to actually support the standard? IE.
There is no "-1 offended" or "-1 you don't agree with me" mod options for a reason.
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.
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.