Live data from Hacker News

One in every 600 websites has .git exposed

jamiembrown.com

41–50 of 214 posts

Re: One in every 600 websites has .git exposed

#41
post #39

Imagine you implement every type of possible security... Keeping your entire server-stack up-to-date, making sure you have SSL, using strong encryption for logging-in, hashing the passwords, making sure your server can only be reached via SSH, adding firewalls, filters, etc. etc. Then some hacker in Eastern Europe comes along (or some beginner at the NSA/GCHQ) and finds out that your .git is exposed and somehow gains…

Well, that's why you either have a team of competent people making sure all your stuff is up to date, routinely performing pentests, etc., or you delegate as much as possible of those responsibilities to 3rd parties (e.g. Heroku).

Doesn't matter. Eventually, there is a 0-day, that no one knows about, that is used on you.

Re: One in every 600 websites has .git exposed

#42

Obviously you shouldn't be storing sensitive information in your codebase (I hope everybody knows that), but the problem here is that you might have been way back when you were prototyping and then moved them out of the codebase . It's really common to start a codebase just by hacking something together with hardcoded secrets. If you have the proper secret segregation now, but you're deploying by doing a git pull, no…

Growing a project from one shot mindset prototyping is really problematic. Every time I wish I started by using a real project structure and design philosophy.

Re: One in every 600 websites has .git exposed

#43
Someone on StackOverflow says this will tell nginx not to serve hidden files.

location ~ /\. { return 403; }

My question - do I need to put this once at the top of my configuration file and all it good or does it need to go into multiple places in the nginx config?

It would be great if there was a simple, universal way to say to nginx "don't serve hidden files from anywhere under any circumstances".

Re: One in every 600 websites has .git exposed

#44
It always felt unclean to have the source repo on production, so we use deployhq.com (similar: circleci.com, Jenkins) to push changes up when code changes are made, rather than pull them from git. We also use a clean-up script that removes any SASS, Grunt, etc source files when deploying to production.

Re: One in every 600 websites has .git exposed

#45
post #43

Someone on StackOverflow says this will tell nginx not to serve hidden files. location ~ /\. { return 403; } My question - do I need to put this once at the top of my configuration file and all it good or does it need to go into multiple places in the nginx config? It would be great if there was a simple, universal way to say to nginx "don't serve hidden files from anywhere under any circumstances".

[deleted]

Re: One in every 600 websites has .git exposed

#47
post #17

I wonder what would happen if you searched for .svn, too. I'm sure you'd run into the same problem in many places. But would it be more or less likely to occur?

In svn's heyday, the standard way to install or update a popular app like WordPress was to download and extract a tarball. Only people who actually participated in the development of the app itself used svn. Nowadays, lots of open-source projects encourage ordinary webmasters to clone a Github repo and run `git pull` to update. So I suspect that public .svn folders will be less common.

That's problematic in itself. "git" has no business being installed on your public-facing web server. Nor should there be any compilers installed, nor any scripting languages not explicitly needed, etc. etc.

Re: One in every 600 websites has .git exposed

#48

Obviously you shouldn't be storing sensitive information in your codebase (I hope everybody knows that), but the problem here is that you might have been way back when you were prototyping and then moved them out of the codebase . It's really common to start a codebase just by hacking something together with hardcoded secrets. If you have the proper secret segregation now, but you're deploying by doing a git pull, no…

Growing a project from one shot mindset prototyping is really problematic. Every time I wish I started by using a real project structure and design philosophy.

And then every time I actually start a project with a real project structure and design philosophy, it goes nowhere and I wish I hadn't wasted the time. Or best case, it's used by a few people internal to whatever company is currently employing me, and security doesn't really matter.

The tech industry is shaped like a funnel, with lots of raw, bad ideas at the top and a few smash mega-hits at the bottom. 99% of the ideas at the top are bad; investing more time than is necessary to prove them out is a mistake. 100% of the ideas that make it to the bottom wish that they'd spent more time designing things at the top. But y'know, if they'd actually done that, they wouldn't have made it to the bottom, they'd be outcompeted by the guy who got a quick and dirty prototype up, made his users happy first, and then closed the gaping security holes (hopefully!) before anyone noticed.

Re: One in every 600 websites has .git exposed

#49
post #21

It seems like if you're storing secrets and the like in your code's repo, the solution is to not do that, rather than just putting a bandaid over it by hiding the repo. Deploy the secrets separately: they don't belong in your site's codebase.

Hiding the repo is hardly a bandaid. It should never be exposed even if the repo is perfectly secret-free. Except in the rare cases where it is intentional e.g. an open source repo and you happen to want people to download it from the same domain not github or git.domain.com.

Can you elaborate on why it shouldn't be exposed?

Presumably, for most commercial entities, the parts of the site that are valuable are the assets, which are served from the site as part of it doing the thing it's meant for. For a large percentage, they're running a CMS like Wordpress or Drupal or whatever, where the codebase is public anyways. And for even more, we're talking about a directory of hand-crafted HTML files, where the version control is the HTML of the site plus some "damn, I always forget to close my tags" commit messages.

Re: One in every 600 websites has .git exposed

#50

Obviously you shouldn't be storing sensitive information in your codebase (I hope everybody knows that), but the problem here is that you might have been way back when you were prototyping and then moved them out of the codebase . It's really common to start a codebase just by hacking something together with hardcoded secrets. If you have the proper secret segregation now, but you're deploying by doing a git pull, no…

Growing a project from one shot mindset prototyping is really problematic. Every time I wish I started by using a real project structure and design philosophy.

Once it gets to a certain level of "no longer prototype", it can help if you then start VCS fresh by initing a new git repository. You lose the prototyping history, but you probably won't need it anyway.
Post reply on HN