Follow Slashdot stories on Twitter

 



Forgot your password?
typodupeerror
Security Bug Encryption Privacy

21 Financial Sites Found To Store Sensitive Data In Browser Disk Cache 118

Posted by samzenpus
from the out-in-the-open dept.
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."
This discussion has been archived. No new comments can be posted.

21 Financial Sites Found To Store Sensitive Data In Browser Disk Cache

Comments Filter:
  • And that my friends (Score:3, Interesting)

    by mitcheli (894743) on Thursday June 20, 2013 @02:00AM (#44058045)
    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.
  • by YA_Python_dev (885173) on Thursday June 20, 2013 @02:41AM (#44058169) Journal
    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?
  • Re:Scaremongering (Score:2, Interesting)

    by Mashiki (184564) <mashiki@NOspAM.gmail.com> on Thursday June 20, 2013 @02:43AM (#44058177) Homepage

    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.

  • by icebike (68054) on Thursday June 20, 2013 @02:49AM (#44058207)

    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.

  • by Bearhouse (1034238) on Thursday June 20, 2013 @03:23AM (#44058329)

    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?

  • by gstoddart (321705) on Thursday June 20, 2013 @06:57AM (#44059189) Homepage

    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.

  • by DaveV1.0 (203135) on Thursday June 20, 2013 @07:01AM (#44059209) Journal
    Maybe you should try reading the second link from the summary [securityevaluators.com] and take a look at the standard heads [w3.org]. 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.

"It's what you learn after you know it all that counts." -- John Wooden

Working...