6

On one of my web servers, I have set up a password-protected directory using the well-known .htaccess / .htpasswd mechanism. The web server is run by Apache 2.4.10 under Debian jessie, if that matters. The relevant snippet from the virtual host configuration:

<Directory "/home/www/path/to/protected/directory">
  AuthType Basic
  AuthName "Restricted Content"
  AuthUserFile /etc/apache2/.htpasswd
  Require valid-user
</Directory>

Now, when I open a document from that protected area using Firefox, Firefox asks for the credentials. So far, so good.

But when I clear Firefox's login data and cache, using Tools -> Options -> Privacy & Security -> Clear Data -> Clear (with both items in the dialog being checked), and then re-open the same or any other document from that protected area, Firefox shows that document without asking for the credentials again.

In other words, Firefox either does not delete its cache when being instructed to do so, or it does not delete what it calls "Site Data" when being instructed to do so.

If I am right, this is a serious security breach. A reasonable user knows that (when not using his own private device, e.g. when using a PC in an internet cafe) the browser's cache and login data should be cleared after having used the browser to access password-protected areas, and relies that this works.

The only way to make Firefox forget such logins seems to be to first clear the cache and the Cookies and Site Data as described above and then immediately close the application (File -> Exit).

But this is not a real solution to the problem. If I instruct a browser to clear the Cache and the Cookies and Site data, I expect that it immediately forgets all credentials without restarting. Period.

I have tested this with Firefox 61.0.2 (the most recent version at the time of this writing) under Windows 7.

By the way, Chrome does it right.

Finally, to avoid misunderstandings:

The above only relates to credentials for the areas which are protected by .htaccess, i.e. where the browser itself asks for the credentials. All sites which implement access control by session cookies are not affected by the problem, because (as far as I can tell) Firefox indeed deletes all cookies as soon as you make it delete its data as described above.

What do you think about this? Is it a security problem?

user
  • 7,670
  • 2
  • 30
  • 54
Binarus
  • 557
  • 5
  • 16
  • Your question reminds me of when I'd try to clear Firefox browser history but kept leaving the "preserve favorites website data checkbox" thus it would delete everything except my most commonly used items. – neonprimetime security Jun 05 '19 at 04:25

2 Answers2

7

Firefox (Firefox 68.0, under Linux) doesn't store this info in Cookies and Site Data but in History.

You need to go to Preferences->Privacy & Security and under the History section, click on Clear History.... Make sure the Active Logins checkbox is checked before you submit.

nimda
  • 86
  • 1
  • 4
  • Thanks for the answer, and +1. Didn't try yet, but I believe you. So Mozilla considers the passwords as part of history rather than as part of site data. Very logical ... especially given that clearing the site data (including cookies which store session keys) normally logs you out of every site. So the user has to clear both the site data (cookies) *and* the history to log out safely from everything. Great. – Binarus Aug 06 '19 at 16:13
2

The accepted answer (clearing "Active Logins" from "Clear History...") has the disadvantage that it clears all active logins, including from other sites on other browser tabs.

An alternative, at least with Firefox, is to reload the page by specifying a different (or invalid) login. This can be done by adding it in front of the URL:

http://other-or-bad-user@www.example.com/...

This can also be used to login as a different user this way:

http://other-user:password@www.example.com/...

While such URL's have been deprecated in RFC 3986 for security reasons, they still work in Firefox v. 80. So it's still a viable workaround until browsers implement better authentication management.

Community
  • 1
mivk
  • 159
  • 3