Problem / Motivation
Screen recording: https://drive.google.com/file/d/1Psq-aeG_j7XH3BTj_jl2eMz8ekb32vqy/view?u.... Browser: Firefox.
Originally reported as a security issue by David Rothstein, but making it into a public issue as the security team considers this non-critical and thus can be fixed in the public queue.
=====
Testing with Firefox, if you log out of a Drupal site and then hit the back button, you can see pages from the authenticated user's previous session.
This could be a problem on public computers, if the authenticated user had permission to see content protected by node access (or similar).
Variations of this have been reported in the public issue queue in many places. For example:
- #1859900: It is possible to view the contents of the authenticated pages by fetching the page from the browser cache memory, history.
- #1197544: History Back Button display webpage as it was seen by logged in User
- #197786: Some servers / browsers will cache pages even when header Cache-control: no-cache is set
We might say it's OK to discuss in public (and it certainly would be hard to find and unpublish all the existing issues now anyway) but I thought it might be useful to discuss here first.
As far as I can tell, the simplest way to fix this is to add the "no-store" header to all pages viewed by an authenticated user; however, Drupal used to do this but it was removed a long time ago (see http://drupal.org/node/109941) because it was causing all sorts of annoyances when an authenticated user tried to use the back button while still logged in. So, it's possible there isn't really a great solution here.
Security Note
Back and refresh attack
Screen recording: https://drive.google.com/file/d/1Psq-aeG_j7XH3BTj_jl2eMz8ekb32vqy/view?u.... Browser: Firefox.
There is a potential security concern here: imagine a user on a public computer. They log in to Drupal, go to pages that only an authenticated user should see, then logout. Unless the browser session was closed (the in-browser caches cleared), then someone else could come to that computer and click the back button to see those pages.
While the risk applies to anything you can see on the screen, it can also apply to anything in markup, notably a password field. See https://resources.infosecinstitute.com/browser-based-vulnerabilities-in-... for a generic description of this approach. The example would be someone attempts to login, it fails, and their password is still in the markup. In my testing, I did not see this issue with Drupal 8 because on a failed password attempt the password is cleared out (i.e. its not sent back to the browser). But, the principle of this approach could apply to other fields. If webforms module is used to submit important information, this issue could apply.
On Firefox, you can close the tab or close the browser (quit the browser application), then open the application again and be able to go back in history. In this scenario, the browser's setting is to "Open up previous tabs".
The user can visit multiple previous pages, not just the most recent.
Browser disk cache
Separately, but related, there is a concern about the browser storing these caches on disk. If those caches are not cleaned up, then anyone with access to that disk can access those cached pages.
Examples of this Attack
- April 2, 2020: Twitter Direct Message Caching and Firefox (see also Twitter's post)
- July 12, 2017: A report from ISE showed 21 of 30 sites tested were vulnerable to this type of attach (Note: the sites were not exclusively Drupal)
Steps to reproduce
1. Login to Drupal
2. Go to a page
3. Logout
4. Note you are redirected to the home page
5. Click the browser's "Back" button
6. Note you are now at the page from Step 2 and you see the Drupal admin toolbar (which should only show if you're authenticated)
This issue can be observed in Chrome and Firefox. With Chrome, if you disable cache using browser tools the issue is not observed. With Firefox, if you disable cache using browser tools the issue is still observed.
The issue persists even if you close the tab or quit the browser (tested in Firefox).
The user can click "Back" multiple times to see even older cached pages.
Proposed Resolution
Allow the user to use the back button, but change its behavior based on authenticated status. There are two basic scenarios:
Scenario 1: Logged out to logged in
1. Go to a page
2. Login to Drupal
3. Click the browser's "Back" button
4. Go to the page from Step 1, but you now see the "logged in" version of the page
Scenario 2: Logged in to logged out
1. Login to Drupal
2. Go to a page
3. Logout
4. Click the browser's "Back" button
5. Go to the page from Step 2, but you now see the "logged out" version of the page
The details on how to achieve this are TBD.
Potential Approaches
Here are some approaches discussed, it's uncertain which of these work. Please update this ticket to verify which do.
Option 1: JavaScript History API
See https://www.drupal.org/project/logout_redirect
Option 2: JavaScript window.onpageshow
See https://gomakethings.com/fixing-safaris-back-button-browser-cache-issue-...
Option 3: Cache-Control no-store
See #3130912: Incorrect Cache-Control headers for authenticated users
Option 4: Clear-Site-Data: "cache"
See https://www.fastly.com/blog/clearing-cache-browser
https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Clear-Site-Data
Reference Material
- https://madhatted.com/2013/6/16/you-do-not-understand-browser-history
- https://www.f5.com/services/resources/white-papers/caching-behavior-of-w...
- https://stackoverflow.com/questions/866822/why-both-no-cache-and-no-stor...
- http://blog.httpwatch.com/2008/10/15/two-important-differences-between-f...
- https://www.fastly.com/blog/clearing-cache-browser
- https://sookocheff.com/post/api/effective-caching/
- https://resources.infosecinstitute.com/browser-based-vulnerabilities-in-...