MozillaZine

How to prevent Firefox 3 from caching

Discuss how to use and promote Web standards with the Mozilla Gecko engine.
jscher2000

User avatar
 
Posts: 11095
Joined: December 19th, 2004, 12:26 am
Location: Silicon Valley, CA USA

Post Posted July 2nd, 2008, 5:42 pm

RobertJ wrote:It seems based on what is in RFC 2616 that, page information can be stored in volatile storage (i.e., memory) and history buffers. It goes on to say that using the response headers is not reliable or sufficient to ensure privacy; which, is in essence what my friend at the cellular company said.

But servers have no way to reach in and flush the cache themselves, so if the headers are not honored, what's next? You could use client-side script to (1) go forward if there is forward history (this probably can be defeated); and/or (2) destroy the <body> contents and reload the page if a certain timeout has passed. Would that make sense?

As a practical matter, if User A does not want User B to access any part of their Firefox session, they should close the browser in a manner that will not allow session resumption. I realize that in the poster's scenario, users cannot be trusted to do this, so perhaps the institution needs an idle-shut-down extension that will forcibly close Firefox for them? Wouldn't that be annoying. ;-)

Jeff.Hibbard
 
Posts: 13
Joined: June 17th, 2008, 9:47 pm

Post Posted July 2nd, 2008, 11:39 pm

RobertJ wrote:I have, in addition to my own sites, examined the response headers from about 25 sites using https. In all cases Firefox 3 does not cache in non-volatile storage (i.e., disk).
I do not dispute this. In fact, I posted the following back on June 25th:
Jeff.Hibbard wrote:According to information displayed by "about:cache", if I did not send no-store, the page was cached on disk. If I did send no-store, the page was cached in memory.


RobertJ wrote:It seems based on what is in RFC 2616 that, page information can be stored in volatile storage (i.e., memory) and history buffers.
Even the portion of RFC 2616 that you quoted clearly says that a cache "MUST make a best-effort attempt to remove the information from volatile storage as promptly as possible after forwarding it." Unfortunately for my side, paragraph 13.13 of the same RFC says "History mechanisms and caches are different" and goes on to make it perfectly clear that history mechanisms can store whatever they want despite any restrictions on what can be cached. So if you want to declare that the area which about:cache labels a "Memory cache device" is really a "history mechanism" and not a "cache in volatile storage", then you win. Otherwise, I think not. Perhaps this "bug" can be addressed by merely changing the incorrect label displayed by about:cache. :wink:

You must bank at different places than I do. I tried National City, American Express and Capital One. All 3 of them let me see sensitive information after I had logged off by merely hitting the back button in FF3. This did not happen with other browsers. I then tried Bank of America. They did keep me from getting anywhere after logout with the back button in FF3, but I was still able to see financial information after I logged off by using about:cache.

I just discovered earlier tonight that FF3 does properly (by my interpretation) honor Cache-Control if I use GET for my forms instead of POST, so my immediate problem is solved. It does still keep the "no-store" data in the memory cache, but at least it sends another GET to the server when someone hits back, instead of just displaying what it has cached. I can live with that.

If, in fact, response headers are "not reliable or sufficient to ensure privacy", I would welcome suggestions from other people in this group about methods that are more reliable. I do already use Refresh to timeout the page and destroy the cookie, but that doesn't keep somebody using back to get to an earlier page in the session, if the browser is willing to display the earlier page from its cache history buffer without sending the cookie to the server to be told it's now invalid. I tried Googling the topic, and essentially every article I turned up suggested either using response headers to prevent caching or using JavaScript to destroy the history. Personally, I consider the later to be anti-social behavior. I really hate it when some web site I briefly visit destroys all the history of everything else I've done in that session.

nesheroj
 
Posts: 8
Joined: June 26th, 2008, 2:00 am

Post Posted July 3rd, 2008, 12:49 am

RobertJ wrote:
nesheroj wrote:I've just found a bug report about this here: https://bugzilla.mozilla.org/show_bug.cgi?id=441751


BTW: We've detected this bug affecting +10 sites with sensitive information including (but not limited to) online banking/broking sites.


This bug is UNCONFIRMED.
Well, each of my teammates could confirm you this bug exist, also the QA dept of the customer and the customers of the customer which reported the issue :)


RobertJ wrote:After logging out most go to a page that says:

"For your security protection it is advisable to close your browser window"
We do this also, the same way we take any possible measures to ensure the privacy of the final user.

RobertJ wrote:I think the comments of my friend of mine who runs a secure web site for a cellular phone company that handles on line billing and payments are correct. His "opinion" is that there is an application design problem if you can "click back".
We, on our side, can do nothing but instruct the user agent how it should behave. there's no desing flaw if firefox 3 doesn't try to refresh the data, we DO show a 'session expired' notice if it does (and firefox2, safari, IE6/7 and many others do obey our cache control directives)

RobertJ wrote:I asked my web site friend about this and he told me that they would never rely on cache control headers for security. I asked him why. He said that there can be numerous caches between the server and the UA, any of which can ignore cache control headers. He said that a properly designed application will insure that you can't "click back" either when you log out or you time out.
The same again. We can't (and we don't want anyway) control the final user's browser. Like we can't control if the user keeps it's login info in a plain text file on his desktop. We can only do our best to preserve their privacy and firefox tries to do the same up to my knowledge. Only that this time there's a detected flaw which if not fixed, we must prevent any access from firefox3 in order to protect our end-users.

.

trolly
Moderator

User avatar
 
Posts: 39909
Joined: August 22nd, 2005, 7:25 am

Post Posted July 3rd, 2008, 1:15 am

You can file a bug at https://bugzilla.mozilla.org/ . Something like "Firefox ignores cache-control for POST data".
Think for yourself. Otherwise you have to believe what other people tell you.
A society based on individualism is an oxymoron. || Freedom is at first the freedom to starve.
Constitution says: One man, one vote. Supreme court says: One dollar, one vote.

nesheroj
 
Posts: 8
Joined: June 26th, 2008, 2:00 am

Post Posted July 3rd, 2008, 4:38 am

Confirmed, its related to forms using POST method, I've yet to implement session data but you can test in http://www.pikanya.net/testcache/ it sends cache-control directives but you can use the back button without reloading the page from the server. Firefox 2 will show a dialog warning you that going back will redo any action to prevent accidental double posting or affecting data. Firefox 3 just silently uses the cached page ignoring any cache control directive used.

trolly
Moderator

User avatar
 
Posts: 39909
Joined: August 22nd, 2005, 7:25 am

Post Posted July 3rd, 2008, 5:39 am

Just to repeat myself: To get it fixed someone has to file a bug. I will not do it because i can not supply a test case or any other relevant data.
@nesheroj: You have already a test case. Can you file it?
Think for yourself. Otherwise you have to believe what other people tell you.
A society based on individualism is an oxymoron. || Freedom is at first the freedom to starve.
Constitution says: One man, one vote. Supreme court says: One dollar, one vote.

RobertJ
Moderator

User avatar
 
Posts: 10872
Joined: October 15th, 2003, 7:40 pm
Location: Chicago IL/Oconomowoc WI

Post Posted July 3rd, 2008, 6:08 am

One additional comment. for nesheroj and Jeff.Hibbard. You might look around and see if there are forums focused on security of user information when using a browser. I talked to my friend and he said the group they rely on is for telecommunication companies only and there is an annual fee to cover maintaining a testing facility with hardware and software. I don't know how they do it and he is the CIO and too far removed from the details to help me. As jscher2000 noted that I can think of a few ways that rely on Javascript (client side), regular cookies and/or persistent tokens embedded via Flash. In the end the user has to take some responsibility. When the log-out page says "Close your browser to ensure you privacy" he/she should pay attention. Sort of like not leaving you credit card on a desk in a hotel room while you go out for breakfast.
FF 83.0 - FF 84b4 - FF 85a - TB 78.5 - Mac OSX 10.13.6

jscher2000

User avatar
 
Posts: 11095
Joined: December 19th, 2004, 12:26 am
Location: Silicon Valley, CA USA

Post Posted July 3rd, 2008, 5:59 pm

I only looked at GET before and I agree that POST behaves in a manner that users say they prefer (lots of threads over time complaining about the warning) but is bad for privacy. Perhaps the new behavior should apply only to HTTP sessions, and the old behavior should apply to HTTPS and other sessions, on the theory that people have a lower expectation of privacy in HTTP sessions.

nesheroj
 
Posts: 8
Joined: June 26th, 2008, 2:00 am

Post Posted July 4th, 2008, 12:56 am

Agree. The new behavior is nice but should only apply when cache is meant to be used, not when explicitly told otherwise :)

It's funny that after firefox being told that this information is:
* Private
* should not be cached
* should be revalidated
* should never be stored
* when accessed is already expired

Still keeps it for future use.

ThG
 
Posts: 1
Joined: August 18th, 2008, 2:55 pm

Post Posted August 19th, 2008, 3:02 am

hi, I have the same problem. Since the last post was made one month ago I wanted to ask if you have found some solutions for that problem. Maybe I found a possible way: It seems that FF3 revalidates a page when the page contains data in a password field. so using a password field for the critical aktions, e.g. logout, could help. Can you confirm this or do you have better server-side solutions?

timjowers
 
Posts: 4
Joined: September 8th, 2008, 10:18 am

Post Posted September 9th, 2008, 7:33 am

Best idea is to use form posts. This will instruct the browser to repost. Then your webserver will reply "the user is logged out" etc. On non-post pages, it does cache even in https in my singular test yesterday. We had all three headers and the pragma. Per Tools->Page Info
Expires: -1
Cache-Control: no-cache, no-store, no-transform
Content-type: text/html; charset=utf-8
PRAGMA: NO-CACHE

Finally, of course it is not a security breach as the software can always save what it can display. If the system must not allow saving then the issue becomes very complex. I've seen several times gub and companies request no printing and no saving but the reality of doing this is you can only make it hard. Once the information leaves the barn, anyone can copy it if they really want to do so. E.g. at Savannah River [nuclear weapons and nuclear recycling] Site the really secure systems were in a shielded room behind lock and key and several layers of guards. If you need to see what is on one of those computers, then you go to it!

jscher2000

User avatar
 
Posts: 11095
Joined: December 19th, 2004, 12:26 am
Location: Silicon Valley, CA USA

Post Posted September 9th, 2008, 8:24 pm

timjowers wrote:Best idea is to use form posts.
...
Finally, of course it is not a security breach as the software can always save what it can display. ...

Tim, this is a very long thread and so you may have missed the specifics in the poster's scenario:

  • The poster's application sent proper headers to prevent caching;
  • The POST method was used;
  • The poster's application ended the session on the server; yet
  • Firefox 3 allowed the user to go Back through the supposedly expired-out pages.

In the poster's scenario of a shared PC used to access sensitive data, this is a risk to privacy if the user fails to close the browser.

You can see how it works for you on these demo pages: http://dev.jeffersonscher.com/cache/index.asp

realvegan
 
Posts: 1
Joined: November 21st, 2008, 11:38 am

Post Posted November 21st, 2008, 11:51 am

For any of you struggling to get something working when having users navigate back to a form and wanting the data to be refreshed from session variables instead of Firefox 3's "back" which doesn't reload the page even if the headers say not to cache/etc.., (like I have been), try creating your own back button and add something like to the button code:

/whateveryourpageis.php?process=back

And then add some checking in your code for that variable, and change your form to populate the data only with the session variables instead of the normal post/get methods (ie: inside each text element, echo the session variable instead if process=back).

This is the only way I could get it to work in Firefox 3.0.4, yet it worked fine without this hack in IE 7.0.5730.13

The form I have is one that will set session variables after it is submitted, but in Firefox, when the user clicks Back, it doesn't reload the page with the session variables, it keeps the page fresh and therefore doesnt' call the session variables as it should be doing since the page headers explicitly in every way tell the browser not to cache the content and that the age is expired.

But if the back button itself is pressed, so far nothing at all that I've tried can make it work in Firefox 3.0.4 - including all the possible header cache options and both POST or GET methods.

I hope this gets fixed in the next Firefox release! [-o<

anna.volyu
 
Posts: 1
Joined: January 21st, 2009, 12:36 am

Post Posted January 21st, 2009, 12:40 am

Hello guys,
I have just found solutions on that tech blog: [http://blogs.helion-prime.com/]

have a nice day

niimae

User avatar
 
Posts: 2
Joined: May 27th, 2009, 9:03 pm
Location: Presque-Isle, ME

Post Posted May 27th, 2009, 9:19 pm

Hi, I recently encountered the Firefox 3 no-cache issue and have come up with something that works. Put the following meta tag between the <head> and </head> of your HTML:

<meta http-equiv="cache-control" content="no-cache, no store"/>

...this also is fully compatible with IE.

Return to Web Development / Standards Evangelism


Who is online

Users browsing this forum: No registered users and 2 guests