Web Apps with Tiger: Security and MySQLby Kevin Hemenway
In our "Getting Started" part of this series, I was a little too fast and a little too slow. Like a confused lover, I went too fast because I didn't want to bore you with protracted explanations and foreplay about topics we may both already know. On the other hand, it was a little too slow because we really didn't accomplish much besides enabling PHP and verifying it worked.
In this, our second part of "Web Apps with Tiger", we'll be focusing on protection. We'll replace the default PHP configuration with a more secure version, and explain some of the differences. Finally, we'll install MySQL, our database server, and run through its own security tweaks. In the end, we'll be satisfied, but certainly desiring more.
Now Is the Time for Caring
In the last article, we finished with an
index.php file containing the contents below. When saved into
/Library/WebServer/Documents/ and accessed from
http://127.0.0.1/, we saw a boatload, nay, multiple boatloads, of configuration options relating to PHP. Load up that file again, as we'll be exploring some of what we see.
<?php phpinfo(); ?>
The first line of interest is Configure Command. This contains the exact
configure command (duh...) Apple used to build the PHP module for Tiger. Since most additional features and extensions of PHP are enabled during this
configure process, we can get a good idea at what "extras" we're getting by examining this line: Apple has seen fit to enable command-line usage, XML parsing, EXIF information for images, FTP support, and so on. For those in the know, you'll be particularly distraught to see no image creation or modification capabilities, such as GD. This is the same as it has always been, and I'll address it in the future as necessary.
Next is the Configure File (php.ini) Path, which alludes to a file named
/etc/php.ini where we could fiddle with our PHP settings. This file doesn't actually exist, meaning that PHP starts up with all its default configuration. This default config is represented by what we do have:
/etc/php.ini-default. We could, if we wanted, rename that to
php.ini and make changes there. Instead, however, we'll be using an entirely different source.
Switching to a More Secure php.ini
/etc/php.ini-default in your favorite editor and read the first few lines:
; This is the default settings file for new PHP installations. ; By default, PHP installs itself with a configuration suitable ; for development purposes, and *NOT* for production purposes. ; For several security-oriented considerations that should be taken ; before going online with your site, please consult php.ini-recommended ; and http://php.net/manual/en/security.php.
Even with this admonishment, very few people actually switch to something stronger: inevitably, they code, they code, they code, they release, phew! All done, time for vacation, forget all about security. Before we get serious with any sort of PHP application, we're going to switch to the "recommended" version of the
php.ini. It won't be an oversight.
Annoyingly enough, this configuration doesn't exist on our hard drive, and is quite difficult to find just layin' around in a Google result. Instead, we'll have to download a brand new source installation of PHP, just to grab the one file we're interested in:
php.ini-recommended. Extract the archive and move this file into its proper place:
tar xzf php-4.4.0.tar.gzmorbus@:~/Desktop >
sudo mv php-4.4.0/php.ini-recommended /etc/php.inimorbus@:~/Desktop >
ls -l /etc/php.ini-rw-r--r-- 1 morbus staff 39480 Apr 28 09:14 /etc/php.ini
With that done, delete the archive and restart Apache:
rm -rf php-4.4.0*morbus@:~/Desktop >
sudo apachectl restart/usr/sbin/apachectl restart: httpd restarted
index.php page; unless you've been incredibly astute or have been watching one single variable, you probably won't notice anything has changed. For an explanation of what this process did, along with reasons why, open the
/etc/php.ini in an editor and read through the intro regarding
log_errors, etc. Of chief and immediate interest is that PHP errors will no longer be sent to the browser: you'll have to check your
error_log whenever PHP code doesn't seem to work correctly. I'll throw in another tailDash recommendation: it allows you to simply F12 your way to log viewing.
While we're in here, we may as well make two other small changes that I prefer, but which are certainly not required. The first relates to the
memory_limit setting, which measures how much memory a PHP script can consume. The default is
8M--I usually set this anywhere from
64M, depending on the types of scripts I plan to be running, for how long, and the capabilities of the hardware itself.
24M is a decent enough value to start with. Generally speaking, if a single script is exceeding a
24M-memory limit, something is usually amiss.
I also like to turn
allow_url_fopen feature, though this is more cautious paranoia than any tried-and-true trick. This setting allows the PHP
fopen function to load remote documents stored on other web servers, and has been implicated in a number of break-ins with poorly designed applications. Turn it
Off for now, and if you ever need to use it in the future, you'll probably be smart enough to make a more informed decision.
If you made either of the above changes, restart Apache again.
Pages: 1, 2