PHP security
In this post I’ll be covering how to add security and minimize the risk in PHP itself. I’ll cover how to set up and what to think on when installing and using PHP on your server.
The time has come to publish the second part of the PHP security paper or whatever you wish to call it. My first post generated an email from Tom that wrote;
I get what you mean and it’s a very good way of thinking, but how or what can I do from the PHP part that could contribute to the security.
To be honest I was not planning on having anything like that, only my thoughts on some issues, now when I think about it I should probably have had it as the first part in the PHP security series.
Anyhow here’s a dirty little post about what Tom wanted so enjoy!
The first question that pops up is of course; should I install PHP on my server as a CGI interpreter, a dynamic module or simply a static module?
Well I can right of the bat tell you that the first option is dangerous to choose if not installed properly it can lead to you compromising your server’s security.
So either you get somebody who knows how to do it or you go with the two latter options where the only difference you’ll notice is the small difference in performance.
I myself have pretty much always compile and use it as a static module. The only down side is that I have to recompile on every new PHP upgrade.
Now my goal is to set up PHP in the following manner:
- I want to isolate the future PHP code from the rest of the system
- I don’t want anyone to see that I’m running PHP.
What I mean with the first point is simply to isolate the PHP scripts from the rest of the system.
In this case any breach or evil hack will be contained in a controlled environment, which often is called a sandbox in security terms.
Originally it was used to run and test untested code and software, in that case if something malicious would want to happen it would be confined and no major problems would arise.
When doing this in PHP or UNIX-systems in general the term chroot is used whenever you want to confine the code in a specific part of the directory.
Here’s a pretty bad illustration on how it works, the monster is stuck in the grey box thus not able to destroy rest of the files outside its folder.
I won’t write another detailed tutorial on how to chroot, there are already existing tutorials out on the net.
The second point is to not give away that I’m running PHP, this I covered in the first post. However I will this time explain what needs to be altered in the php.ini file.
If you haven’t at least seen what’s in it then it’s about time you do so!
You could start with what I mentioned in the previous PHP Security post, what I mean is associating the file extension with something else than .php.
This is easily changed in the apache configuration file, you simple have to change the following lines:
AddType application/x-httpd-php .php AddType application/x-httpd-php-source .phps //These could be changed to something along: AddType application/x-httpd-php .krillz AddType application/x-httpd-php-source .krillzs
Now let’s move over to the php.ini. To disable PHP to display information in the http headers you should change the expose_php to off.
Mission accomplished the masking of PHP is now completed!
Now let’s finish securing php, to not make this post too long I will simply post the changes I did in my php.ini and add a comment before each:
//Only be able to access the files in the base directory. open_basedir = directory[:…] //Trying to open files outside the directory with System() or exec() will be refused safe_mode_exec_dir = directory[:…] // scripts are able to access files only when their owner is the owner of the script safe_mode = On //You should turn this off whenever safe_mode is set to on, to prevent group owners accessing files safe_mode_gid = Off //Not to reveal php information in the http headers expose_php = Off //Turn the error loggin on log_errors = On //Set the name of the error log error_log = MakeOneUp //To prevent php errors to be displayed, could give away crucial information to an attacker! display_errors = Off //This is set to off now a days, however make sure this is the case! register_globals = Off
Well that’s all for now, stay tuned for part III!
