Open Bug 56788 Opened 25 years ago Updated 2 months ago

Cookies need to be encrypted when stored on disk

Categories

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

x86
All
enhancement
Points:
8

Tracking

()

REOPENED

People

(Reporter: webmaster, Unassigned)

References

(Depends on 2 open bugs)

Details

(Keywords: sec-want, Whiteboard: [necko-triaged])

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.
This would render the cookie manager completely useless. (IMHO, it's up to the site's owner to encrypt the value).
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.
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.
Status: UNCONFIRMED → RESOLVED
Closed: 25 years ago
Resolution: --- → WONTFIX
> 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 webmaster@richinstyle.com 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).]
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.
Status: RESOLVED → VERIFIED
One hint: Bugzilla_logincookie
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.
*** Bug 116916 has been marked as a duplicate of this bug. ***
*** Bug 280285 has been marked as a duplicate of this bug. ***

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?

Flags: needinfo?(nhnguyen)

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.

Flags: needinfo?(nhnguyen)
Type: defect → enhancement
See Also: → 1562324
Duplicate of this bug: 1331238
Duplicate of this bug: 1428262
Duplicate of this bug: 1739732
Duplicate of this bug: 1259652
Duplicate of this bug: 1743810
Duplicate of this bug: 496306
Duplicate of this bug: 588704

bug 19184 is a more general "encrypt everything" bug but cookies are worth considering separately. Moving some dupes from that one to here.

bug 1889150 is another potential technology that this could be built on once it's done. details are sparse though. bug 1562324 might still be the best bet.

Status: VERIFIED → REOPENED
Ever confirmed: true
Keywords: sec-want
Resolution: WONTFIX → ---
See Also: → 19184, 1889150
Summary: Cookies need to be encrypted via one-way hash → Cookies need to be encrypted when stored on disk
Duplicate of this bug: 521740
Duplicate of this bug: 460617
Severity: critical → --
Priority: P3 → --
Assignee: morse → nobody
QA Contact: tever
Duplicate of this bug: 1907214

I am not putting this on our priority backlog as we have pending dependent bugs.
But we should put this on our roadmap once we have the required code support available to implement this.

Ed, FYI.

Severity: -- → N/A
Points: --- → 8
Rank: 5
Priority: -- → P3
Whiteboard: [necko-triaged]
Flags: needinfo?(edgul)
Flags: needinfo?(edgul)
Duplicate of this bug: 1964105
You need to log in before you can comment on or make changes to this bug.