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).
One in every 600 websites has .git exposed
41–50 of 214 posts
Re: One in every 600 websites has .git exposed
#42Obviously 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…
Re: One in every 600 websites has .git exposed
#43location ~ /\. { 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
#44Re: One in every 600 websites has .git exposed
#45Someone 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
#46 location ~ /\. {
deny all;
access_log off;
log_not_found off;
}Re: One in every 600 websites has .git exposed
#47I 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.
Re: One in every 600 websites has .git exposed
#48Obviously 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.
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
#49It 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.
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
#50Obviously 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.