121–130 of 214 posts
It seems Google doesn't like people looking into the extent of this problem [1]. When googleing for "inurl:.git", it returns no results. And on top of that, I need to enter a captcha first? [1] https://www.google.be/search?q=inurl%3A%22.git%22
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?
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…
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
It seems Google doesn't like people looking into the extent of this problem [1]. When googleing for "inurl:.git", it returns no results. And on top of that, I need to enter a captcha first? [1] https://www.google.be/search?q=inurl%3A%22.git%22
I've had more success with 'intitle: Index of /.git'
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?
Another way is a second file that overrides settings as needed. Although I have found that to be less maintainable if the configuration file changes. That file should be somewhere entirely out of the VC tree.
Either way, the file must be placed in a directory that is not served by the web server.
/include
and
/public
are traditional. Only /public is exposed by the web server.
Other solutions just seem hackish to me, but every project is different I suppose.
Earlier quoted context omitted.
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…
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
Hell, I recently saw an application where there was unchecked input for being able to download files outside the application... if you passed it a path of, for example `../../somefoo-file` would take you out of that application's path.
The OWASP Top 10 is deadly.
Earlier quoted context omitted.
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…