56788 - Cookies need to be encrypted via one-way hash

Status: VERIFIED WONTFIX

(Core :: Networking: Cookies, enhancement, P3)

Description

[Matthew Brealey]

Many sites can be compromised by adding a fake cookie to cookies.txt. A common 
authentication technique is to store a cookie with the username, and to test 
for the presence of this in deciding whether to allow access.

Unfortunately cookies are stored in cookies.txt in clear text, and it is 
therefore possible to add a fake entry and gain access to many sites.

This needs fixing so that cookie names and values are encrypted so that people 
can't fake entry.

Comment 1

[Gilles Durys]

This would render the cookie manager completely useless.
(IMHO, it's up to the site's owner to encrypt the value).

Comment 2

[Matthew Brealey]

Not true. The site should be able to trust that it is reading its own cookie. 
It is not enough to say that the site should 'do encryption'. Many (most?) web 
programmers are incompetent and won't do this. 

Comment 3

[Stephen P. Morse]

This is an interesting turn of events.  Browser security concerns normally have 
to do with the site using the browser to attack the user.  In this case, the 
user is using the browser to attack the site.

It would certainly take a sophisticated user (i.e., a hacker) to know how to 
forge a cookie.  That same user could modify the open-source browser code to do 
the forging for him, no matter how we encrypted the cookies file.  So trying to 
protect the site from the user is a hopeless task.

If the site has something to lose by being compromised in this manner, then I 
would agree with Gilles that the site should take some preventative measures and 
not the browser.  I would think that most sites wouldn't care about this.

Therefore my inclination is to close this as "wont fix".  cc-ing some other 
security folks to see if they agree/disagree with me on this.

Comment 4

[Matthew Brealey]

> it would certainly take a sophisticated suer

Open up cookies.txt. There in plain text (in mine):

bugzilla.mozilla.org	FALSE	/	FALSE	1877472107	Bugzilla_login
	[e-mail]

How sophisticated do you need to be to work out what's going on there? 
[I bet a lot of high-profile sites could be compromised in this manner - I 
heard, for example, that Barclays bank, Britain's largest bank was hacked 
because the programmers were to stupid even to know about Pragma: no-cache 
(etc).]

Comment 5

[Hixie (not reading bugmail)]

Oh come on!!! Whatever we do with our cookies file, people can still send 
cookies to remote hosts using any network utility such as netcat or even telnet,
which comes with every decent operating system on the planet!

Any sites that can really be cracked by passing a "forged" cookie are so badly
designed that they _deserve_ to be cracked. 

VERIFIED WONTFIX.

Comment 6

[Peter "jag" Annema]

One hint: Bugzilla_logincookie

Comment 7

[Mitchell Stoltz (not reading bugmail)]

I agree with the WONTFIX. This problem is up to the websites to fix, not the
browser. It's too easy to work around any encryption we might put on the cookies
file. Using cookies for site authentication is frowned upon anyway. And yes,
this includes Bugzilla.

Comment 8

[Stephen P. Morse]

*** Bug 116916 has been marked as a duplicate of this bug. ***

Comment 9

[Frank Wein [:mcsmurf]]

*** Bug 280285 has been marked as a duplicate of this bug. ***

Comment 10

[Alexander Kachkaev]

Here is how I got here today, 16 years since the last comment (Firefox 76, macOS 10.15 Catalina).

1. Used Firefox as my primary browser for years, thinking that my data was protected from other running apps

2. Downloaded Yandex Browser (via brew cask install yandex) just to test if one Chrome extension works in it or not

3. Opened Yandex Browser. Saw:

   • no prompts from FF
   • a keychain prompt about Chrome storage, which I rejected
     Yandex Browser featured:
   • all my currently open FF tabs (OK)
   • all my FF history (meh, but maybe OK)
   • active logged in sessions into gmail, github, facebook, twitter and so on (W T F ?!)

So what happened was that some macOS app I just downloaded sniffed the Firefox DB and could successfully read all my browsing data! That's pretty shocking to say the least!

I’m a web developer who actively uses yarn and npm each data. Ths means that I routinely download thousands of third-party packages and it's just a matter of time when a just-published malicious package will be able to read stuff from my disk. This won’t do harm to apps relying on the macOS keychain and even my ssh keys will be safe, thanks to the master passwords. However, the unencrypted FireFox DB will be a trivial target for hackers – this case with Yandex Browser demonstrates that there are no barriers opening it!

I'm not an expert in desktop app development, but I'm pretty sure that macOS is capable of making the data secure. It must be a matter of some negotiation between a signed app and the OS, all happening without any user involvement.

Is keeping a sqlite file with some extremely sensitive data still acceptable in 2020?

Comment 11

[Daniel Veditz [:dveditz]]

You most likely want bug 1562324 which wasn't possible (supported by OSes) when this bug was WONTFIXed. It is now (that's what's behind that keychain prompt you got for Chrome) and using it is what bug 1562324 is about.