Web Security is a Three Edged Sword
We just released a new build of ExpressionEngine 1.6.7 that includes some measures to help prevent information disclosure due to residing on insecure server environments, and it got me thinking that it would be a good time to write up a post on web security basics for people new to the subject and as a reminder for pros.
There’s an aphorism from the TV series “Babylon 5”: Understanding is a three-edged sword: your side, their side, and the truth. In a similar vein comes the title of this blog post. Web security is a three-edged sword: the server, the software, and you. Like most truisms, it is self-defining, obvious, and relatively uninteresting because it doesn’t tell you anything that you don’t already know; it’s just wrapped up in pithy phrase. Perhaps due to their boring “heard-it-before” nature, the truths spoken in such phrases are easily and quickly forgotten in day to day routines or in moments of panic, both times that we as humans tend to run on instinct and auto-pilot instead of giving weighty thought to matters.
So, reminders are handy. As is the case in this build, some changes we make to ExpressionEngine do not deal directly with the security of ExpressionEngine’s code, but try to make up for failings of either server security or lack of precautions taken by the user. Each edge of the sword is not wholly independent. Many times, one edge can make up for a deficiency in another. But all three edges must be considered and sharpened to have a complete solution.
One edge of the sword is the software, and is the responsibility of the developers. Application security is something that we have always taken very seriously, developing from the ground up with security in mind. That mindset is what drives us to write code that can prevent common problems that result from server inadequacies, or to block certain input that if a third party were to use in their code without validating could cause problems, and so forth. You can’t control ExpressionEngine’s code security - that’s strictly our responsibility and on us. But there are some things that are under your control that can help keep your sites safe, regardless of what software you are using, by examining the other two edges of the web security sword.
You. If you’re implementing add-ons or PHP in templates, are you or the developer fully aware of potential security issues? Do you have old versions of software left on your web site? Scripts that you aren’t using any more? Do you keep the scripts that you are using up to date (including tools that the host may have pre-installed for you like phpMyAdmin)? Have you renamed your system folder to something unique and hard to guess (“sys”, “admin”, and “cp” fail this test)? Do you change it regularly? Do you keep a ZIP archive of your site in a publicly accessible web directory (this one’s bad if that’s not clear)? Is your password any of the following: password, password1, 123456, 123456789, or expressionengine? You might laugh at these, but a number of readers right now are logging into their settings to change their password. On that note, if you are giving untrusted people access to your site or SFTP account, create a temporary user for them, restrict access as much as possible, and remove their account when done.
The last edge of the sword (in the discussion, not in significance) is the server. The good news about the server, and some people tend to forget this, is that it is also controlled by you. If you cannot make or request necessary changes to improve security of your server, you can move. “The host is cheap”, “I’m locked in for a year”, “the client loves them”, “they’re honest about their failings” etc. are not excuses to stay on an insecure or poorly configured server. If your software had a flaw that allowed any guest to edit or delete any piece of content they wanted, would you keep using it simply because you had already paid for and installed it? Certainly not. Why anyone would put up with less from their hosts is beyond me. But here are some things you can check for and/or do to maximize safety of your software on a server:
Moving application system folders and other potentially sensitive files outside of a web accessible directory. Is auto-directory indexing enabled (the mod_autoindex Apache module)? If it is, ask your host to disable it and failing that use .htaccess Options -Indexes. Choose a server that runs Apache as your user or with equivalent permissions. If Apache runs as www/nobody without additional “jail” type security, run away. Choose a server that uses SFTP only.
These lists are not in any way intended to be complete but just to help encourage thinking about security from all three sides, since a failure of one cannot always be mitigated by the other two. Hopefully this post will be helpful to those new to the game, and remind the adept to stay on their toes!
