System directory

The (generically titled) “system” directory of your website or web application should be the one containing all the scripts required for system administration, completely separated by all other files. To achieve maximum security in this regard, here are some important guideliness:

System directory name

  • do not name the “system” directory “system”, or “admin”, or “root”, etc.. Instead, choose an unusual and cryptic name, and use a global variable in your code to hold this name. This way, the default “system” directory can me renamed and moved deeper into the file system, provided the global variable is hard-coded with the same value (eventually including the relative path). If you’re building a system that get’s deployed to others, teach the (future) admin to do this before going live.
  • URL rewriting to access the “system” directory should only be used on top of the action described above.
  • “system” directory name should not be made apparent to any visitor or registered user, except system administrators, who would get a link taking them to the admin interface located in this directory
  • scripts running in the “system” directory (say,¬† should display no direct outbound links (to other websites)! Reason being, the HTTP Referer header will contain the URL, compromising the secrecy of the “system” directory name.

Continue reading

The need for website security

Website defacement

You may be developing a simple, straight forward personal website, containing information that’s both public, and easy to back-up, and so implementing proper security measures doesn’t present much interest. However, no matter how simple or low-value your system is, it is definitely not your intention to have it defaced by hackers. Failing to secure your website guarantees that, sooner or late, it will be defaced, if only for the lulz. Happened to me? Oh, yes.

Continue reading

Common security mistakes

Stupid mistakes

Stuff you have no excuses for, no matter what you may come up with. I know, you’re so above and beyond¬†this, but simple things are often the easiest to overlook, and when they go wrong they tend to do the greatest damage. Before pondering on which encryption cipher to use, make sure you’ve got these covered.

  • sticking your FTP/website admin credentials on a post-it on your monitor
  • keeping any admin credentials in a plain-text file on your webserver, which, when accessed, will not undergo any server-side processing (such as happens to a PHP script), but will be simply displayed in browsers
  • letting your sensitive directories (containing sensitive administrative data) be accessed from the web, including as indexes
  • diluting security of your admin credentials by holding them in potentially insecure online storage, such as your own email inbox, in plain-text
  • using poor admin credentials, such as an easily guessable admin user name (“admin”, “administrator”, “webmaster”, “root”, etc.) and a weak password (i.e. short and lower case letters only)

Continue reading

Security risks and threats

Social engineering

This was the singlemost effective tactic Kevin Mitnik used, according to himself. The name sounds cool, but it really is about getting people to spill the beans and give the attacker security sensitive information in the old fashion way, that only requires people skills (as opposed to advanced computer hacking skills).

Allegedly, this is still the most effective way of breaching security, as it relies on the weakest link in the security chain: the human.

Continue reading

Secure your code: general principles

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.

Continue reading

Food for thought

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.

Continue reading

Layers and levels of security

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.

Web server

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!

Continue reading

Secure the database 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

Secure the web/FTP server

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.

Continue reading

Secure PHP

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 register_globals = Off in your php.ini, or use ini_set(‘register_globals’, ‘Off’) in your code, or put php_flag register_globals 0 in your .htaccess
  • turn off magic_quotes: put magic_quotes_gpc = Off, magic_quotes_runtime = Off, magic_quotes_sybase = Off 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 error_reporting = 0 in your php.ini, or do it the ini_set() or .htaccess way.

Continue reading