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

151–160 of 214 posts

Re: One in every 600 websites has .git exposed

#151

Post by skarap »

jasonkester wrote: post #147

I see a lot of discussion here about best practices to avoid this, but nothing about the obvious question: Why is it that the go to version control system for developers everywhere is designed such that there it puts a single file at the root that magically gives anybody that can see it the ability to download all the source code in the repository? That is: - completely non-obvious and unexpected - a terrible idea Wh…

And how would you expect it to work? Keep the repo in ~/.local/ or something like AppData? What happens then if you want to have two clones of the same repo? What if you want to move a clone around (e.g. to a different machine)? Of course it's possible to find solutions to these issues, but they will never be as simple and easy to use as the current model (btw: git supports having the magic directory external to the working tree).

It's non-obvious and unexpected if you have never used a VCS and didn't read a single page describing git. In which case almost everything in git will be unexpected and non-obvious (so will be any programming language or technology).

But I agree that the problem shouldn't be trying to avoid handling out the .git dir to everybody. The problem is - git clone in document root of the webserver for website deployment is a terrible idea and was never a supported usecase.

edit: so I came the third! Should try typing quicker.

Re: One in every 600 websites has .git exposed

#152

Post by capsule_toy »

jasonkester wrote: post #147

I see a lot of discussion here about best practices to avoid this, but nothing about the obvious question: Why is it that the go to version control system for developers everywhere is designed such that there it puts a single file at the root that magically gives anybody that can see it the ability to download all the source code in the repository? That is: - completely non-obvious and unexpected - a terrible idea Wh…

It's actually not a problem for many web developers. If you're working in Rails, Django, etc., you're not going to have the DOCROOT pointed at your top level directory. And .git is only in the top level directory, which is already an improvement over .svn.

But let's say we agree it's an issue and should be fixed. What alternative solution would you propose? You can't just get rid of the "magic file" because it actually contains your version history, the thing you wanted to track in the first place.

Re: One in every 600 websites has .git exposed

#153

Post by beagle3 »

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…

> (--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)

That's not true (though not completely wrong).

rsync is stateless. It does not assume the version on the remote machine is "exactly how you left it"; Rather, it compares file size and file modification time; if either changed, it will do a transfer -- efficient delta transfer, usually - which might be as little as 6 bytes if the contents is exactly the same.

--checksum makes it ignore file size or modification time, and compare the file checksum in order to decide if it's time for a transfer (delta or not).

A malicious actor, or bad memory chips, might change your file's contents, but keep the file size and time/date the same. In that case, --checksum will overwrite that file with your source version, and a --no-checksum wouldn't. So it's not bad advice. Whether the cost in disk activity is worth it depends on your thread model, data size, and disk activity costs. (Though, if corruption is due to bad memory, this is the least of your problems)

However, a corruption because of a program error / incompetent edit to the file is very unlikely to leave both the size and modification date intact - and a standard rsync will figure that out as well.

Re: One in every 600 websites has .git exposed

#154

Post by rurounijones »

chei0aiV wrote: post #135
nmalaguti wrote: post #3

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?

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! https://enricozini.org/2014/debian/debops/

I would dispute the idea that packaging your web-app (which is what the article is talking about) into a .deb or .rpm is a standard practice.

Re: One in every 600 websites has .git exposed

#155

Post by kilotaras »

aaronbrethorst wrote: post #2

I 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?

https://news.ycombinator.com/item?id=838981 - similar breach was reported in 2009. It focused on .ru part of internet and got a bunch of big names.

Re: One in every 600 websites has .git exposed

#156

Post by tokenizerrr »

jsjohnst wrote: post #120
tokenizerrr wrote: post #73

Earlier quoted context omitted.

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.

Glad I don't work at your shop then. Environment variables are a terrible way to give your app secure information. There's well over a dozen reasons why you shouldn't do this in your apps, but one super obvious one is there's way to many frameworks that expose environment variables in their debug output if not properly configured. Think you'll never misconfigure a server? Guess again, pretty much every major site (Go…

Please review HN's guidelines on civility.

Re: One in every 600 websites has .git exposed

#157

Post by svisser »

jasonkester wrote: post #147

I see a lot of discussion here about best practices to avoid this, but nothing about the obvious question: Why is it that the go to version control system for developers everywhere is designed such that there it puts a single file at the root that magically gives anybody that can see it the ability to download all the source code in the repository? That is: - completely non-obvious and unexpected - a terrible idea Wh…

The design of the version control system is not the problem here, is it?

Re: One in every 600 websites has .git exposed

#158

Post by juliangregorian »

vog wrote: post #145
phantom_oracle wrote: post #30

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…

You seem to imply this is a novel attack vector. But it's really just an instance of a very old mistake: Don't use the root of your app as document root! It's really as simple as that. Almost all modern apps have a subdirectory "public/" or similar. That one is meant to be used as document root. You only have to ensure there are no sensitive files in there . If you fail to introduce such a directory, you'll have a ga…

Great point. How much do you want to bet most of these are PHP, where it takes special discipline not to make your top directory web-accessible?

Re: One in every 600 websites has .git exposed

#159

Post by quicksilver03 »

Some of the other commenters suggest adding git-dir and work-tree to the git commands, but there's a better solution: use the --separate-git-dir option when cloning the repository.

For example:

    git clone --separate-git-dir=
where is outside of any directory served by the web server and is the htdocs root.

This option makes /.git a file whose content is:

    gitdir:
The advantage is that all git commands work as usual, without the need to set git-dir and work-tree, and that there's nothing special to add to the web server configuration.

Re: One in every 600 websites has .git exposed

#160

Post by zimbatm »

Imagine you find a typo or bug on some site that you use daily and it really annoys you. How awesome would it be able to just `git clone http://www.microsoft.com/`, fix the issue and then either host your own version of the site or submit a pull-request. Seems like it's already possible on 600 websites :) (well they probably didn't run `git update-server-info` ).
Post reply on HN