Wait, do people store repo passwords in .git? Otherwise a simple remote address means nothing.
I think it's more they have access to your codebase, which could then be analyzed to look for exploits.
One in every 600 websites has .git exposed
131–140 of 214 posts
Re: One in every 600 websites has .git exposed
#132Earlier quoted context omitted.
Where is the right place to store db passwords, api keys, etc? What is best practice in this area?
We (Shopify) use https://github.com/Shopify/ejson -- we store encrypted secrets in the repository, relying on the production server to have the decryption key. It's relatively common to provision secrets with configuration management software like Chef/puppet/ansible/etc using, e.g. Chef's encrypted data bags. Another slightly heavier-weight solution with some nice properties is to use a credential broker such as Vau…
For ansibile the built-in solution is: http://docs.ansible.com/ansible/playbooks_vault.html
Re: One in every 600 websites has .git exposed
#133Why are people serving web traffic to a folder with a .git folder anyways? I thought it was basic deployment practice to export your code OUT of the VCS before deploying... every shop I've worked at had this in place. Other solutions just seem hackish to me, but every project is different I suppose.
So that deployment is "just" git pull.
I don't get it either.
Re: One in every 600 websites has .git exposed
#134Earlier 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.
Don't put secret keys in your repository is also the wrong lesson. The right lesson is: Know where your secret keys are and take the appropriate steps to secure them. Whether that's in the codebase, a properties/ini/conf/whatever file, environment variables, whatever - know where they are and make sure you understand possible threats against them. This story could just as easily have been written about how easy it is…
Is there a general algorithm that can tell you all possible threats against your secret keys?
Re: One in every 600 websites has .git exposed
#135The 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?
Personally I would use standard practices of the open source world; package your app properly into a .deb/.rpm, deploy that and push configuration for it out using puppet/ansible/etc. aka, debops!
Re: One in every 600 websites has .git exposed
#136I'm not surprised in the slightest given the current trend to build everything in production.
Re: One in every 600 websites has .git exposed
#137Earlier quoted context omitted.
Don't put secret keys in your repository is also the wrong lesson. The right lesson is: Know where your secret keys are and take the appropriate steps to secure them. Whether that's in the codebase, a properties/ini/conf/whatever file, environment variables, whatever - know where they are and make sure you understand possible threats against them. This story could just as easily have been written about how easy it is…
Is there a general algorithm that can tell you all possible threats against your secret keys?
No, there are an infinity of things that shouldn't have access to your secret keys. So you have to take a default deny approach, and ensure that only things that positively should have access to your secret keys do.
Re: One in every 600 websites has .git exposed
#138Is there an automated "security as a service" service that if I subscribed to it, it would have told me that this is a problem on my websites? It really annoys me randomly hearing about critical security issues through tech news websites - there should be a more systematic way for "non-security professionals" to ensure their sites are protected to best practice levels.
Mail me at mdcrawford@gmail.com if you'd like to be my very first early adopter.
Re: One in every 600 websites has .git exposed
#139Earlier 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.
Don't put secret keys in your repository is also the wrong lesson. The right lesson is: Know where your secret keys are and take the appropriate steps to secure them. Whether that's in the codebase, a properties/ini/conf/whatever file, environment variables, whatever - know where they are and make sure you understand possible threats against them. This story could just as easily have been written about how easy it is…
Putting keys in a text file doesn't fit the narrative of a generally-careful user forgetting about side effects and metadata.
It's important to know where your keys are, but it's also important to not store your keys in certain ways that are easily overlooked.
A lesson of "don't put secret keys inside the web root" is also useful.
But a lesson of "know where your keys are and secure them" is a bit too short-sighted. You don't just want them to be secure right now, you want the mechanisms keeping them secure to be mistake-resistant.
Don't put them in the code, even if you promise to be super careful.
Re: One in every 600 websites has .git exposed
#140It's clear the problem involves some PHP sites developed with git and instead of using a specific www directory inside the project the server points to the root folder of the project thus exposing .git (and the rest). Classic dumb error by PHP developers. I have hard time believing one would be able to expose the .git folder in a Rails,Spring or Django application since the public folder isn't the root folder of the project.
I wish servers would be configured so they don't server ^\..+$ files by default. I wish servers would behave as secure as possible then it's up to the developer to whitelist features rather than the other way around.