9 ms·
Please stop serving .git to the outside world
- johnbburg 13y agodevs aren't always the ones deploying the sites they develop! Also, non-standard file extensions for source code is often exposed and should probably be hidden. (e.g. .module for drupal sites).
- andyhmltn 13y agoThis is a brilliant post. I was about to deploy a site before I read this. It's so easy just to forget that directory.
- tytso 13y agoTo be clear (it wasn't mentioned explicitly in the blog post), but it's obviously what the author was referring to, this is about people who are deploying web sites with static content which is being managed via git.
- jstanley 13y agoAnd it only applies when the document root is also the git repo root. If the document root is under a subdirectory, the .git directory won't be served.
- hdra 13y agoI'm curious, what security risk does static content could pose by serving the .git ?
- pyre 13y agoOff the top of my head, if you use an email (to commit) that you don't want the outside world to see, now it's exposed.
- calpaterson 13y agoIf you don't expect your source code to be made public and don't take care to keep secrets out of it, then you will be surprised when attackers have (for example) your cookie signing key. I know checking secrets into source code is already a bad practice, but accidental publication takes bad practice and makes it a security hole.
- drdaeman 13y agoParent post was asking about static content, not dynamic. No code to keep secret.
- drdaeman 13y agoI think there's nothing wrong with this if there aren't (and weren't) any secrets directly embedded in the source code and all configuration files that contain sensitive information are (and always were) properly gitignore'd. Tech-savvy users can even be encouraged to pull the code and send patches. :)
- wldlyinaccurate 13y agoSomebody correct me if I'm wrong here, but doesn't the .git directory essentially contain the entire history of the repository? The history could easily contain sensitive information like passwords. It will contain names email addresses of contributors, too. Try it yourself: cat .git/logs/HEAD
- deleted 13y ago[deleted]
- tokenizerrr 13y agoWhy would it contain passwords?
- maw 13y agoSome people are naïve. All people make mistakes. And many people are naïve about whether they make mistakes.
- lucaspiller 13y agoThe history could. If you ever stored passwords in Git, even if you have now removed them, they would still be in the history.
- siddboots 13y agoLuckily, you can use git to rewrite history. http://git-scm.com/book/ch6-4.html http://git-scm.com/book/ch6-4.html
- 13y ago
- wldlyinaccurate 13y agoI recently discovered that I had been serving .git on my blog for a couple of years. All it took to fix was a simple rule in my Nginx config: # Don't expose hidden files to the web location ~ /\. { return 404; }
- jaxbot 13y agodeny all; works too
- thejosh 13y agoYep. It's good practice to disallow . files because one time you may forget you put one there.
- fohlin 13y agoThough, keep in mind the potential conflict with /.well-known/ - <http://tools.ietf.org/html/rfc5785> http://tools.ietf.org/html/rfc5785>.
- hafabnew 13y agoThis isn't the best solution. Instead do as others have suggested and make a subdirectory of your project the webserver root. This solutions just stops nginx (/whatever web server you're using) from displaying the file. If someone finds a remote-file inclusion vulnerability in your app, in all likelihood they can use said vulnerability to browse your .git directory -- because, hey, it's in your webserver directory, so the permissions are almost certainly set up so whatever user the webserver is running as (www-data probably/hopefully) can view it! (Obviously if your webserver user can view important files such as these elsewhere on the system, you're still screwed -- but reducing attack surface, etc etc.)
- alcat 13y agoI make it a habit to put all my public files in directory such as www/, where as .git and other non public but site-related files/directories are contained above this.
- dan15 13y agoIMO this is the correct approach - Exposing every single file in the repository (including files that don't need to be public) sounds terrible.
- drivebyacct2 13y agoYes. I mean, even 6 year old PHP articles get this right, don't serve files from the same place your executing code is running from. public_html has specific connotations for a reason.
- peterjmag 13y agoFor simple static sites, I use a workflow very similar to this one[1]. It takes a minute or two to set up, but once it's all configured, you can deploy to your heart's content without ever worrying about exposing your .git directory to the world. [1] http://toroid.org/ams/git-website-howto http://toroid.org/ams/git-website-howto
- astrodust 13y agoNo. Not this. index.html has no business being in the root of your project. Always, and I mean always put your web content into a directory separate from the root of your .git archive. This is the easiest way to avoid all of these problems. Rails calls this directory "public", but it could be whatever you want, so long as what's mounted on your web server is not the root.
- devmach 13y ago* Any folder in your project can have index.html and indeed it should have. * Parent talks about static pages, not about rails-ruby/php/python project. But i get your point : If somehow somebody screw with servers config, there is a risk to expose your apps files & configs. You can follow parents advice but set your root path in apache/nginx config to /var/www/www.example.org/public instead of /var/www/www.example.org
- astrodust 13y agoEven a static site can be structured so that the .git directory is outside of the main public mount. This gives you a natural place to store notes, documentation, and other non-public content. It's not about screwing with the server config, it's so that it takes several stupid mistakes before your .git folder is flapping in the breeze, not just one. Being one configuration directive away from embarrassing failure is not a good idea.
- rlx0x 13y ago> Being one configuration directive away from embarrassing failure is not a good idea. I can't stop but thinking about PHP webapps, for instance Wordpress serves wp-index.php in the same directory as wp-config.php, indeed only one configuration directive away from blowing it all up in your face. Every few months or so I encounter a huge site that serves me PHP source code. For instance the BBC: http://www.bbc.co.uk/radio4/hitchhikers/zmachine/hhguide.xml http://www.bbc.co.uk/radio4/hitchhikers/zmachine/hhguide.xml But hey its PHP I guess anyone who would care about something like that has stopped using it years ago.
- dan15 13y ago.git should never be in your web root... I can't think of any situation (other than a very simple site) where you'd want to just stick the whole Git repository in the web root. Normally there's a bunch of other things in the repository (documentation, database scripts, etc.) that you wouldn't want exposed publicly.
- dsirijus 13y agoYou can hide it very easily with any of the virtual host syntax, and it's easy to deploy that way. I say, why not.
- kcbanner 13y agoBecause of all the reasons parent mentioned.
- StavrosK 13y agoYou should do both, though.
- brown9-2 13y agoYou could also very easily add one additional command to your deploy script to copy all the web content from the directory being pulled to to the web root, and not have to worry about any accidents.
- astrodust 13y agoOr you could set the web root to be that directory.
- dan15 13y agoHiding it is riskier than just not having it there in the first place. Why blacklist when you can whitelist?
- trapezor 13y agoThis is clearly Ops problem.
- rlpb 13y agoYou can keep the same workflow but just have .git somewhere else. Just define GIT_DIR.
- contingencies 13y agoOK, so I knew about this one before. But if you didn't, there's a better solution than just remembering it, which seems to be the gist of this post. Solution: run one or more automated security tools across your sites, before deploying them to public locations. If possible, automate this process, so it happens all the time. The tools won't catch everything, but they will catch something you didn't, some of the time. Testing is good practice with all software! Do it.
- koyote 13y agoCan you recommend a couple of good automated security tools?
- contingencies 13y agohttp://w3af.org/ http://w3af.org/ http://www.arachni-scanner.com/ http://www.arachni-scanner.com/ http://www.openvas.org/ http://www.openvas.org/ https://code.google.com/p/skipfish/ https://code.google.com/p/skipfish/
- lemonade 13y agoVery useful list. None of these have anything running as a service you can try out easily, I guess that would be a Bad Idea anyway as this kind of tools might either accidentally cause stuff to happen to a server, or be used as part of an attack. I guess script youngsters will not be very much deterred by having to install e.g. a python or ruby library - but any lazy bum that drops the idea to scan some elses site is a win.
- lemonade 13y agoVery useful list. None of these have anything running as a service you can try out easily, I guess that would be a Bad Idea anyway as this kind of tools might either accidentally cause stuff to happen to a server, or be used as part of an attack. I guess script youngsters will not be very much deterred by having to install e.g. a python or ruby library - but any lazy bum that drops the idea to scan some elses site is a win.
- marijn 13y agoThis is too much of blanket statement. As long as there's nothing secret in the repository, serving up .git is perfectly fine. Both http://codemirror.net http://codemirror.net and http://ternjs.net http://ternjs.net (projects by me) have websites that are simply checkouts of the projects' repositories. Which were already public.
- _wmd 13y agoThis is pretty much a blanket statement for any project of reasonable size (or even with just a sole clueless developer). But don't take my word for it, check the evidence first hand by poking around the list for yourself :) The solution is so effortless that it seems indefensible to serve .git, when the risk of doing so is a fleeting moment of forgetfulness leading to your site and databases getting pwned. Kind of like /etc/passwd being "public" so long as nobody puts their password in their GECOS field. Why take the risk.
- apendleton 13y agoNo, it really isn't a blanket statement. Almost all of my organization's web properties are public github repos (yay, non-profit organizations!). I doubt any of our properties serve .git, but that's just for technical architecture reasons (they're mostly Django apps), and there's literally nothing in the .git directories that isn't already available for free.
- marijn 13y agoThe repository is already public. It can't get any more public by being exposed over the website.
- tingletech 13y agoBack in the 90s I found I could get to /etc/passwd of a campus machine via anonymous ftp. I got all worried and I reported to the sysadmin, and they said anyone of the thousands of students who could log into the machine could read /etc/passwd anyway, and it was not a big deal because the passwords were in /etc/shadow and the anonymous ftp user could not read that file. This was back before ssh, and I think I expressed a concern about people knowing who had accounts on the machine, but you could tell if someone had an account via finger. Still seems like a bad idea to me. But if .git is from a public repo on github already I don't see the issue.
- tlongren 13y agohttp://www.fcc.gov/.git/config http://www.fcc.gov/.git/config FCC has a github account. http://www.fcc.gov/.git/logs/HEAD http://www.fcc.gov/.git/logs/HEAD
- kumar303 13y agoor, to put it another way, please stop writing closed source software ;)
- scubbo 13y agoI feel incredible stupid asking this, but...how? I'm running a (very small) personal site on lighttpd, and updating it via git. I checked my.server.com/.git/config - and was duly served the config file. Eek! So I edited my /var/www/lighttpd/lighttpd.conf file, and added the following lines: $HTTP["url"] =~ ".git" { url.access-deny = ("") } and (I have used [asterisk] for the symbol, here, as otherwise it rendered my text italic) $HTTP["host"] =~ "(.[asterisk])" { url.redirect = ( "^/.git(.*)" => "%1/nope.html" ) } And restarted the server. But my.server.com/.git/config still served up the config file. What am I missing?
- dalore 13y agoAnother way would be to only deploy releases to your server and not have the .git directory at all. Look at git archive.
- fallenhitokiri 13y agoInstead of messing around with access and redirect stuff I would suggest, as others have in this thread, that you just put your files in a subdirectory and use this subdirectory as root for lighttpd. Problem solved with two commands and you can also add additional stuff to your repository like sources before they went through different processors (coffee script, SASS,...) or various drafts. This way you also have a full copy of everything you need for your site in case something happens to your workstation.
- scubbo 13y agoSo, instead of having: .git some_page.html some_css.css You would advocate: .git web_docs/some_page.html web_docs/some_css.css ? Makes sense. It will require some reorganisation, but it seems (from everyone's comments) to be best practice. Thanks! (Still kinda bugs me that I can't work out how to prevent lighttpd from serving individual files, though!)
- scubbo 13y agoOK, now I'm REALLY confused. I've moved all my documents from /var/www/lighttpd/mainSite to /var/www/lighttpd/mainSite/webdocs (leaving .git in .../mainSite). I've updated /etc/lighttpd/lighttpd.conf to point at /var/www/lighttpd/mainSite/webdocs, and confirmed that it's pointing at the right place by editing a file, and confirming that that change shows up on the site. I've confirmed that there is no .git folder in webdocs (you never know!) But calling my.site.com/.git/config still serves a file!? Time to go ask on some lighttpd fora...
- binarydreams 13y agoJust keep the .git bare repo outside the document root.
- level09 13y agoI used to restrict that globally in my nginx / apache configurations (since I mainly work with these two web servers).
- kpommerenke 13y agoSame problem with subversion. Try http://yoursite/.svn/entries http://yoursite/.svn/entries If you use Apache, you can add the following to prevent the .svn directories from being served: <LocationMatch ".\.svn."> Order allow,deny Deny from all </LocationMatch
- michaelmior 13y agoI just push to a repo out of the web root that has a git hook which sets GIT_WORK_TREE to my web root and does a checkout.
- deleted 13y ago[deleted]
- andrewflnr 13y agoIn a word: Rsync. What I do is have source files in one directory, filter them over to another with, at the moment, jinja2, then rsync that to my server using a shortcut script. The filtering is the tricky part.
- coolj 13y agoDefcon 19: Adam Baldwin - Pillaging DVCS Repos For Fun And Profit: https://www.youtube.com/watch?v=3Tq8tUDKUH0 https://www.youtube.com/watch?v=3Tq8tUDKUH0