17 ms·

Don't publicly expose .git (2015)

156 points by g4k 9y ago

jldugger 9y ago
> Bad people can use tools to download/restore the repository to gain access to your website’s sourcecode. So if I post my website's sourcecode on github, I'm equally vulnerable? I could see problems if said checkout contained a credential cache, but that doesn't seem to be mentioned.
- floatingatoll 9y ago
  Yes. It's not necessarily a problem, but it's a risk to consider carefully at licensing time.
- azag0 9y ago
  This is the old security via obscurity. At least though, one should know that one publishes the full source.
- Izmaki 9y ago
  If you post your source code to github you know it will be public, and might remember to remove passwords from debug code etc., however if you expect it to be private, while it's not, you might be lazy and store passwords in plaintext in the code. A horrible thought for a programmer, yes, but human beings are lazy.
- _wmd 9y ago
  git clone https://username:password@github.com/.. https://username:password@github.com/... will end up in git reflog, so yes, it's a problem, and there's no guarantee a future feature of Git that you've never heard of doesn't make the problem worse
  - falsedan 9y ago
    reflog is local though
    - _wmd 9y ago
      http://your.broken.site/.git/logs/HEAD http://your.broken.site/.git/logs/HEAD
      - falsedan 9y ago
        I don't understand. Do you mean, the remote also has a reflog? It sure does, it's local to the repository! But entries recorded in my reflog are not pushed to or fetched from any remote I interact with. Instead, their reflog is updated when I push (to record that my commits were accepted & their branches/tags changed), and my reflog is updated when I fetch (to record that their commits were accepted & my branches/tags changed).
        _wmd 9y ago
        And what happens when Ansible checks out the Git repository for you? Or some equivalent shell script or deployment system, or some helpful developer hand-deploying something with 'git clone' on the server? Or what about helpful developer that checked in some secrets which are visible in the repository history but not the current checkout? Or that stupid PHP thing where 'config.php' and its MySQL passwords are world-readable, but rely on the web server interpreting it as a PHP script due to its file extension to prevent secret leaks.. not so valid when a copy of the script if available as ".git/objects/00/cf74f2066b0c72a4c4b2a24ef116f1fd23df42". But of course, even if these weren't problems, the original point still stands: there is no guarantee .git doesn't contain secret data (such as username:password) either now, or into the future, so exposing it is a bad idea. https://en.wikipedia.org/wiki/Principle_of_least_privilege https://en.wikipedia.org/wiki/Principle_of_least_privilege
        falsedan 9y ago
        That's too much commentary for me to extract from a single fake link to an NXDOMAIN. > there is no guarantee .git doesn't contain secret data (such as username:password) either now, or into the future, so exposing it is a bad idea. The same can be said of the HTML and images, so I don't find it a useful heuristic. Note that I was disputing your claim that a username+password used to fetch a repo over http would leak into the remote's reflog.
  - jldugger 9y ago
    > git clone https://username:password@github.com/.. https://username:password@github.com/... will end up in git reflog So if your deploy process is an anonymous git checkout of Drupal, there's no credential leaking to worry about. > no guarantee a future feature of Git that you've never heard of doesn't make the problem worse Okay.
cyphar 9y ago
An interesting thing to note is that .pack files give you some safety against this sort of disclosure. Bare git objects are very easy to access even with indexes disabled because their name is their hash (and so if you have access to the index or the current HEAD you can recreate the history). Pack files contain multiple objects, but their name is computed from a hash of the packed objects. This makes it quite difficult to figure out the path to the pack file (you have to brute force the entire history and how it was packed in order to get a single .pack file's worth of data). Not that you should have .git exposed on your public webserver anyway. I do remember participating in a CTF that had a problem like this a few years ago, it's possible that it was the same one the author mentioned.
- duskwuff 9y ago
  Not safe, just slightly more obscure. The .pack files are listed in .git/objects/info/packs.
  - cyphar 9y ago
    Ah, that makes sense. I probably should've thought about it a bit more, because if there wasn't mapping from object -> pack then git wouldn't be able to quickly look up objects in packfiles.
  - jwilk 9y ago
    According to https://github.com/kost/dvcs-ripper/issues/6#issuecomment-117952742 https://github.com/kost/dvcs-ripper/issues/6#issuecomment-11... , .git/objects/info/packs is not reliable.
kleinsch 9y ago
I feel like whenever possible, the answer is to stop storing sensitive information in source control. That solves a whole class of problems, including this one. If your history has sensitive info, see about rewriting the history. If that's not possible, maybe fork the repo, remove the sensitive info, and get the team to switch to the fork. If that's not possible either, make the sensitive info meaningless (reset your DB passwork, revoke the API tokens, etc).
- asattarmd 9y ago
  Source Code is the sensitive information that he's talking about in the article.
  - WorldMaker 9y ago
    If you've got a static site hostable in htdocs directly, then that "sensitive source code" is also accessible in browser dev tools and View Source menus.
- Izmaki 9y ago
  Even without passwords, just knowing the infrastructure of the target system is candy for a hacker.
  - eropple 9y ago
    This is really true only if you're ascribing to the perimeter model of security rather than defense-in-depth, though. If your systems are (properly, to my mind) constructed, knowing what your infrastructure looks like doesn't provide significant value. That obscurity becomes a nice-to-have, rather than an essential, aspect of your security. (When building systems for clients, this is something I stress. "We should be operating as if it is assumed that an attacker has a VPN into your network space and has nmapped all your stuff.")
    - majewsky 9y ago
      Counterpoint: Knowledge of the infrastructure can be used in social engineering attacks, e.g. to increase the likelihood of success for password spearphishing.
Hamcha 9y ago
I don't like the advice he gives on just denying access to .git. I think the idea of cloning the repo in the htdocs folder is just wrong. A much better approach (or at least, what I use) would be to set up the repo somewhere private with --bare and set a receive hook to checkout HEAD to the htdocs folder, this way the htdocs only has the content and you get the extra feature that you can sneak extra commands on the checked out source (such as building/minifying) without changing the original source
- bananaboy 9y ago
  Yeah this sounds like a much better idea. You could also do a shallow clone (for performance and so you don't have the full history there).
- ljoshua 9y ago
  This sounds like an awesome approach. Do you have any resources you could share on a few of the details? Using --bare I get, but I've not yet played with hooks and such.
  - jdwithit 9y ago
    Git hooks are just arbitrary scripts. They need to exist in a specific location, and accept certain arguments depending on when in the lifecycle they are meant to execute. But they can be written to do basically anything. From linting and syntax checking, to complex deploy behaviors. http://githooks.com/ http://githooks.com/
- glandium 9y ago
  It's actually kind of mentioned at the end of the article: > Another approach is to use git’s --git-dir and --work-tree switches to move the git repository out of the document root. Yet another option is to make the htdocs directory a worktree of the git repository, which doesn't require passing flags around, or setting environment variables. Technically, this still leaves a .git, but it's only a file containing the actual location to the real .git directory. https://git-scm.com/docs/git-worktree https://git-scm.com/docs/git-worktree
eliq 9y ago
Isn't this a non issue (don't need to change any config to block .git) with a properly configured firewall and nginx proxy passing to localhost when the code does not live in a publicly visible location? Eg- https://www.digitalocean.com/community/tutorials/how-to-set-up-django-with-postgres-nginx-and-gunicorn-on-ubuntu-16-04 https://www.digitalocean.com/community/tutorials/how-to-set-...
- bluetooth 9y ago
  Are you asking if this is a non-issue if you've... addressed the issue?
  - eliq 9y ago
    You could have worded it a little differently: if a folder is not accessible in the root directory of the web server, there is no need to modify the web server config to deny access to .git. These type of snarky responses discourage newcomers to participate in discussions. I have seen this happen to many people, so please dial back the snark.
    - lucb1e 9y ago
      I see where you're coming from. From what I understand you're suggesting the same thing as Hamcha, who currently has the top post: make the web root a subfolder in version control, so the version control folder is above the web root. However, when I read it, it sounded like "if you have some uncommon setup with proxying to localhost [and then filtering out requests to .git?]" which indeed sounds like addressing the issue. Your second comment clarifies what you mean.
- aptwebapps 9y ago
  It's an issue, just not really specific to git and has been around for a long time. The issue is having source files or any sensitive info, under the web root where it could get exposed by an incorrectly configured web server. This is why modern setups keep the source code somewhere else and use some sort of application server behind the web server or similar arrangement.
partycoder 9y ago
If the .git folder is exposed, you can download it, then do "git checkout" in that folder and get the full working copy.
- Spivak 9y ago
  Just like anyone can go to Github, Gitlab, Bitbucket, etc. and get a full working copy. If your code is public then what does it matter? If it's not then you should be protecting it like any other sensitive information.
  - partycoder 9y ago
    You make the assumption that code is public and in a git hosted service. Neither of those are necessarily the case. You can unintentionally expose your repository by deploying .git by mistake.
  - vultour 9y ago
    Who said the code was public?
mioelnir 9y ago
If I remember my Apache config right, the two examples are switched. The 2.4 config should be 'Require all denied' and the 'Order deny,allow' the old 2.2 syntax.
- gehaxelt 9y ago
  Hi, I just rechecked with [1] and you seem to be right. I'll update the blogpost in a second. Thanks for the hint! [1] https://httpd.apache.org/docs/current/upgrading.html https://httpd.apache.org/docs/current/upgrading.html
libeclipse 9y ago
The author fails to acknowledge a scenario where you wouldn't care, or where you'd even actively want your source code to be public. For example, static websites for open source projects, et al.
- codezero 9y ago
  I think they did... > It seemed like an accessible git repository was intended on some websites - mostly open source projects where the website’s sourcecode is available online.
  - ubernostrum 9y ago
    Every so often, the Django security address gets an email from someone who wants to claim bug-bounty money because "Dear Django team, I have discovered source-code disclosure vulnerability in your web site..."
- xg15 9y ago
  Even then though, they should be aware of the meta data that's stored in the repo and make sure it's appropriately sanitized. > On the other side, we had to hold our breath when we noticed that more than 100 projects used HTTP-Authentication for server-client communication. That means, that the protocol://user:password@host/repository combination is saved in the .git/config file, giving attackers access to the users (companies) GitLab-instance or GitHub/BitBucket account. With a bit of luck an attacker gets access to the CI-Server and then runs malicious code to further compromise your infrastructure.
concede_pluto 9y ago
> When deploying a web application, some administrators simply clone the repository. Step one: stop randomly smearing crap around. Prod should only have files that came from a .deb or .rpm signed by the legit build process, because that's how you know your system is reproducible and has everything it should and nothing else.
- marcosdumay 9y ago
  And then you moved the problem from keeping your files in sync on the web server to keeping your files in sync on the package source.
  - stephenr 9y ago
    Building debs and rpms from version control is a legitimate step though.
  - eropple 9y ago
    That's a significantly more straightforward and safer problem to have to handle. You should prefer it across-the-board.
    - marcosdumay 9y ago
      That's the exactly same problem, with the exactly same failure modes and consequences on failure. It's also solved the exact same ways, by scripting your stuff on one level or another.
      - eropple 9y ago
        Solving the problem in one place (your CI/CD server) is a significantly less complex a task than solving it in N places (every server on which your application is running). It removes the concerns around configuration drift (have all your machines been properly brought up to policy?) and enables easier reasoning about the whole thing.
- jdwithit 9y ago
mercora 9y ago
It is possible to separate the work tree from the git repository files with the "--separate-git-dir" flag. .git is then a file whose contents point to the directory where the repository files reside. Any other command works as usual without specifying the directory, so it is just needed for clone or init.
gonyea 9y ago
No, you need to delete the .git folder from your server entirely. Ideally, delete it before you deploy. In fact, don't even put a github deploy key on the server. Deploy binaries. And don't just stop with .git: Delete any folder/file that's not required to operate the app in production.
- evincarofautumn 9y ago
  Yup. I used to host .git on a server but it ended up being more complication than it was really worth. Now I just have a “deploy” script that uses sftp to push all the build artifacts (and nothing else) to the server.
  - Silhouette 9y ago
    Now I just have a “deploy” script that uses sftp to push all the build artifacts (and nothing else) to the server. We do something similar. "Clean and minimal" is a good strategy when you're deploying assets to publicly accessible systems.
auscompgeek 9y ago
> A tool to discover, one to download and one to extract git repositories. Hasn't dvcs-ripper [1] been around for longer? It supports other VCSes as well. Also, the article fails to mention that a simple `git clone` would usually work as well, although that tends to be blocked in similar CTF challenges. [1] https://github.com/kost/dvcs-ripper https://github.com/kost/dvcs-ripper
- gehaxelt 9y ago
  Hi, one of the authors here. I knew about dvcs-ripper, but thought that implementing another variant might be fun and let me learn about git internals. Does a simple `git clone` really work? I just tested it and it failed: ``` $> git clone http://x.domain.tld/ http://x.domain.tld/ fatal: repository 'http://x.domain.tld/' http://x.domain.tld/' not found $> git clone http://x.domain.tld/.git/ http://x.domain.tld/.git/ fatal: repository 'http://x.domain.tld/.git/' http://x.domain.tld/.git/' not found ``` And yes, the post's background is a CTF challenge that blocked a simple `git clone`.
  - bitwave 9y ago
    I remember, that it was the 9447 ctf in 2014. The challenges were bashful and tumorous. See: https://github.com/ctfs/write-ups-2014/tree/master/9447-ctf-2014/bashful https://github.com/ctfs/write-ups-2014/tree/master/9447-ctf-...
- rurban 9y ago
  Since about 2012: https://k0st.wordpress.com/2012/10/23/rip-or-pillage-dvcs-story-about-git/ https://k0st.wordpress.com/2012/10/23/rip-or-pillage-dvcs-st... Parts are even in metasploit.
andersonmvd 9y ago
".git" is only one of many checks performed by Nikto (an open source security scanner - https://cirt.net/Nikto2 https://cirt.net/Nikto2), but there are other checks and many other scanners. shameless plug: I've developed a service that you run to check against vulnerabilities in your apps/servers and it has a free plan (https://my.gauntlet.io/registration.html https://my.gauntlet.io/registration.html) in case you're interested (https://gauntlet.io https://gauntlet.io).
- 616c 9y ago
  Is this just hosted nikto2? It sounds very cool. Do you distribute against different cloud systems? I know you're a pro from the site address but I'd be worried about quick blacklisting; I'm sure you're effective.
  - andersonmvd 9y ago
    Not only nikto2, but other scanners (https://gauntlet.io/en/product/supported-scanners/ https://gauntlet.io/en/product/supported-scanners/) as well. It comes with open source installed, but integrate with commercial too. Currently each scan triggers a new virtual machine - thus a new IP Address and all applications need to be verified prior to execute a scan (e.g., Google Analytics require metatag, file upload or dns record).
Kenji 9y ago
If someone being able to download your source code repository is opening yourself up to attacks, you're doing something wrong. Either you are relying on security through obscurity, or you checked keys into git. Both horrible practices.
- vultour 9y ago
  Do you give everyone complete access to your production code?
  - kuschku 9y ago
    Yes? It’s under GPL, after all.
- falsedan 9y ago
  > you checked keys into git. Both horrible practices. Hey! That's not very kind to disparage everyone using a text file in a git repo to manage their passwords/keys. Putting keys into a git repo is fine! But be careful when publishing that repo, as something you thought was private could suddenly become public.
  - zandor 9y ago
    It still is a pretty bad practice though.
    - falsedan 9y ago
      I would do it, if I was certain I could avoid accidentally publishing the repo. I'd never describe it as 'bad', as that's extremist & it's easy for someone who does this to misinterpret you as saying, "you are bad for doing this and not following best practices".
gehaxelt 9y ago
Hello HN, here's one of the blogpost's authors. Although it has been a while since we published the blogpost, I'll try to answer any questions or listen to any suggestions.
- dmitrij 9y ago
  https://news.ycombinator.com/item?id=14534499 https://news.ycombinator.com/item?id=14534499
wooptoo 9y ago
For nginx: # deny access to HG and Git repositories location ~ /\.(hg|git)/ { deny all; }
- kchr 9y ago
  Doesn't solve the issue of the data being available on a public server, though. Any piece of code run by the web server would most likely have access to those directories, as well as any other static content in the web root...
fergie 9y ago
The real solution to this problem is to reference passwords, tokens, keys, or and other "private" strings with environmental variables or external config files, which are then excluded from the source control system. That way your super-secret stuff can never be extracted from git or svn. This approach also has a whole class of additional benefits relating to being able to run a system in different places (for example- setting up dev->test->prod staging servers)
jeisc 9y ago
? Would it not be secure enough to put .git in the directory above the public root: /mysite/.git /mysite/mysiteroot/index.html /mysite/.gitignore /mysite/lib/common
tutufan 9y ago
Rationale for "make install" rediscovered. Film at 11... :-)

156 points by g4k 9y ago

> Bad people can use tools to download/restore the repository to gain access to your website’s sourcecode. So if I post my website's sourcecode on github, I'm equally vulnerable? I could see problems if said checkout contained a credential cache, but that doesn't seem to be mentioned.

floatingatoll 9y ago
Yes. It's not necessarily a problem, but it's a risk to consider carefully at licensing time.
azag0 9y ago
This is the old security via obscurity. At least though, one should know that one publishes the full source.
Izmaki 9y ago
If you post your source code to github you know it will be public, and might remember to remove passwords from debug code etc., however if you expect it to be private, while it's not, you might be lazy and store passwords in plaintext in the code. A horrible thought for a programmer, yes, but human beings are lazy.
_wmd 9y ago
git clone https://username:password@github.com/.. https://username:password@github.com/... will end up in git reflog, so yes, it's a problem, and there's no guarantee a future feature of Git that you've never heard of doesn't make the problem worse
- falsedan 9y ago
  reflog is local though
  - _wmd 9y ago
    http://your.broken.site/.git/logs/HEAD http://your.broken.site/.git/logs/HEAD
    - falsedan 9y ago
      I don't understand. Do you mean, the remote also has a reflog? It sure does, it's local to the repository! But entries recorded in my reflog are not pushed to or fetched from any remote I interact with. Instead, their reflog is updated when I push (to record that my commits were accepted & their branches/tags changed), and my reflog is updated when I fetch (to record that their commits were accepted & my branches/tags changed).
      - _wmd 9y ago
        And what happens when Ansible checks out the Git repository for you? Or some equivalent shell script or deployment system, or some helpful developer hand-deploying something with 'git clone' on the server? Or what about helpful developer that checked in some secrets which are visible in the repository history but not the current checkout? Or that stupid PHP thing where 'config.php' and its MySQL passwords are world-readable, but rely on the web server interpreting it as a PHP script due to its file extension to prevent secret leaks.. not so valid when a copy of the script if available as ".git/objects/00/cf74f2066b0c72a4c4b2a24ef116f1fd23df42". But of course, even if these weren't problems, the original point still stands: there is no guarantee .git doesn't contain secret data (such as username:password) either now, or into the future, so exposing it is a bad idea. https://en.wikipedia.org/wiki/Principle_of_least_privilege https://en.wikipedia.org/wiki/Principle_of_least_privilege
        falsedan 9y ago
        That's too much commentary for me to extract from a single fake link to an NXDOMAIN. > there is no guarantee .git doesn't contain secret data (such as username:password) either now, or into the future, so exposing it is a bad idea. The same can be said of the HTML and images, so I don't find it a useful heuristic. Note that I was disputing your claim that a username+password used to fetch a repo over http would leak into the remote's reflog.
- jldugger 9y ago
  > git clone https://username:password@github.com/.. https://username:password@github.com/... will end up in git reflog So if your deploy process is an anonymous git checkout of Drupal, there's no credential leaking to worry about. > no guarantee a future feature of Git that you've never heard of doesn't make the problem worse Okay.

cyphar 9y ago

An interesting thing to note is that .pack files give you some safety against this sort of disclosure. Bare git objects are very easy to access even with indexes disabled because their name is their hash (and so if you have access to the index or the current HEAD you can recreate the history). Pack files contain multiple objects, but their name is computed from a hash of the packed objects. This makes it quite difficult to figure out the path to the pack file (you have to brute force the entire history and how it was packed in order to get a single .pack file's worth of data). Not that you should have .git exposed on your public webserver anyway. I do remember participating in a CTF that had a problem like this a few years ago, it's possible that it was the same one the author mentioned.

duskwuff 9y ago
Not safe, just slightly more obscure. The .pack files are listed in .git/objects/info/packs.
- cyphar 9y ago
  Ah, that makes sense. I probably should've thought about it a bit more, because if there wasn't mapping from object -> pack then git wouldn't be able to quickly look up objects in packfiles.
- jwilk 9y ago
  According to https://github.com/kost/dvcs-ripper/issues/6#issuecomment-117952742 https://github.com/kost/dvcs-ripper/issues/6#issuecomment-11... , .git/objects/info/packs is not reliable.

kleinsch 9y ago

I feel like whenever possible, the answer is to stop storing sensitive information in source control. That solves a whole class of problems, including this one. If your history has sensitive info, see about rewriting the history. If that's not possible, maybe fork the repo, remove the sensitive info, and get the team to switch to the fork. If that's not possible either, make the sensitive info meaningless (reset your DB passwork, revoke the API tokens, etc).

asattarmd 9y ago
Source Code is the sensitive information that he's talking about in the article.
- WorldMaker 9y ago
  If you've got a static site hostable in htdocs directly, then that "sensitive source code" is also accessible in browser dev tools and View Source menus.
Izmaki 9y ago
Even without passwords, just knowing the infrastructure of the target system is candy for a hacker.
- eropple 9y ago
  This is really true only if you're ascribing to the perimeter model of security rather than defense-in-depth, though. If your systems are (properly, to my mind) constructed, knowing what your infrastructure looks like doesn't provide significant value. That obscurity becomes a nice-to-have, rather than an essential, aspect of your security. (When building systems for clients, this is something I stress. "We should be operating as if it is assumed that an attacker has a VPN into your network space and has nmapped all your stuff.")
  - majewsky 9y ago
    Counterpoint: Knowledge of the infrastructure can be used in social engineering attacks, e.g. to increase the likelihood of success for password spearphishing.

Hamcha 9y ago

I don't like the advice he gives on just denying access to .git. I think the idea of cloning the repo in the htdocs folder is just wrong. A much better approach (or at least, what I use) would be to set up the repo somewhere private with --bare and set a receive hook to checkout HEAD to the htdocs folder, this way the htdocs only has the content and you get the extra feature that you can sneak extra commands on the checked out source (such as building/minifying) without changing the original source

bananaboy 9y ago
Yeah this sounds like a much better idea. You could also do a shallow clone (for performance and so you don't have the full history there).
ljoshua 9y ago
This sounds like an awesome approach. Do you have any resources you could share on a few of the details? Using --bare I get, but I've not yet played with hooks and such.
- jdwithit 9y ago
  Git hooks are just arbitrary scripts. They need to exist in a specific location, and accept certain arguments depending on when in the lifecycle they are meant to execute. But they can be written to do basically anything. From linting and syntax checking, to complex deploy behaviors. http://githooks.com/ http://githooks.com/
glandium 9y ago
It's actually kind of mentioned at the end of the article: > Another approach is to use git’s --git-dir and --work-tree switches to move the git repository out of the document root. Yet another option is to make the htdocs directory a worktree of the git repository, which doesn't require passing flags around, or setting environment variables. Technically, this still leaves a .git, but it's only a file containing the actual location to the real .git directory. https://git-scm.com/docs/git-worktree https://git-scm.com/docs/git-worktree

eliq 9y ago

Isn't this a non issue (don't need to change any config to block .git) with a properly configured firewall and nginx proxy passing to localhost when the code does not live in a publicly visible location? Eg- https://www.digitalocean.com/community/tutorials/how-to-set-up-django-with-postgres-nginx-and-gunicorn-on-ubuntu-16-04 https://www.digitalocean.com/community/tutorials/how-to-set-...

bluetooth 9y ago
Are you asking if this is a non-issue if you've... addressed the issue?
- eliq 9y ago
  You could have worded it a little differently: if a folder is not accessible in the root directory of the web server, there is no need to modify the web server config to deny access to .git. These type of snarky responses discourage newcomers to participate in discussions. I have seen this happen to many people, so please dial back the snark.
  - lucb1e 9y ago
    I see where you're coming from. From what I understand you're suggesting the same thing as Hamcha, who currently has the top post: make the web root a subfolder in version control, so the version control folder is above the web root. However, when I read it, it sounded like "if you have some uncommon setup with proxying to localhost [and then filtering out requests to .git?]" which indeed sounds like addressing the issue. Your second comment clarifies what you mean.
aptwebapps 9y ago
It's an issue, just not really specific to git and has been around for a long time. The issue is having source files or any sensitive info, under the web root where it could get exposed by an incorrectly configured web server. This is why modern setups keep the source code somewhere else and use some sort of application server behind the web server or similar arrangement.

partycoder 9y ago

If the .git folder is exposed, you can download it, then do "git checkout" in that folder and get the full working copy.

Spivak 9y ago
Just like anyone can go to Github, Gitlab, Bitbucket, etc. and get a full working copy. If your code is public then what does it matter? If it's not then you should be protecting it like any other sensitive information.
- partycoder 9y ago
  You make the assumption that code is public and in a git hosted service. Neither of those are necessarily the case. You can unintentionally expose your repository by deploying .git by mistake.
- vultour 9y ago
  Who said the code was public?

mioelnir 9y ago

If I remember my Apache config right, the two examples are switched. The 2.4 config should be 'Require all denied' and the 'Order deny,allow' the old 2.2 syntax.

gehaxelt 9y ago
Hi, I just rechecked with [1] and you seem to be right. I'll update the blogpost in a second. Thanks for the hint! [1] https://httpd.apache.org/docs/current/upgrading.html https://httpd.apache.org/docs/current/upgrading.html

libeclipse 9y ago

The author fails to acknowledge a scenario where you wouldn't care, or where you'd even actively want your source code to be public. For example, static websites for open source projects, et al.

codezero 9y ago
I think they did... > It seemed like an accessible git repository was intended on some websites - mostly open source projects where the website’s sourcecode is available online.
- ubernostrum 9y ago
  Every so often, the Django security address gets an email from someone who wants to claim bug-bounty money because "Dear Django team, I have discovered source-code disclosure vulnerability in your web site..."
xg15 9y ago
Even then though, they should be aware of the meta data that's stored in the repo and make sure it's appropriately sanitized. > On the other side, we had to hold our breath when we noticed that more than 100 projects used HTTP-Authentication for server-client communication. That means, that the protocol://user:password@host/repository combination is saved in the .git/config file, giving attackers access to the users (companies) GitLab-instance or GitHub/BitBucket account. With a bit of luck an attacker gets access to the CI-Server and then runs malicious code to further compromise your infrastructure.

concede_pluto 9y ago

> When deploying a web application, some administrators simply clone the repository. Step one: stop randomly smearing crap around. Prod should only have files that came from a .deb or .rpm signed by the legit build process, because that's how you know your system is reproducible and has everything it should and nothing else.

marcosdumay 9y ago
And then you moved the problem from keeping your files in sync on the web server to keeping your files in sync on the package source.
- stephenr 9y ago
  Building debs and rpms from version control is a legitimate step though.
- eropple 9y ago
  That's a significantly more straightforward and safer problem to have to handle. You should prefer it across-the-board.
  - marcosdumay 9y ago
    That's the exactly same problem, with the exactly same failure modes and consequences on failure. It's also solved the exact same ways, by scripting your stuff on one level or another.
    - eropple 9y ago
      Solving the problem in one place (your CI/CD server) is a significantly less complex a task than solving it in N places (every server on which your application is running). It removes the concerns around configuration drift (have all your machines been properly brought up to policy?) and enables easier reasoning about the whole thing.
jdwithit 9y ago

mercora 9y ago

It is possible to separate the work tree from the git repository files with the "--separate-git-dir" flag. .git is then a file whose contents point to the directory where the repository files reside. Any other command works as usual without specifying the directory, so it is just needed for clone or init.

gonyea 9y ago

No, you need to delete the .git folder from your server entirely. Ideally, delete it before you deploy. In fact, don't even put a github deploy key on the server. Deploy binaries. And don't just stop with .git: Delete any folder/file that's not required to operate the app in production.

evincarofautumn 9y ago
Yup. I used to host .git on a server but it ended up being more complication than it was really worth. Now I just have a “deploy” script that uses sftp to push all the build artifacts (and nothing else) to the server.
- Silhouette 9y ago
  Now I just have a “deploy” script that uses sftp to push all the build artifacts (and nothing else) to the server. We do something similar. "Clean and minimal" is a good strategy when you're deploying assets to publicly accessible systems.

auscompgeek 9y ago

> A tool to discover, one to download and one to extract git repositories. Hasn't dvcs-ripper [1] been around for longer? It supports other VCSes as well. Also, the article fails to mention that a simple `git clone` would usually work as well, although that tends to be blocked in similar CTF challenges. [1] https://github.com/kost/dvcs-ripper https://github.com/kost/dvcs-ripper

gehaxelt 9y ago
Hi, one of the authors here. I knew about dvcs-ripper, but thought that implementing another variant might be fun and let me learn about git internals. Does a simple `git clone` really work? I just tested it and it failed: ``` $> git clone http://x.domain.tld/ http://x.domain.tld/ fatal: repository 'http://x.domain.tld/' http://x.domain.tld/' not found $> git clone http://x.domain.tld/.git/ http://x.domain.tld/.git/ fatal: repository 'http://x.domain.tld/.git/' http://x.domain.tld/.git/' not found ``` And yes, the post's background is a CTF challenge that blocked a simple `git clone`.
- bitwave 9y ago
  I remember, that it was the 9447 ctf in 2014. The challenges were bashful and tumorous. See: https://github.com/ctfs/write-ups-2014/tree/master/9447-ctf-2014/bashful https://github.com/ctfs/write-ups-2014/tree/master/9447-ctf-...
rurban 9y ago
Since about 2012: https://k0st.wordpress.com/2012/10/23/rip-or-pillage-dvcs-story-about-git/ https://k0st.wordpress.com/2012/10/23/rip-or-pillage-dvcs-st... Parts are even in metasploit.

andersonmvd 9y ago

".git" is only one of many checks performed by Nikto (an open source security scanner - https://cirt.net/Nikto2 https://cirt.net/Nikto2), but there are other checks and many other scanners. shameless plug: I've developed a service that you run to check against vulnerabilities in your apps/servers and it has a free plan (https://my.gauntlet.io/registration.html https://my.gauntlet.io/registration.html) in case you're interested (https://gauntlet.io https://gauntlet.io).

616c 9y ago
Is this just hosted nikto2? It sounds very cool. Do you distribute against different cloud systems? I know you're a pro from the site address but I'd be worried about quick blacklisting; I'm sure you're effective.
- andersonmvd 9y ago
  Not only nikto2, but other scanners (https://gauntlet.io/en/product/supported-scanners/ https://gauntlet.io/en/product/supported-scanners/) as well. It comes with open source installed, but integrate with commercial too. Currently each scan triggers a new virtual machine - thus a new IP Address and all applications need to be verified prior to execute a scan (e.g., Google Analytics require metatag, file upload or dns record).

Kenji 9y ago

If someone being able to download your source code repository is opening yourself up to attacks, you're doing something wrong. Either you are relying on security through obscurity, or you checked keys into git. Both horrible practices.

vultour 9y ago
Do you give everyone complete access to your production code?
- kuschku 9y ago
  Yes? It’s under GPL, after all.
falsedan 9y ago
> you checked keys into git. Both horrible practices. Hey! That's not very kind to disparage everyone using a text file in a git repo to manage their passwords/keys. Putting keys into a git repo is fine! But be careful when publishing that repo, as something you thought was private could suddenly become public.
- zandor 9y ago
  It still is a pretty bad practice though.
  - falsedan 9y ago
    I would do it, if I was certain I could avoid accidentally publishing the repo. I'd never describe it as 'bad', as that's extremist & it's easy for someone who does this to misinterpret you as saying, "you are bad for doing this and not following best practices".

gehaxelt 9y ago

Hello HN, here's one of the blogpost's authors. Although it has been a while since we published the blogpost, I'll try to answer any questions or listen to any suggestions.

dmitrij 9y ago
https://news.ycombinator.com/item?id=14534499 https://news.ycombinator.com/item?id=14534499

wooptoo 9y ago

For nginx: # deny access to HG and Git repositories location ~ /\.(hg|git)/ { deny all; }

kchr 9y ago
Doesn't solve the issue of the data being available on a public server, though. Any piece of code run by the web server would most likely have access to those directories, as well as any other static content in the web root...

fergie 9y ago

The real solution to this problem is to reference passwords, tokens, keys, or and other "private" strings with environmental variables or external config files, which are then excluded from the source control system. That way your super-secret stuff can never be extracted from git or svn. This approach also has a whole class of additional benefits relating to being able to run a system in different places (for example- setting up dev->test->prod staging servers)

jeisc 9y ago

? Would it not be secure enough to put .git in the directory above the public root: /mysite/.git /mysite/mysiteroot/index.html /mysite/.gitignore /mysite/lib/common

tutufan 9y ago

Rationale for "make install" rediscovered. Film at 11... :-)