back to article 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 …

  1. unimaginative
    WTF?

    How does anyone manage to do this?

    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?

    1. Anonymous Coward
      Anonymous Coward

      Re: How does anyone manage to do this?

      In which case could a .ssh folder not be committed too?

    2. karlkarl Silver badge

      Re: How does anyone manage to do this?

      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.

    3. Anonymous Coward
      Anonymous Coward

      Re: How does anyone manage to do this?

      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.

    4. Bravo Charlie

      Re: How does anyone manage to do this?

      I imagine the people doing this are plug-in developers for Firefox. In which case, a lot depends on whether the cookies files are from a dev sandbox or from an active firefox instance.

      1. fch
        Trollface

        Re: How does anyone manage to do this?

        What is this "Dev Sandbox" thing you're talking about ? Only kiddie developers use sandboxes. Real Develoopsers commit sins^Wcode right on their live instances. And github is free cloud storage for Real develoopsers. All cool. Oops.

    5. Anonymous Coward
      Anonymous Coward

      Re: How does anyone manage to do this?

      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.

  2. b0llchit Silver badge
    Facepalm

    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.

  3. This post has been deleted by its author

    1. Gene Cash Silver badge

      Re: Thank god I only use my github login for comments on other devs projects.

      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.

  4. LateAgain

    Should all software include a gitignore file?

    Just asking. You can't fix "stupid"

  5. FeepingCreature Bronze badge

    A git bug?

    Arguably a git bug: if you "git add .", it will include hidden files (ie. dotfiles) unless explicitly excluded.

    (The same happens if you git add \*, or git add * in a folder with only hidden files.)

    Git really needs a sane default for gitignore.

    1. Mike 137 Silver badge

      Re: A git bug?

      Or a git behaviour (or maybe both)?

      A well named service for such happenings.

    2. LDS Silver badge

      Re: A git bug?

      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.

    3. JVDL

      Re: A git bug?

      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.

      1. FeepingCreature Bronze badge

        Re: A git bug?

        > 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.

  6. MidgetOfDoom

    What sort of idiot would do such a thing?

    1. Anonymous Coward
      Anonymous Coward

      "What sort of idiot would do such a thing?"

      a 'GitHub dork'?

  7. Howard Sway Silver badge

    a consequence of committing code from one's Linux home directory

    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.

    1. Loyal Commenter Silver badge

      Re: a consequence of committing code from one's Linux home directory

      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.

      1. David 132 Silver badge
        Happy

        Re: a consequence of committing code from one's Linux home directory

        You insensitive bastard. I do all my development under MS-DOS 1.0, and cannot create subdirectories.

  8. Draco
    Big Brother

    Enough with the demands for Totalitarian control.

    >> "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.

  9. Omnipresent

    If you want to be safe.

    "When choosing to backup sensitive Firefox profile data, Mozilla recommends Firefox Sync, which encrypts and safely stores files within Firefox servers."

    Hand it over to the internet. We'll keep your data safe.....As bad as chrome.

    1. Stumo
      Headmaster

      Re: If you want to be safe.

      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.

  10. Pascal

    "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".

    1. FrogsAndChips

      Re: expiration

      From the article:

      "One mitigating factor at least is that sessions and associated cookies tend to expire relatively quickly."

  11. Loyal Commenter Silver badge

    Idiots commit private data to public repositories. Film at 11.

    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.

  12. Anonymous Coward
    Anonymous Coward

    Not critical cookies?

    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.

POST COMMENT House rules

Not a member of The Register? Create a new account here.

  • Enter your comment

  • Add an icon

Anonymous cowards cannot choose their icon

Other stories you might like

Biting the hand that feeds IT © 1998–2022