Using the back button after logging out shows you pages from the authenticated user's session

Adding a related issue to fix this in paranoia.module.

Another possible way to mitigate this, at least in my testing with Chrome, may be to use the Vary:Cookie header, even for authenticated users. The private data may still be stored somewhere by Chrome, but at least a simple Back button click doesn't reveal it.

Don't we already send vary: cookie? It looks like D7 always does unless you suppress it (e.g. for a CDN).

Drupal 8 seems to have similar logic.

For Drupal 8 you can follow this link "https://www.drupal.org/project/logout_redirect" to solve this issue.

I experimented a bit with the "no-store" cache control header. If that is set as default header for logged-in users then form field entries are lost when you click away by accident and use the back button. I think that would be a UI regression? We deliberately introduced the store option (now a default in browsers I assume) in #109941: Store site view in HTTP headers many years ago so that users do not lose context when they navigate back.

Wonder if this could be solved by having the user land on a page after logout that loads with no-store, then redirects?

Or maybe we could also/instead use JS history API to replace the entries for the current window?
https://developer.mozilla.org/en-US/docs/Web/API/History_API

Not sure either of these are bullet-proof in terms of eliminating authenticated content being stored by the browser.

However, there might be an even better option, a response header to ask the browser to clear cache:
https://www.fastly.com/blog/clearing-cache-browser
https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Clear-Site-Data

Seems to have reasonably broad browser support now.

Adding a Clear-Site-Data: "cache" cache on logout would do the trick. But won't people be upset that now their browser has to download all the assets which are common between the logged in sites and logged out site?

Anyhow I had a quick test of the header and it worked great on Chrome but not in Firefox?!?! :( I tried both with and without quotes and with cache and *. Without quotes worked on chrome - it never worked on firefox. :(

This issue was reported on a site build I'm working on. After lots of searching and trying to find the right search terms, I found this issue! It seems to describe what I'm seeing.

I'll add some reference material to the description of the ticket.

The comment from #14 is insightful. I see #3130912: Incorrect Cache-Control headers for authenticated users is planned to implement the "no-store" flag in the Cache-Control headers, I don't know if that will affect this ticket. I also see https://www.drupal.org/project/logout_redirect.

I'm going to document these various approaches in the description.

I'm going to have a go at describing the proposed resolution so that it's clear what this ticket is trying to achieve. Please revise as anyone sees fit.

Adding a screen recording of the issue.

Sorry for all the updates, but I am going down the rabbit hole and finding important information.

It seems there are two objectives, one functional and one security related.

Functional objective: ensure a user who is browsing along and hits the back button doesn't see an incorrect logged-in state. That is simply confusing.

Security objective: ensure that Drupal sites with sensitive information are not vulnerable to the two attacks described.

It seems like with some research and testing, an approach could be defined to address those objectives. However, it gives me concern as I don't know what indirect impacts are involved with various approaches.

Maybe we could focus on the security issue first? It seems like Drupal should have a default of Cache-Control: no-store for authenticated traffic, which is covered by #3130912. I will need to do some testing, but in the research I've done that seems to be what others are pointing to as the solution. I'm wondering if a ticket should be opened with webforms to have some flag on every webform that declares whether its a sensitive form, and if it is send the no-store header.

I did a test of patch #5 on #3130912 and found it to meet the security objective of not exposing authenticated information through the back button attack. But, it did not meet the functional objective of an authenticated user clicking the "Back" button and seeing an anonymous page. See details here: https://www.drupal.org/project/drupal/issues/3130912#comment-13767062

We’ve had a bit of an uptick in security researchers reporting this issue about Drupal.org.

Looks like Clear-Site-Data header now is supported by pretty much all browsers other than safari

https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Clear-Site-Data

Looks like Clear-Site-Data header now is supported by pretty much all browsers other than safari

I wouldn't say that, Clear-Site-Data is not supported on Firefox and Safari. It was supported on Firefox at some point, but later moved to a feature flag because the implementation turned out to be incomplete/problematic. There doesn't seem to be a lot going on in the issue, so I'm afraid we'll have to wait a little longer before being able to use this feature.

I tested the patch on Google Chrome, the header is successfully added to the logout response but it looks like I'm still able to access cached admin pages by using the back button. Am I doing something wrong?

Attached rerolled patch against 9.4x,,
Kindly review patch,,

A MR was opened, so no need for a rebase. More work is still needed so setting back to Needs work.

OWASP has a page in the WSTG about this topic. Their recommendation:

The Back button can be stopped from showing sensitive data. This can be done by:

• Delivering the page over HTTPS.
• Setting Cache-Control: must-revalidate

This is basically what Drupal is doing already. Except that there are some additional directives on authenticated pages (Cache-Control: must-revalidate, no-cache, private). I wouldn't expect that the extra directives no-cache and private would reverse the effect of must-revalidate. So I looked at other response headers relevant to browser caching.

Turns out that we are missing Vary: Cookie on authenticated responses. The culprit is FinishResponseSubscriber::setResponseNotCacheable(). The comment in this method says:

    // There is no point in sending along headers necessary for cache
    // revalidation, if caching by proxies and browsers is denied in the first
    // place. Therefore remove ETag, Last-Modified and Vary in that case.

There is only one situation where this behavior would be correct: On a selected route which is delivered with Cache-Control: no-store in all cases (independently whether a session is open or not).

In all other situations, the Vary: Cookie header must be on every response. No matter whether a user is logged in or not or a session is open or not.

MR !3505 adds Vary: Cookie to every response. Obviously needs manual browser testing.

MR !3505 doesn't seem to fix the problem. Interestingly this wasn't an issue on the previous build of the site I am mainly working on. I get a 403 (i.e., the expected behavior) with the following testing scenario in Firefox:

1. GET /
2. Log in -> 302 to /
3. Navigate to profile form (/user//edit)
4. Logout -> 302 to /
5. Hit browser back button -> 403

The legacy site was based on Drupal 7 and Authcache. Authcache encourages the browser to cache pages even for authenticated users. However, it also ensures that the ETag is different for each variant of a page.

I think that when Authcache is active, the browser is replacing the cached frontpage in step 2 (after login), and the cache is replaced again in step 4 (after logout). My hunch is that a cache replacement (in contrast to a cache insert) invalidates previous history and as a result the browser attempts to refetch the user page when the back button is hit.

Pure speculation though, more testing is clearly necessary. Also I am a bit disappointed by the OWASP page linked in #39. It doesn't seem to cover the full problem.

see https://www.drupal.org/project/drupal/issues/3130912

Should we consider Option 3:Cache-Control: no-store? On linked issue #3130912: Incorrect Cache-Control headers for authenticated users there's patches to implement it with test coverage. OWASP recommends the approach also on its FAQ page https://owasp.org/www-community/OWASP_Application_Security_FAQ#how-do-i-...

Twitter.com and Google seems to rely on Cache-Control: no-store header on authenticated services.

Fastly article from 2014 states about Vary: Cookie: "Cookie is probably one of the most unique request headers, and is therefore very bad."

I tested @znerol's MR !3505 with DDEV, it works only with HTTPS enabled, like mentioned on OWASP documentation. Tested with Firefox, Chrome, Edge. Unfortunately on Safari the back button showed the cached content.

Wrote on #3130912: Incorrect Cache-Control headers for authenticated users that we should implement the Cache Control header change on that issue. It will partially fix this issue. On Safari there's a bug https://discussions.apple.com/thread/251817133 and I hope we could narrow down this issue just for Safari.