Some of de most basic and useful general principles of programming must be applied when approaching security matters in your code.
Stay DRY (Do not Repeat Yourself)
More than unproductive, repeating yourself when implementing security is dangerous. Bugs have more room to spread and remain undetected (slipping between a copy and a paste or two .hg commits ). Attackers get more chances to see your code.
Security is imperfect
Just like anything else, all security mechanisms are inherently flawed, the only thing that separates good security from bad security is the degree of work an attacker has to do in order to by-pass it. A security mechanism cannot be perfect, but it has to be at least good enough for the purpose.
Security is not some “self contained” entity
But a chain of mechanisms, governed by a set of practices, used (and abused) by an unpredictable number of unknown users (and abusers). Any secure system is just as secure as its weakest link. When that link fails, security is compromised.
Layers of security
A well conceived security system operates on different layers, hence reducing the chance of complete and catastrophic breach when one layer has failed. It doesn’t mean that isn’t still possible, just that the chances are significantly reduced by putting the burden of security on more than one subsystem, on more than one level.
Offers the logistics required to protect your directories and files from (unautorized) access, serving to the outside world only what it is supposed to get. Secure your web server!
The MySQL server has its own security mechanisms in place, via user-based access, as far as table level, with per-operation authorization (you can grant access to a certain table only, to a certain user, only allowing SELECT operations).
See securing the web server, for general MySQL administrator account guideliness. In addition:
- do not re-use your root account credentials in your scripts! This way, there’s no need to store these on the file system. Instead, create a separate database for the purpose of your website/application, create an user account (with the relevant privileges) for that database only, and store these credentials on the file system (as securely as possible). If your application requires multiple databases, either do the same for each (possibly having a single set of credentials for all of them), or create an user that can create databases, but without the other root privileges.
- make sure your admin credentials are not the same as those for cpanel or FTP access, nor are they the same as those you use in your system’s user management interface
The web server software configuration is largely managed by your web host. They are the ones responsible for the “general” securing of the web server. However, that does not mean (at all), that your system, whose interface is output by the webserver, is automatically secure. That is why you need to take extra steps to secure your system, using what the web server has to offer. Some of these may seem childishly obvious or simplistic. Regardless, just make sure you have it covered.
For the purpose of this tutorial, the PHP engine provides the development environment. There are many features of it that present significant security risks and should be disabled. Lately, they are disabled by default in the newer versions on PHP.
Securing your PHP must include:
- turn off register_globals: put in your php.ini, or use in your code, or put in your .htaccess
- turn off magic_quotes: put , , in your php.ini, or do it the ini_set() or .htaccess way (see above).
- turn off allow_url_fopen and allow_url_include if you don’t need to read files via URLs (usually from other servers)
- set error_reporting level to 0, thus preventing error messages, potentially containing sensitive information, such as database keys, user passwords, etc., from being displayed in browsers; put in your php.ini, or do it the ini_set() or .htaccess way.
Or web application security, or, more generally, system security, is a conglomerate of mechanisms and practices aimed at protecting the integrity and privacy of the system and its users. There are many layers of security, and many ways too look at them. This document looks at security from the position of website/web application developer (i.e. it is less relevant for web/database server administrors).
Staying in sync with the present time is not that big a deal. Keeping your eyes open, your ears keen, and your reflexes intact isn’t particularly difficult. Following your herd is not something hard (or something to be proud of). Most people are on Facebook and Twitter. I’m not. It’s not that I’m not “most people” (which I’m not), it’s that I’m not in sync with my times.
Sometimes, to be ahead of your times, you need to live in the past.
In a seaside town, on a sunny week, at work. Always at work, then back “home” at more work, under never-ending stress, playing Atlas all the time. Not today. Against all ods, today will be a day for sea toe-dipping, plenty of sun burns and a few seaside glasses.
Sometimes you have to stop and smell the seagulls.