Securing PHP on IIS

So you have PHP installed and running on your IIS server, and have installed several PHP applications. All is well. However, have you ever given any serious consideration to securing PHP on IIS to best protect yourself from malicious attacks? In this guide we'll look at some of the steps you can take to help secure PHP in your IIS environment.

Restrict HTTP Verbs

Not specific to PHP, but more a general security precaution is to take a minimalist approach by only enabling configuration options that you actually need. In this case restrict which HTTP verbs can be used by only enabling the ones you need when configuring your PHP application mapping in IIS. Enabling GET, HEAD and POST should be enough for most PHP applications.

Use a customised PHP configuration

Using Microsoft's new FastCGI handler it is possible to use a different php.ini file for every PHP application mapping. Even if you are using the PHP ISAPI extension it is still possible to use per directory configuration values for PHP. What this enables you to do is customise your PHP configuration around the specific requirements of your user and/or PHP application. This is very useful as requirements are often different and using the one PHP configuration file to cater for everything can often mean using a loose configuration.

Seperate your IIS user accounts and application pools

By segregating your users and/or PHP applications by using a different IIS user account and application pool you are able to mitigate the potential of one user and/or PHP application interfering with another. By using different application pools you are able to isolate PHP crashes to the specific user/application causing the issue.


Tighten NTFS permissions

By using the NTFS deny permission you are able to restrict where your IIS user is actually able to go on your system. Basically your IIS user account should only have permissions to the files and directories it needs to access. Everything else should be set to deny. If you have separated your users and/or PHP applications by using different IIS user accounts as mentioned above you can actually make it impossible for one user/application to access files of another user/application. This in effect has a very similar function to the safe_mode php directive used by many *nix based web hosts. Be warned though, setting the deny permission can be very destructive and difficult to recover from when done on a global level. Be sure to plan your permission structure first and make a backup of your system state.

Limit the execution of PHP scripts

Although having a robust NTFS structure is preferable, it can be a lot of work to implement and maintain. Another way of achieving a similar result is to use the open_basedir directive in you php.ini file. Using this directive you are able to specify where PHP scripts are able to be executed from. This does take some planning with your PHP installtion though as this restriction also applies to your PHP session and upload directories. However, with some planning and using custom php.ini files as mentioned earlier this can be very effective.

Restrict PHP Extensions and Directives

Another point for the minimalist approach here is to only enable the PHP extensions that your PHP applications are going to use. There are also some PHP directives such as register_globals and allow_url_fopen which can be security risks, and should be disabled if possible. This will reduce your footprint to the outside world and potentially your risk of being hacked.

Disable unnecessary Functions and Classes

Some PHP functions and classes can be dangerous. By using the disable_functions and disable_classes PHP directives you are able to supply a list of comma separated functions and classes which you wish to disable. Again, these options are at their best when used with a customised PHP configuration so that only the functions and classes used by your application are enabled.

Limit PHP resource usage

A common cause of DoS attacks with PHP is when a script is targeted to exhaust your system resources. In particular ensure that you limit the max_execution_time, max_input_time, memory_limit, post_max_size and upload_max_filesize to only what you need, and what your server can handle.

Don't expose yourself

Last but not least, ensure the expose_php directive is off so that PHP does not expose that it is installed on your server. Not so much a security issue in itself, however the less a hacker knows about your system the harder it is for them.

Hopefully this guide has if nothing else given you somewhere to start with securing PHP in your IIS environment. If you have any feedback or suggestions for addition to this article, please post a comment here. If you a looking for help with securing your own PHP installation on IIS, then please post in the forums.

Average rating
(8 votes)