Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

One in every 600 websites has .git exposed

jamiembrown.com

Post reply on HN
Print view View original

101–110 of 214 posts

Re: One in every 600 websites has .git exposed

#101

Post by ForHackernews »

nostrademons wrote: post #51
Nate75Sanders wrote: post #27

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…

You probably should revoke all your existing credentials and replace them with fresh ones as soon as you pull them out of the VCS. That way, your attackers have the credentials, but they don't work anymore.

We've left test keys in our git repos. They don't work for anything except a virtual machine used for local development, but I always thought it would be amusing if a hacker grabbed them and got frustrated trying to use them.

Re: One in every 600 websites has .git exposed

#102

Post by ejcx »

RowanH wrote: post #100
ejcx wrote: post #85

Earlier quoted context omitted.

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 ?

It was my first conference talk. If you would like to ask any questions email me at the one in my profile

https://m.youtube.com/watch?v=wzrVYyouQTk

Re: One in every 600 websites has .git exposed

#103

Post by notduncansmith »

sago wrote: post #86
thaumaturgy wrote: post #76

Earlier quoted context omitted.

Better better yet, don't use git to move code from test to prod. Use rsync, and exclude .git and other nuisance files. Unfortunately I can't seem to convince anyone that this is good practice. :-(

Amen! Use rsync --checksum --ignore="..." unless you have a damn good reason not to (--checksum is essential to prevent corruption/malicious modification, without it you are implicitly assuming the version on the remote machine is exactly how you left it: that assumption is why Linus built git around shasum in the first place). rsync is even easier than SSHing to git pull, or opening up a pushable repo on a server. F…

One approach that I've found works well (YMMV, etc) is deploying with Ansible. It has a Git module built in (so it's almost 0 work to configure), and you can set up SSH agent forwarding so you never have put keys on the server that have access to your source control, nor manually SSH in and pull.

Re: One in every 600 websites has .git exposed

#105

Post by craigkerstiens »

dangero wrote: post #68
Dylan16807 wrote: post #57

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?

http://12factor.net provides a good guidance for this at a high level. In reality all config should be separated from code.

There's a variety of mechanisms for loading this into your environment.

Re: One in every 600 websites has .git exposed

#106

Post by viraptor »

matt_kantor wrote: post #98
viraptor wrote: post #26

Earlier quoted context omitted.

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. [1]: http://git-scm.com/docs/git-archive

No, archive is very different. `svn export` could be used at the target side. Basically you can export from remote repository to the chosen directory without any extra operations, so .svn is never created.

`git archive` requires you to have a clone of the repo from which you can create an archive. That means people are more likely to just do a local checkout than play with archive on top of it.

Deploy with svn export:

    svn export url.of.repo destination/path
Deploy with git archive:

    git clone url.of.repo
    cd repo_name
    git archive --format=tar some_commit_or_branch | (cd destination/path && tar -xf -)

Re: One in every 600 websites has .git exposed

#107

Post by alexisnorman »

tokenizerrr wrote: post #73
dangero wrote: post #68

Earlier quoted context omitted.

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

Environment variables are the best and easiest way that I know of. You can supply those anyway you want to, and any programming language can easily get their values.

I'm surprised this isn't higher up. Are there any arguments against ENV variables in favor of something else?

Re: One in every 600 websites has .git exposed

#108

Post by crdoconnor »

dangero wrote: post #68
Dylan16807 wrote: post #57

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?

http://docs.ansible.com/ansible/playbooks_vault.html

Re: One in every 600 websites has .git exposed

#109

Post by cddotdotslash »

dangero wrote: post #68
Dylan16807 wrote: post #57

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?

I use AWS for a number of applications, so I've started doing the following:

1. Create a JSON file containing encrypted secrets (DB pass, etc.)

2. Upload the file to a secure S3 bucket with fine-tuned permissions and server-side encryption

3. For the instance that is launching, include the permission in the IAM role that allows it to "S3:GetObject" on the specific JSON file you uploaded.

4. Deliver decryption keys to the app in some manner (Chef, Ansible, etc.)

5. When the app starts, it downloads the JSON file and loads the environment variables.

I wrote a blog post[1] about this with more detailed info and an NPM module if you use Node.js.

[1] http://blog.matthewdfuller.com/2015/01/using-iam-roles-and-s...

Re: One in every 600 websites has .git exposed

#110

Post by raquo »

thaumaturgy wrote: post #75
dangero wrote: post #68

Earlier quoted context omitted.

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

FWIW I have a /private directory in the root of all vhosts, so it looks like: /srv/www/domain.com/public_html/ |--------->/private/ |--------->/logs/ |--------->/tmp/ Anything stored in /private/ is not publicly accessible by the web server process, but can be read or written by anything running under the user's username. It's specifically for storing things like configuration files. I think this should be standard p…

Why do you store such stuff under /public_html anyway? One level higher would be more appropriate I think.
Post reply on HN