One in every 600 websites has .git exposed

Post by moosey » Mon, Jul 27, 2015, 5:48 PM UTC

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…

Post by dang » Mon, Jul 27, 2015, 7:07 PM UTC

jsjohnst wrote: post #174

tokenizerrr wrote: post #156

Earlier quoted context omitted.

Please review HN's guidelines on civility.

Fair point, I potentially should've left off the first sentence. I stand behind the rest of the post, but the first sentence is a bit on the edge and I apologize.

Post by smtddr » Mon, Jul 27, 2015, 9:23 PM UTC

yrro wrote: post #162

smtddr wrote: post #115

Earlier quoted context omitted.

Here's my caution to this. If low level processes can do "ps aux", and they see something like: DB_USER=scott DB_PASSWORD=b3withm3pl3aze /usr/bin/python webapp.py That could be troublesome if an attacker figured out a way to run remote commands on your server even as an unprivileged user.

Reading the environment of another process is a privileged operation.

    pikachu@POKEMONGYM ~ $ sleep 99 &
    [1] 21340
    pikachu@POKEMONGYM ~ $ cat /proc/21340/environ

Post by smtddr » Mon, Jul 27, 2015, 11:12 PM UTC

tokenizerrr wrote: post #206

smtddr wrote: post #205

Earlier quoted context omitted.

If an attacker can get the process that's running the webapp.py to exec some abitrary bash command, that process has the ability to read its own /proc/$PID/environ . In general, you can read /proc/$PID/environ on processes that you own. At least I can do that on my Debian system: pikachu@POKEMONGYM ~ $ sleep 99 & [1] 21340 pikachu@POKEMONGYM ~ $ cat /proc/21340/environ XDG_SESSION_ID=5COMP_WORDBREAKS= "'> (I actually…

If you can get it to exec some arbitrary bash command (or otherwise access the environ of a process) you can also have it cat any file on the server, and even the memory of the running processes that belong to the same user as the exploited process, and also execute network requests. So if you get that far, pretty much nothing will protect you.

Post by otterley » Wed, Jul 29, 2015, 3:22 AM UTC

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…