Thousands of Firefox users accidentally commit login cookies on GitHub Thousands of Firefox cookie databases containing sensitive data are available on request from GitHub repositories, data potentially usable for hijacking authenticated sessions. These cookies.sqlite databases normally reside in the Firefox profiles folder. They're used to store cookies between browsing sessions. And they're …
How does someone manage to commit a FF profiles folder?
You normally create a repo for each project directory.
Are people creating a repo for their entire home directory - so if they forget to exclude something it gets added? Perhaps to use github as free backup?
I indeed wrote a program that functions like dropbox and uses GitHub (and mirrors to GitLab and BitBucket) as a backend (It even splits files to <100MB chunks and recombines them behind the scenes ;).
But, only a weirdo would share the root of their $HOME directory... The sharing is usually constrained to a folder (i.e ~/DropBox).
I don't think they will ever be able to make a public service idiot proof for *these kinds* of users.
I get that a big part of security is about protecting numbskulls holding the keys to the kingdom from inadvertently handing them over, but at what point do we just let natural selection play out and let the idiots get hacked on their own lack of merit?
The ingredients to this problem suggest a gross lack of understanding of things by a person who's job is to understand and develop the things. On those grounds I can see GitHub really saying "Look; We can't be assed to save every moron from themselves and we're not going to pay a bug bounty because you found that some idiots committed the equivalent of mypasswords.txt to their public repos."
Personally, I want these people to get hacked so hard that they give up coding. Got enough halfwits writing shite code in JavaScript and Python out there already.
It says in the article -
Marlin speculates that the oversight is a consequence of committing code from one's Linux home directory. "I imagine in most of the cases, the individuals aren't aware that they've uploaded their cookie databases," he explained. "A common reason users do this is for a common environment across multiple machines."
We might guess that some of that environment is something they want to be able to version and diff for analysis - but certainly not the cookies. However, it is unsafe to put an environment e.g, the contents of `/etc` on Linux, on a private github account, let alone a public one, even without the cookies. Better to encrypt the content, and then decrypt and diff when necessary. (Only a short script away.) Then a public github account could be safely used if that was the most convenient storage. Environments, e.g, the contents of `/etc` on Linux, are not usually that large.
If the individuals who uploaded these cookie databases were made aware of what they'd done, they'd s*** their pants."
They should not shit their pants. The shit needs to be expelled at record speed. They should actually be banned from using the public interwebs. The users doing a commit of their home folder with private stuff to a public site is just too stupid. They deserve to shit themselves and all shit should hit a fan blowing in their faces, at record speed.
Github, as a public accessible site, is a bad match for private stuff. period. Learn the tools and consequences before you shit yourself in public, idiots.
This post has been deleted by its author
This has nothing really to do with GitLab vs GitHub or anything like that. Anyone stupid enough to put their cookie files on GitHub can be stupid enough to put them on GitLab.
These are the same morons that make their AWS buckets public and store cleartext passwords and write firmware update systems that don't require authentication.
Yet why .sqlite should be excluded? It could be an empty database, one used to run tests, etc. etc. There's also the issue of using git as a deployment system - a VCS should not be a deployment system as it may store files that are not useful of even dangerous for a deploy (unless the repository is structured to be a "deployment only" and properly fed only with the necessary files - still, I don't like it).
But more and more developers attempt to use shortcuts to work less - and they commit and deploy too much.
Hidden files are a pretty common pattern for many software projects' configuration files though. Heck, even the .gitignore file is a hidden file.
I think there's a good reason to not have "sane defaults" for a gitignore file, because whatever one person might consider a perfectly fine set of things to ignore will be someone else's things they want committed.
I think in a case like this, while code hosting services could add warnings or block credentials, ultimately the onus is on the user to understand what they are committing.
> Hidden files are a pretty common pattern for many software projects' configuration files though. Heck, even the .gitignore file is a hidden file.
Right, and they should also not be committed. I think in this case, "dot for hidden" as the OS default should take precedence over git's view. Similarly, git should not add hidden-attribute files with a "git add *" on Windows either.
(I think the tendency of hiding, say, CI configuration files as dotfiles is fundamentally wrongheaded. This is the sort of "clean up the folder" instinct that would make people delete all those messy DLL files from system32 in the XP days.)
Is the file part of the build? Then it should not be a dotfile. Is it local state? Then it should not be committed.
If you're so lazy that you just do everything in your home directory because you can't be bothered typing mkdir and cd commands, or, a more frightening possibility, don't actually know how to use them, you really shouldn't be committing anything to github. A quick sweep of all their directories to identify any projects by people who've done this and an option to not show any projects by anyone who has would be useful, because I don't want to waste a second of my life on anything produced by such a moron.
Quite frankly, people who can't manage to put things into their own directories should not be using git. It's a development tool, and those who can't keep files properly separated are the same people who save all their documents directly on the desktop, and definitely not developers.
It's about as appropriate as giving a toddler a welding torch.
>> "I'm frustrated that GitHub isn't taking its users' security and privacy seriously," Marlin told The Register in an email.
GitHub isn't a mind reader. It doesn't know which uploaded data is private and which isn't. It trusts that the user correctly commits files to public and private repositories.
Every single file that is uploaded - publicly visible or not - is a potential security threat, data leak, or doxxing.
I can think of at least two legitimate reasons for uploading and making public facing a cookies.sqlite file:
1) controlled data to work with
2) a honeypot
Yes, some idiots might "accidentally" upload that file, but they might also "accidentally" upload their banking details as well or any other file that contains "sensitive" information.
If you dig into the Firefox code (I did) you'll see they are careful to ensure everything is encrypted before it leaves your machine. It's even possible (although not easy and poorly documented) to run your own sync server if you don't trust theirs.
That said, I don't think cookies are synced. Passwords and settings are.
"You'll be authenticated on any services which the user was logged in on when they committed the database"
Not to diminish the importance of the issue but the above statement assumes that "all authentication/session cookies for any and all web sites ever have no server-side expiration mechanism".
I don't think this is in any way the fault of GitHub, or a bug. Simply put, you shouldn't be committing anything to a git repo that you didn't want in the repo. Doubly so if it is a public repo. A database full of your auth cookies might be a juicy target, but the same could equally well be said about the fools who commit their AWS keys to public repos, or database connection strings containing credentials, or anything else private and/or sensitive because thy don't understand the concepts of user secrets and .gitignore files.
In short, it's not GitHub's job to fix stupid. You'll find a linear solution to the travelling salesman problem first.
We could consider another plausible scenario for a-few/some/most of these cases.
A developer sets up an environment for testing on a container or VM, and that test includes the use of a browser. They want the browser to be already initialized and pre-installed for faster testing across a variety of ? so they set it up that way on purpose. There is nothing critical in the cookies.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2025
