Presenting Jacob Thompson, Independent Security Evaluators.
(Applause) JACOB THOMPSON: I'm Jacob Thompson, and
this is C.R.E.A.M., Cache Rules Evidently Ambiguous, Misunderstood.
Websites use HTTPS for things such as banking and payroll due to the sensitive nature of
the personal information contained therein. The reason they use HTTPS, the data is too
sensitive to transfer over an open network without encryption.
If it is too sensitive to be sent over the network without protection, maybe it shouldn't
be written to disk without encryption either, especially without the user's knowledge.
In the past, many web browser were cautious about persistently caching the information,
whether or not the header said to cache it. I am not concerned about memory caching, but
only persistent caching to disk, as in you close the browser and it is still there.
I was offline and bored at one point, so I opened my copy of Firefox. And having nothing
to read, I went to the disk cache. I was very surprised to see things there from my bank,
like check images and account summaries and recent transactions.
My impression was that browsers did not cache this information. After that, we at Independent
Security Evaluators looked at 30 sites, along with other analysts. We found 21 of them were
causing information to be persistently cached in the latest browsers, either sending no‑caching‑related
headers, or headers that were nonstandard or obsolete which only worked with certain
browsers. The first thing I will do is show you a couple
pages where we found information cached to disk, and what it was. Then I will look at
the history of why this has been so consistent, and how somebody can be confused of whether
this happens at all, and how to prevent it. (Cheers and applause)
Sorry, but this is a first‑time DEF CON speaker. He sincerely asked us: Please do
not interrupt my talk, so we're not going to interrupt his talk. We will just sit up
here quietly and have a drink. Here's to DEF CON!
(Applause) Thank you all for coming.
JACOB THOMPSON: Okay, guys. So the first thing I will show you, some of the information
we found in the disk cache. Then I will go over some of the history of
what browsers used to do, what they do now, what the standard says and what the impressions
are of people when you go on the Internet to places like StackFlow and look for this,
and then some recommendations about how we think it can be more secure.
ADP is a popular payroll processing company. Anybody have their checks done with this company?
Lots of you. We had somebody at ISE with previous ADP history.
He logged into the web interface and looked at a payroll statement. It was cached with
nice information like the last four digits of the Social Security number and bank account
number which might be used for authentication purposes on other sites, so you can see how
things can possibly go wrong. ADP was sending some caching headers, but
they were obsolete and only interpreted by IE. If you went to Firefox or Chrome, it was
left behind. Another site, Argus, processes claims for
health insurance companies. In Maryland, our Blue Cross Blue Shield company uses Argus
to handle these claims. So we went there to see the pharmacy claims,
and without any caching headers at all, there was the name of the patient and the medications
they were on, as well as the dosages ‑‑ maybe not the best thing to have sitting on
your hard‑drive. Also, it was sent with no caching headers, so even IE might cache
this. The final one was more surprising, Equifax,
which does credit reports. After an ISE analyst accessed his credit report there, it was cached,
including information such as the obvious credit score and name. But also by definition,
a credit report has a list of all your accounts. If you recently have applied for credit, a
common question might be: It looks like you have a mortgage from three years ago, what
is the payment, stuff like that, which you can get from the credit report.
Here is a list of the 21 sites we found with some forms of caching issues. Some of them
were big‑name banks. Others were not so big, but a pretty broad spectrum of sites.
Here are some data‑types we found. Some not so severe, others were more concerning
with information like birthdate and the last four digits of you SSN, and credit card numbers
without expiration dates. Then there were some things for auto insurance, et cetera.
Before I go into the nonstandard headers the sites may have been using, if at all, how
do you prevent disk caching in today's popular browsers with these two headers? Don't use
them as metatags. There is a historical precedent, but it is
not reliable. Pragma no‑cache goes back to the mid‑'90s when SSL was introduced,
and you need to pass the header due to a special case with IE 8 when the server speaks HTTP
1.1, as opposed to 1.0. For all other cases, including IE9, cache
control knows what is in the standard specifically for this purpose, talking about preventing
information from being revealed on backup tapes, which is the same concept.
So what are some headers we saw that don't work and fail? Cache control no cache. That
is in the standard, but it is about preventing a user from seeing stale information, telling
the browser that you have to revalidate before serving another request; it has nothing to
do with security. Despite that, when Microsoft first implemented
support, they decided to interpret it with the same meaning. They stayed with that all
the way through IE 9. In IE 10, they started to follow the standard, and this is still
changing up to today. Pragma no‑cache predates HTTP 1.1. And what
it means, if it is over has the meaning of if it is over SSL, do not write it to disk
cache, and it still works in IE. We saw "cache control private" on a handful
of sites, not intended at all for web browsers. It is about caching proxy servers by multiple
users, saying this information is specific to one user, you shouldn't use it to service
another request by a different user. Cache control in meta equiv tags doesn't work.
The pragma does, but there is buggy behavior, and there are more details about that in the
white paper. So it doesn't work, at least for the purpose of preventing disk caching.
Finally, passing the cache control no‑store header when the server uses 1.0 is ignored
by IE 8 and earlier versions, which seems weird. Why would a server speak to a header
it doesn't understand because it is too old? Until recently, Apache mod SSL support would
automatically downgrade a connection from Version 1.1 to 1.0, if IE was the requesting
browser. This was a bug workaround, and it was still
there until two years ago when it was patched in the main Apache branch. The change still
has not percolated to the various Lennox distributions, including the latest Santo SOS.
That behavior is a little weird, something you would never realize until you followed
it through and had a site send the header, and then look in your cache. In the past like
with early Netscape, it didn't cache anything over HTTPS. And even today, Safari still works
like that. When a server is sending something over SSL, it is never cached, and the server
has no way to mark "nonsensitive" to mark an exception.
Firefox experimented in Version 3 to allow certain things marked "not sensitive," what
I call an opt‑in policy of using a public header, go ahead, it's just a CSS file or
something, it is okay. Then there are other browsers, especially
like older ones that only allow the pragma no‑cache header as a way to mark individual
resources not to be written to the disk cache, which I call "nonstandard opt out" because
nonstandard behavior works, and standard headers don't.
Then IE, as it came into newer versions, started to support cache control no‑store, but pragma
no‑cache is still there. So I call it a "generous" opt out, be generous as what you
accept. It's often applied to other parts of rendering.
I have the three IE versions listed separately because there is individual variance, but
the main idea is still there, old behavior, new behavior, both work.
New browsers like Chrome and Firefox 4, either the server sends cache control no‑cache
store, or it gets cached, period, the end. Because of the this discrepancy, there is
a lot of confusion out there in the community about what they really do.
If you go on your search engine and search for "browsers do not cache SSL or HTTPS,"
you will find old and new results saying web browsers don't cache to disk if they came
over SSL. Some say "from stack overflow and blog posts"
and even a W3C mailing list which may have been true when written, and some say SSL is
not cached, except IE browsers. But that's not true today, especially with Chrome and
Firefox. This quote comes from the OWASP application
security fact, who should they better. This may have been true with Firefox 2 and earlier,
if those were the browsers you were looking at, but as far as SSL, that part of the standard
is just not there; there is no specific behavior that all browsers follow.
So let's look at the browser developers like Mozilla who decided to change caching to increase
performance. On the "bug" end of things, in deciding to switch the policy from opt‑in
to strict standards compliant opt‑out, one comment on the bug said: Among sites not using
cache control no‑store, the correlation between SSL and sensitive is very low.
But it doesn't work that way for those 21 sites, so where do we go from here? Should
browsers assume websites will mark things "sensitive"? The web sites either use headers
they think are marked sensitive, or they don't realize they need to do it in the first place.
What do we think should be done? First of all, the obvious thing is to fix web applications.
After all, the HTTP standard does say this is the header to use if you want to prevent
disk caching. "Clogs‑browser compatibility" is about more than the tags and HTTP request,
as well as deeper meanings of the standard that can have security consequences.
I have "fixed browsers" as a "maybe," because it can be reasonably said by a browser vendor
that the standard says you send this if you want to prevent caching; however, at the minimum,
browsers should interpret the pragma no‑cache header.
Despite being standard, it had the meaning in IE and earlier versions of Netscape when
they had the opt‑out policy. They could switch from opt out to opt in; browser not
required to cache anything. They can go back to the Firefox 3 policy where nothing is cached
unless the server says "cache control public." More important, the bad documentation out
there saying browsers don't cache this or use pragma no‑cache, that should be fixed.
We obviously can't fix mailing list archives, but at least wikis and other things should
be updated, and anyone doing security assessments of Windows applications, they should be aware
of this issue. Finally ‑‑ and this is probably the most
controversial and least likely to happen. Maybe the HTTP standard should take this into
account that if you look at RFC 2616 and you search for SSL, there is a grand total of
one occurrence. And if you search for HTTPS, there are no
occurrences. So while that may make for a nice layered architecture with the protocol
on top, encryption underneath, you shouldn't be ignoring security consequences or assumptions
people are making, especially when there is a historical behavior among different web
browsers. Finally, I have actually put an HTTPS site
out there that tries different combinations of caching headers so that you can look and
see what really happens in the browser you try.
Before I bring up the site for an experiment, are there any questions? If not, I will go
to the demo site. Safari was on the list as no browser. Chrome was strict compliance,
and the same for Android. On Android, it is possible these things can be getting cached
just like on desktop, and it's harder to change browsers on mobile.
(Question or comment from audience member) JACOB THOMPSON: Something about pdf? I
can't hear the question. The fact it is a pdf file, how does it affect the caching?
Okay. It is possible that due to the fact when it is a pdf, if using Adobe plug‑in,
depending on the implementation, it might be caching to a temporary file.
We tried it in Firefox, and sending cache control no‑store does work, especially with
the new built‑in reader. This person is asking if you are using a web browser, can
you reconfigure to go back to the old policy or not.
In Explorer there is option for: Do not save encrypted pages for disk. In IE 10 and 11,
it is supposed to work, but there were problems with downloads in earlier versions.
In Firefox there is a hidden browser preference you can set the opposite way to go back to
the no‑cache SSL policy. We tried writing an extension for Chrome, but we didn't get
anywhere with the APIs. There's nothing to do with Safari, because it doesn't cache in
the first place. Would it make sense to encrypt (?)
JACOB THOMPSON: Where do you store the key? You want to exit the browser, go back
in. If you can recover the key, potentially, but so can any other application.
(Question or comment from audience member) JACOB THOMPSON: Or just use a memory cache,
but that is valid for a mobile phone without as much memory.
Ready for the demo site? I am in Firefox. The first thing I will do, it will clear the
cache so that this is valid. All right, zero bytes. Next I will visit our test page.
You can also do this, if you would want to. It did work earlier. I even have an ETC host
entry. So this is a main page with a little description of the issue, how to check for
it. Then I have some i‑frames links pages to
send various combinations of the headers. I have a small explanation of what they are
supposed to do. After you visit this page, I will close the
browser so that we are guaranteed it is in the disk cache, and then go back in. We will
go to the magic URL. It shows all the disk cache entries. I named
those files on the demo site so that it tells you what headers it is sending. So no headers;
dot‑HTML is not sending cache‑relate headers, no cash control or pragma.
Then cache control no‑cache, I am proving this does not work. So it might be influencing
the decision of whether or not to validate before reuse, but it has nothing to do with
disk caching. Cache control no‑store is a meta-tag, not
there in the headers. It is in here if you look, and that doesn't work either. And it
probably shouldn't work, because for meta-tags to affect caching, you have some weird condition
where you can cache and then parse, or parse and then cache; it would be buggy behavior.
IE does support the meta-tag for pragma headers, and there is documentation of bugs saying
if it is over a certain size, put the tag at the bottom of the page, something like
that, just crazy. Pragma no‑cache is not working here in Firefox.
It would have worked in IE. One more, cash control public and private, and private doesn't
work. So you can check the behavior and prove it
to yourself. Any further questions? (Comment or question from audience member)
JACOB THOMPSON: We haven't tested that. The best thing would be the justification
in Firefox about why they changed it between Version 3 and 4. Maybe somebody has done statistical
testing. Nowadays we have bigger (?)
JACOB THOMPSON: That is why they changed it in the first place. As long as the site
does the proper behavior, we would be okay, but that is not happening right now.
This is Firefox 22. It hasn't changed. Anything further? All right. Thank you very much.
(Applause)