tor exit node scanning my site 6:20pm PDT.
One in every 600 websites has .git exposed
91–100 of 214 posts
Re: One in every 600 websites has .git exposed
#92Earlier quoted context omitted.
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.
How do you communicate that data amongst team members then?
I think at one point, if you have a shared password for a development DB, production DB, etc. then just keeping those on a pen and paper notebook is your best solution. Usually, for shared environments such as that (although I hope the team can set-up their own DB's for development!), the number of shared "secrets" is relatively small. Some secrets are best not stored electronically, especially if they can give away user data.
Re: One in every 600 websites has .git exposed
#93Earlier quoted context omitted.
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.
How do you communicate that data amongst team members then?
As I detailed in my other response to your original question, use an example config file that is version controlled. It includes all the necessary config keys, but example-only values. All team members would then be able to easily create a local config file based on the example that works. You can even document the config with comments in the example file so devs know what is needed and what it's for.
Re: One in every 600 websites has .git exposed
#94Earlier 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?
My preferred solution currently is to use try to use encrypted strings in config files that are not stored in VCS. The host machine encrypts and decrypts using host specific keys so if the file is copied off-server, it is not fully compromised immediately. This is usually via python script which rewrites the file. (BTW, pretty easy to do on Windows boxes with MS API). I've considered using encrypted folders on windows in addition but not sure if that really makes a difference.
Usually the base config is in VCS but without user/password/db strings. We then manually configure the file with the encrypted strings on the server (usually with the machine name in the filename so that we can use hostname in code to find it and makes it clear the file is machine specific). Not all tools make this easy though and only works if you can add your own code in between. Also prefer files to environment as the files can be locked down easier in my opinion and more obvious what is going on.
I like some of the other solutions that are using encrypted strings but with a keystore server and may consider for the future if they support both windows and linux.
Re: One in every 600 websites has .git exposed
#95It 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
It looks like for some reason Google actually searches for the character "．" (U+FF0E, "fullwidth full stop") when performing those sorts of queries, not "." (U+002E, "full stop").
For example, check the URLs of these search results: https://www.google.com/search?q=inurl:%22.hello%22
Re: One in every 600 websites has .git exposed
#96Earlier quoted context omitted.
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 f…
> Can you elaborate on why it shouldn't be exposed?
Because there is no need to expose it. If you expose it then you need to vet not only it's head but it's entire history, and for what purpose?
> For a large percentage, they're running a CMS like Wordpress or Drupal or whatever
I doubt someone running Wordpress would be using version control anyway. Most of the time it is WP + some standard plugins and no custom coding.
> And for even more, we're talking about a directory of hand-crafted HTML files
And anything else you happened to have in your directory. Your passwords file? Even if you commit a delete there is still history!
Re: One in every 600 websites has .git exposed
#97I discovered almost the exact same problem in a very large production site once, except it was the .svn directory.
Re: One in every 600 websites has .git exposed
#98I 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?
I think less likely. Svn actually had an `export` command, which allowed you to do a checkout of a specific commit with no svn metadata. If someone was actually using svn for deployment, they likely knew about it. ( http://svnbook.red-bean.com/en/1.7/svn.ref.svn.c.export.html )
git has `archive`, which is essentially the same thing.
Re: One in every 600 websites has .git exposed
#99Earlier 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…
Just wanted to +1 the suggestion for Vault - I've found it to be a really nice balance between usability and security.
Re: One in every 600 websites has .git exposed
#100Imagine 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…
I did a conference talk at derbycon on exactly this, regarding startups. The amount of obvious holes of founders not knowing what XSS is, or writing bad PHP apps with obvious code execution vulns, or glaring logic and auth mistakes allowing full account hijacks is incredible. It's really bad out in AppSec land
Link to your talk ?