141–150 of 214 posts
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?
Earlier quoted context omitted.
Why do you store such stuff under /public_html anyway? One level higher would be more appropriate I think.
It's not under public_html. It's under /srv/www/domain.com. It is one level higher.
Is there an automated "security as a service" service that if I subscribed to it, it would have told me that this is a problem on my websites? It really annoys me randomly hearing about critical security issues through tech news websites - there should be a more systematic way for "non-security professionals" to ensure their sites are protected to best practice levels.
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?
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…
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 game of cat-and-mouse, where you have to add extra webserver rules for each sensitive file: VCS, crypto secrets, private keys, and so on. In that setup it's easy and very likely to forget one. Of course, this then creates the feeling of "How can anybody keep track of this never ending list of security details?"
In the end, this is a blacklist vs. whitelist thing. Like with your firewall, you want one rule that blocks everything and allows only specific stuff. The alternative is to allow for everything, have rules to deny all sensitive stuff, and finally get in trouble for having forgotten one rule (e.g. probably because an additional service was introduced after the firewall rules have been written.)
Earlier quoted context omitted.
Don't put secret keys in your repository is also the wrong lesson. The right lesson is: Know where your secret keys are and take the appropriate steps to secure them. Whether that's in the codebase, a properties/ini/conf/whatever file, environment variables, whatever - know where they are and make sure you understand possible threats against them. This story could just as easily have been written about how easy it is…
Is there a general algorithm that can tell you all possible threats against your secret keys?
1. Make a list of everything that absolutely positively cannot live without this data/access/permissions/etc.
2. Put the data somewhere where absolutely nothing whatsoever can ever read it (except root).
3. Figure out what one single change will resolve #2 so that the things in #1 can happen without any other things gaining access.
If you don't do #1, you don't understand your requirements/applications. If you don't do #2, then your data is probably vulnerable through some other mechanism. If you can't do #3 then you probably need to change something else (e.g. stop running all processes as the same user, stop running all services on the same box, stop trusting users, set up more granular sudoers rules, etc).
What I find is that when you come up with an idea for #3, and then come up with a list of side effects, you can actually find a lot of the kinds of issues I mentioned above, for example where the public website CMS (as 'daemon') and the accounting backend (as 'daemon') both have access to the same resources, and thus someone gaining access to the CMS can get the accounting DB user/pass and get access to your transaction records, user database, etc.
That is:
- completely non-obvious and unexpected
- a terrible idea
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 error here is uploading sensitive or hidden information to a web host into a public directory, not how it is stored locally.
If you use the root of your app, including source code and hidden files, as the public directory of your website, one permissions error means all sorts of things might be exposed, e.g. other dotfiles would also be exposed, and potentially all of your source code too, because you're relying on the web server to hide it somehow in every instance. That's the problem that needs fixed here (exposing the wrong files to public root), not that one particular hidden folder exists.
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 root of your project should contain nothing more than build documentation/scripts and other developer/user notes & scripts (which for a web application could be as simple as "expose the subdirectory call "public" via your web server" but could be much more for more complex applications that have larger build requirements).
Ignoring this long held recommended practise (which less experienced developers might not be aware of): git originally came from an environment where you couldn't simple expose your repository as your application. The Linux kernel and other projects needed building from source before they could be put into production. So this is in part due to people using a tool in a new context without sufficiently thinking about the possible implications (that the tool designer, thinking about other environments, might not have considered). Security requires a lot of "due diligence" like this unfortunately: you can't expect the tool designer to be aware of all the potential security considerations in your environment, you have to deduce and mitigate them yourself.
It's clear the problem involves some PHP sites developed with git and instead of using a specific www directory inside the project the server points to the root folder of the project thus exposing .git (and the rest). Classic dumb error by PHP developers. I have hard time believing one would be able to expose the .git folder in a Rails,Spring or Django application since the public folder isn't the root folder of the…