Follow Slashdot blog updates by subscribing to our blog RSS feed


Forgot your password?
Security Bug Encryption Privacy

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."
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 @03: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.
    • Re: (Score:1, Informative)

      Apple refusing to allow addons in their Webkit

      Apple's browser's name is Safari. WebKit is the rendering engine.

      • by AK Marc ( 707885 )
        "Their webkit" could be translated as "Safari, Apple's Webkit-based browser." So I don't see your correction as changing the meaning. Maybe because so many here know the correction you made, that only those reading with the "goal" of proving someone wrong would deliberately read it so obtusely.
        • by Anonymous Coward

          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.

    • by Pope ( 17780 )

      Apple not allowing the what now? []

      • Perhaps, but they don't allow extensions in iOS, and while I own a Macbook, the majority of users for Apple use Safari on a small 4 inch screen. I apologize, I wasn't thinking of the version in OSX.
    • by antdude ( 79039 )

      But no caches suck for people with slow Internet like dial-up users. :(

  • by Anonymous Coward on Thursday June 20, 2013 @03:04AM (#44058061)

    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)

      by Anonymous Coward

      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.

      • by icebike ( 68054 ) on Thursday June 20, 2013 @03: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 blueg3 ( 192743 )

          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.

        • It's not arbitrary if a browser has an option to not cache any data received over SSL. Using SSL implies some or all of the information is sensitive-- it's just a tool to help the browser and the end user decide when to not use cache without reducing performance the rest of the time. I would like that feature, since we can't trust the site to protect this information.
  • by c0lo ( 1497653 ) on Thursday June 20, 2013 @03:07AM (#44058071)

    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.

    • 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.

      • 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 [] 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?

        • 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).

          • 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?

        • Unlike Windows security updates, Ubuntu security updates don't wait until the operating system is on its period to correct known defects.

          From the article to which you linked.

          Sometimes there is an extraordinary Patch Tuesday, 14 days after the regular Patch Tuesday.

  • by david.emery ( 127135 ) on Thursday June 20, 2013 @03:14AM (#44058091)

    From the 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 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?
      • by bloodhawk ( 813939 ) on Thursday June 20, 2013 @05:26AM (#44058543)
        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.
        • 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)

      • by anegg ( 1390659 ) on Thursday June 20, 2013 @07:51AM (#44059149)

        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.

  • Scaremongering (Score:2, Insightful)

    This is BS. If an attacker has access to your files in your local disk, they have already won.
    • by Anonymous Coward

      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".

      • 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

        • by Anonymous Coward

          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.

      • If you're not using your computer, you should expect keyloggers and never sign into anything which doesn't have 2-factor authentication.

        • It depends on what that two-factor authentication is. If it's just another password, then the keylogger can (and will) steal those and you are no better off security-wise than before. What's needed is something serious like one-time passwords. An added advantage with them is that even if they are sniffed, they are no good for an attacker to try to reuse.
    • by Anonymous Coward

      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)

      by Mashiki ( 184564 )

      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.

    • 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.

      • 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.

    • by blueg3 ( 192743 )

      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.

    • Damn! Common sense! Get him!!!

  • There are plenty more financial sites than 21 that do that. They must not have looked very hard or at a lot of sites.
  • by wbr1 ( 2538558 )

    This is my first rule. The solution.. whole drive encryption. The tinfoil hat of secondary storage.

    • by blueg3 ( 192743 )

      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.

  • by Bearhouse ( 1034238 ) on Thursday June 20, 2013 @04: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 anegg ( 1390659 )
      Part of the problem is that the browser, which should be a tool of the user, has become a surrogate tool of the servers which the user accesses. The more that browsers are called upon to do to offload processing from the server (Java, Javascript, etc.) the less the browser is under the control of the user. For example, reading any major news site, the "other things you may be interested in" links all appear in Explorer and Safari to be simple links, but they actually have complex Javascript that routes yo
    • by tepples ( 727027 )

      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.

  • by Anonymous Coward

    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

  • 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.

    • by Lennie ( 16154 )

      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: []

    • by blueg3 ( 192743 )

      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.

  • Not because it's better, heaven's no. It's because most financial and government institutions use it as the web standard they develop toward, since it's the standard browser in the office. Note I'm talking about institutions not generally internet-oriented, like the bank or the water company.

  • by gstoddart ( 321705 ) on Thursday June 20, 2013 @07: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.

  • ... to think that financial institutions are very serious about security. Their losses are covered by the consumer, so getting their hands on the consumer's money takes a much higher priority than protecting it. Of course, they justify it as "convenience" for the consumer, but it really all about the convenience for them.
  • 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.

Someday your prints will come. -- Kodak