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."
recognized only by Internet Explorer
So IE is the only browser that cares about your privacy and doesn't store sensitive data in its cache. Got that. I just wish that more browsers would be like IE. But after all, Microsoft has always greatly cared your privacy - unlike Google and their snooping does.
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.
This is BS. If an attacker has access to your files in your local disk, they have already won.
There's a hidden treasure in Python 3.x: __prepare__()
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__()
There are plenty more financial sites than 21 that do that. They must not have looked very hard or at a lot of sites.
I was promised a flying car. Where is my flying car?
This is my first rule. The solution.. whole drive encryption. The tinfoil hat of secondary storage.
Silence is a state of mime.
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.
The data is on your own machine. If your disk is encrypted, the data is safe at rest. When the machine is running, don't allow random people access to your machine.
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?
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 have no idea what header I need to send to prevent IE from caching an XMLHTTPRequest. I don't think its possible.
If you really want to go after financial sites for security there is no shortage of low hanging fruit such as absence of the secure header when sending cookies to the browser.
I find it hilarious that you have a higher score than them.
Everytime you give programmers tools you should expect they will be twisted in every possible way.
So Bad designs, lazy or even awful programmers work on every companies even the sensitive once. My guess is that you could find such mistakes on almost every website or app where security wasn't on the roadmap.
I worked for banks and even if they do the same job security is no always priority.
- Bank One as their "basic" security scan open every TCP request on your server to watch if there is no sensitive informations that could be intercepted. If you do an SQL query on sensitive information they have automatic alerts and people come to the room you are in less than 5 minutes.
- Bank Two have almost nothing and some sensitive database still have the default account and password usable. Or some sensitive database are duplicated on non secure datamart.
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.
Temp files aren't supposed to be publicly visible anyway. If you want private browsing, browsers have a special mode for that. Otherwise the browser caches what it can, which is a good thing. SSL is about preventing online eavesdropping, it has nothing to do with whether the browser stores data on your hard drive. Protecting the data on your hard drive is up to you.
How many of these mega-corporation web sites were outsourced to the lowest bidder? You get what you pay for.
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.
.
Prisencolinensinainciusol. Ol Rait!
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.
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?
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.
You don't need your own Internet access. You can buy a $200 Nexus 7 tablet and carry it into the public library.
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.
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.
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?
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?
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.
... 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.
I am becoming gerund, destroyer of verbs.
If today's phones had to put up with the web of eight years ago, that'd be one thing. But eight years ago, you didn't expect your desktop to render the CSS3, AJAX, and social widget filled monstrosities that are 2013 web sites. Eight years ago, webmasters expected some of their PC viewers to be on dial-up and their few (if any) phone users to be on something like WAP. This meant the average download size of all items on a web page was far smaller than it is today.
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.
Beta is broken and the link to classic doesn't work. Stop wasting our time or there won't be anybody left here.