Security is a layered process. The web-facing component usually receives most of the attention, as it should; but a chain is only as strong as its weakest link. Here are some of the measures we take at OpenWeb to create a secure application from top to bottom.
HTTP layer: PHP#
PHP is the world's most popular server-side programming language. Part of its popularity is its flexibility and "accessibility" (meaning, how easy it is for the programmer to grasp and use).
It also evolves relatively quickly. As a result of these perks, PHP is the victim of shoddy advice and poor use. Most of the top search results for programming in PHP treat it as a "band-aid markup": mixing snippets of it with existing HTML code in order to get one ephemeral flash of interactivity here, or the appearance of relevancy there.
We treat PHP as a full-fledged programming language. We use the latest, stable versions (PHP 5.4). We use Object-Oriented Programming. We actively manage the php.ini file to disallow dangerous, deprecated functions, and set reasonable limits. We stick to a well-defined convention that eschews the cryptic one-liners. And we never mix code (PHP) with content (SQL statement, HTML, etc).
In short, we write an application in PHP, which can interact with the user via XHTML, XML, or some other communication language (like JSON, or even plain text).
Web server: Apache#
Most Apache installations today suffer from the one or both of the following ailments:
- They are grossly out of date,
- They use the package's default configuration.
Updating the Apache web server can seem like an impossible task. In fact, with the proper use of version control tools, it can be nearly foolproof. It is also the only practical way of ascertaining that security holes have been properly patched.
But if uprading Apache is a reasonably difficult task, there is no valid excuse for failing to configure it properly. Virtually all default installations of Apache (that is, as downloaded from a package manager) expose too much. At OpenWeb Solutions, we start with a blank slate, only adding directives that are needed, and only enabling modules that will be used.
When possible and appropriate, we will compile Apache from source, tweaking the configuration parameters and only building into it the modules and extensions we need.
Although most of the servers we have set up are GNU/Linux, most of the following strategies apply equally well to ther UNIX systems:
- Setup a chrooted environment for the Apache web server
- Enable and enforce SELinux
- Set up strong firewall rules (IPTables)
- Set up SSH with Public Key authentication
- Use SUDO for all tasks requiring root permission
- Set up user accounts correctly
- Turn off unnecessary or unused daemons
- Set up proper logging and log rotation
Some clients, like universities and large companies, have full control of their networking environment. In these cases, we make recommendations to the networking team to open just the necessary ports to and from the necessary addresses.
Of course, security does not stop there. There is also security at the physical level, for example. At OpenWeb Solutions, however, we specialize in security at the software level, where the vast majority of attacks are directed.
We are available for consultation if you have questions about how to improve the security of your web environment.