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).
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.
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 real problem here is the standard is just plain retarded. Even though I hate Apple I think their approach is the lesser evil. The default should be don't cache, web servers should then be able to enable caching if they want to sacrifice some security for performance (assuming the user hasn't explicitly disabled caching). It would be nice to be able to rely on users having well managed machines or the internet being made up of mostly well managed servers but lets face it that aint happening anytime soon in anything but well run enterprises and IT literate end users.
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.
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.
http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.9.2
Seems like it's mentioned there to me...
Watch for Penguins, they eat Apples and throw rocks at Windows.
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.