Live data from Hacker News

One in every 600 websites has .git exposed

jamiembrown.com

61–70 of 214 posts

Re: One in every 600 websites has .git exposed

#61

Earlier quoted context omitted.

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 i…

I can't deny that nature likes quick n dirty, but I wish I could just find a balance between reckless and too slow.

Re: One in every 600 websites has .git exposed

#62
post #6

The author doesn't give any suggestions for alternative ways to deploy. What are the best practices here? What should operators that currently deploy this way do instead?

599 out of every 600 sites don't have the problem of a public facing .git folder. I don't think alternative deployments need to be suggested as they are commonplace. It depends on what sort of platform and server you're running on but just do what you have to do so you're not serving your .git.

Doesn't change anything, but worth noting, these are not necessarily 599 git-using websites being compared.

Re: One in every 600 websites has .git exposed

#63
post #22

Earlier quoted context omitted.

Would it be safer to not put .git within the reach of the webserver, and separate the development path from the production host path?

It certainly would, however like another comment I replied to ITT security doesn't have to be either-or it can be "do all the secure things". I.e. * No secrets in your repo * Only copy to the server what you need (and automate this) * Add conditions to your web server to not serve up .git, in-case the previous two checks failed. When working in teams I think having additional checks and balances and not one 'perfect…

Extremely good point - we should always aim for security in depth and especially don’t rely on people not doing stupid things, because if it is possible then someone will at some point.

Re: One in every 600 websites has .git exposed

#64

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…

> Obviously you shouldn't be storing sensitive information in your codebase (I hope everybody knows that)

Sadly, in my experience hardcoding secrets such as (database) passwords and encryption private keys is not uncommon at all in web applications. I don’t like criticising other developers, but sometimes the people who get to make these decisions don’t necessarily have the perspective or experience to make the rights calls.

Re: One in every 600 websites has .git exposed

#65

Earlier quoted context omitted.

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 i…

I can't deny that nature likes quick n dirty, but I wish I could just find a balance between reckless and too slow.

The balance is whatever works, gets people using the product, and ideally keeps them happy.

The balance is generally far more on the quick 'n dirty side than most engineers (myself included) would prefer, but we could look at this as a cognitive bias of engineers rather than a failing of nature.

Re: One in every 600 websites has .git exposed

#66
post #29

It seems Google doesn't like people looking into the extent of this problem [1]. When googleing for "inurl:.git", it returns no results. And on top of that, I need to enter a captcha first? [1] https://www.google.be/search?q=inurl%3A%22.git%22

The .git directory wouldn't be crawled though, correct?

Most of the time it wouldn't be crawled.

But zero results is blatantly wrong.

Re: One in every 600 websites has .git exposed

#68

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…

Wrong lesson. Don't put secret keys in your repository. Someone getting a copy of your code should be a big annoyance at worst.

Where is the right place to store db passwords, api keys, etc? What is best practice in this area?

Re: One in every 600 websites has .git exposed

#69
post #68

Earlier quoted context omitted.

Wrong lesson. Don't put secret keys in your repository. Someone getting a copy of your code should be a big annoyance at worst.

Where is the right place to store db passwords, api keys, etc? What is best practice in this area?

In a configuration file that is not version controlled, or even environment variables, so that your application starts with the right variables, but they are not in some config file.

Re: One in every 600 websites has .git exposed

#70
post #68

Earlier quoted context omitted.

Wrong lesson. Don't put secret keys in your repository. Someone getting a copy of your code should be a big annoyance at worst.

Where is the right place to store db passwords, api keys, etc? What is best practice in this area?

Stack Exchange's blackbox [1] is one solution. I haven't played with it personally and I'd love to hear other people's take on what's worked for them.

[1] https://github.com/StackExchange/blackbox

Post reply on HN