Q and A on cross site request forgeries and breaking into sessions. It's one of the attacks that XSS enables and the attack of the future. For Session, fixations, hijacking, lockout, replay, session riding etc....

I'm looking for ways to force browsers not to cache data. I've included the following header in both HTTP and HTTPS server responses:

Cache-Control: no-store, no-cache, must-revalidate, proxy-revalidate

but after I browse away and log off from the app (but do not close the browser), I can still press the back button on the browser (tested on Opera 9.10 and iceweasel 2.0) or set the browser in offline mode and view the sensitive data. I was under the impression that browsers aren't supposed to cache HTTPS data at all. Why is this data being cached? Is there a header I can set that will stop this?

I would assume that, given that test, is just the browsers loading what it has as temporary data

If you really want to test that server's response isn't being cached, you could just use some local proxy (paros, webscarab, whatever...) or any tool to see http headers (livehttpheaders on firefox) and look for the response code, if the no-cache isn't working as you expected, you should see a 304 response code (not modified). The response code in every visit (if nothing is being cached) should be 200

To add a little more (someone correct if I'm wrong in this) using the back button of the browser doesn't create a new request to the server, just load a previous state, that is why I mentioned that it should be the temporary data being loaded in your test.

I'm not an expert on the subject so my response could be unaccurate at some point.

The back button uses the browser's in-memory cache, so that users can go back to a page, if they click on a link or similar they will ask for a new copy of the page.

Realistically you're probably not going to be able to change this behaviour without something creative (I tried dynamically appending meta redirects instead of having ordinary links, but that didn't work), since the browser wants to keep the page in it's in-memory cache.

Most likely; no. The in-memory cache holds pages as they were when the user left them. And there's no reason to ask me, test it out and have a look.

If you really do want to go through with this, I see two methods:
- Make all your links actually form buttons that submit post requests; post responses are never cached (even in memory)
- Rewrite all your links so that before actually going to the link, they use some javascript to scrub the current page and remove any content from it

They both break the user's ability to open links in new windows (unless you use the second idea and have normal links, and have the javascript in the onclick handler and come up with some method to detect when a new window/tab is being opened, and then *not* scrub the page) The first one is surer, and doesn't require javascript, but maybe if you get clever enough, you can get the second idea working for you.