>> Developers’ Land of Web Strait.

According to www.owasp.org, the top 5 security issues faced by PHP community nowadays are:

1. Remote code execution.
2. Cross-site scripting.
3. SQL injection.
4. PHP configuration.
5. File system attacks.

Most of these security problems were caused by the developers or server’s administers. Today, I just wanna talk about the File system attacks. Such security issue is even critical for those applications operate in a share hosting environment. Hence, I would like to further specialize my discussion on “File system attacks in a shared hosting environment”.

Most of the time when we talk about the security attacks, you would probably think that such irritated behaviors must be initiated by someone stays far from the server that host your web applications. Such statement would be correct if and only if your applications were hosted in a dedicated server and none of the strangers were sharing the same server with you. Yep! those strangers are your “neighbors”, but how good that you know about your “neighbors”?

Most of the time, PHP applications are running by the webserver Apache + php_mode - it is by far the fastest(i.e. relatively best performance) way to run PHP scripts. The web server - Apache will normally run as nobody, or apache. In order for Apache to be able to serve your web content, that content must be readable by nobody. This includes images, HTML files, PHP scripts, and etc. Thus, if someone gain the same privileges as nobody on the server, they would be able to access to your web content hosted in the same hosting environment. Mean while, there are plenty of functions in PHP available for your “neighbors” to hack your web application.

For example, to steal my neighbour’s DB configurations in WordPress, I would just need one line of code as following:

readfile(’/home/neighbour/public_html/wp-config.php’);

When the share hosting had been more and more popular since HTTP/1.1, such security issues had been one of the most critical security problems faced by the PHP community. Finally, the safe_mode directive is specifically designed to try to solve or minimize such security issues in a share hosting environment. However, safe_mode directive should be configured correctly. Otherwise, It won’t be safe, but make the situation to be worse and caused a lot problems. Please bear in mind that safe_mode directive had been dropped from since the PHP 6, and there is something important stated in the PHP manual:

It is architecturally incorrect to try to solve this problem at the PHP level, but since the alternatives at the web server and OS levels aren’t very realistic, many people, especially ISP’s, use safe mode for now.

When safe_mode is enabled, PHP will ensure that the owner of the script must be the same with the file being opened(i.e. opened for read, write, execute). Otherwise, it will abort the script’s operations. As you can see from here, it’s much more restrictive than what you can imagine in Unix Shell scripting. Because there is possible for a Shell user to read a file that is not owned by him. For E.g. rwx rwx r– file1.php. In Shell, the owner and group users of file1.php had the read, write, and execute privileges. Mean while, the other users had the read privilege. However, by enabling this safe_mode directive in PHP, those PHP scripting files owned by the other users and even the group users will never be able to open file1.php. Therefore, there is another PHP directive called safe_mode_gid had been created for relaxing the checking to the group instead of the user when it’s being enabled.

On the other hand, there is another solution to the shared hosting environment. That is implementing the PHP in CGI(i.e. Common Gateway Interface) mode instead of using php_mode. However, it’s not the efficient way for those hosts in which need to serve too many requests. Unlike php_mode(i.e. PHP interpretor is persistent and in-process as long as the Apache web server is running), when we adopted CGI way of implementation, a full PHP interpretor or process is forked for every single request of dynamic content. Thus, when there are too many requests at the same time, the server may run-out of resources and memory. Anyway, CGI on the other hand, takes no overhead when idling. Hence, it should be an ideal way for those hosts in which serve just few thousand page views a day.

Ok, when we had implemented PHP as CGI, then we can implement Apache’s suEXEC to secure the shared hosting environment. By using CGI+suEXEC, when the web server received a request, then the site owner’s user ID (instead of the web-server’s user ID) will be used for opening a file. But we must configure it correctly. Otherwise, it would cause more security problems to us. The following is the statement from the Apache suEXEC Support.

What is suEXEC?

The suEXEC feature — introduced in Apache 1.2 — provides Apache users the ability to run CGI and SSI programs under user IDs different from the user ID of the calling web-server. Normally, when a CGI or SSI program executes, it runs as the same user who is running the web server.

Used properly, this feature can reduce considerably the security risks involved with allowing users to develop and run private CGI or SSI programs. However, if suEXEC is improperly configured, it can cause any number of problems and possibly create new holes in your computer’s security. If you aren’t familiar with managing setuid root programs and the security issues they present, we highly recommend that you not consider using suEXEC.

On the other hand, there is an alternative for suEXEC called suPHP in which do exactly the same mission as suEXEC. We will discuss on installing and configuring suPHP in future to secure a shared hosting environment.