The process of securing the Apache server was described in the previous article, so as a starting point we'll use the configuration file that was presented there. For Apache to handle PHP scripts, we must add the following lines to httpd.conf:

    AddModule mod_php4.c
    AddType application/x-httpd-php .php

    AddType application/x-httpd-php .inc
    AddType application/x-httpd-php .class

It is worth to note that besides "*.php", two extensions have been added as PHP scripts: "*.inc" and "*.class". Programmers often include additional files, with an extension like "*.inc", "*.class" or similar. Because by default those extensions are treated as regular files, the requests to download them will reveal the source code comprised in them. This can lead to revealing passwords or other sensitive information.

A few changes must also be made in the PHP configuration file (/etc/php.ini). The most important changes that should be made to improve PHP security are as follows:

In addition, changing the file extension can be taken into account. For example *.php to *.asp, *.dhtml or even *.html. Such a change will make it difficult for any potential intruders to recognize the server-side technology that is being used. In order to change the extensions, all the *.php files should be renamed to *.dhtml (for example), and the following line should be changed in /chroot/httpd/usr/local/apache/conf/httpd.conf:

    AddType application/x-httpd-php .php

to the new one:

    AddType application/x-httpd-php .dhtml

Thanks to that, web users will not see *.php extension in the URL address which is what immediately suggests that the PHP technology is being used at the server side.

Defending against CSS and SQL Injection attacks

The last step of securing the server is implementing the logging of the GET and POST payloads, and implementing protection against Cross-Site-Scripting and SQL Injection attacks. In order to perform that, we will use the mod_security module, which we enable by adding the following line into httpd.conf:

    AddModule mod_security.c

To enable logging of the GET and POST requests, it suffices to add the following section to httpd.conf:

    <IfModule mod_security.c>
         AddHandler application/x-httpd-php .php

         SecAuditEngine On
         SecAuditLog logs/audit_log
         SecFilterScanPOST On
         SecFilterEngine On
    </IfModule>

The above commands will enable the Audit Engine, which is responsible for logging requests, and the Filtering POST Engine, which will make it possible to log POST requests. In order to protect web application against CSS attacks, the following lines should also be inserted before "</IfModule>":

    SecFilterDefaultAction "deny,log,status:500"
    SecFilter "<(.|\n)+>"

The first line causes that the server to return the "Internal Server Error" message when the request contains the search phrase from any SecFilter variable. The second line sets up the filter to search for HTML tags in the GET and POST requests.

One of the typical signatures of SQL Injection attack is the appearance of an apostrophe (') or quotation mark (") in the GET or POST request. By rejecting all the requests containing those characters, we can make the use of SQL Injection technique very difficult:

    SecFilter "'"
    SecFilter "\""

Note, that although filtering the <, >, ', " characters lets us defend against CSS and SQL Injection attacks, it can lead to the improper functioning of the PHP application. It happens, because regular users cannot use those characters in the HTML forms. To solve that problem, the JavaScript language can be used on the client side, which should replace the prohibited characters with special tags, e.g. &lt; &gt; &quot; etc.

Summary

Achieving a high level of a web server's security using server-side technologies (PHP, ASP, JSP etc.) is a very difficult task in practice. The very nature of interactions with a web server in any significant way decreases the web server's security. That is why server-side scripts should only be used where it is absolutely necessary.

The methods described in this article let us mitigate the risk of a successful break-in when new vulnerabilities in Apache, PHP or even the web application itself are found. Of course, the article doesn't exhaust the subject of securing the PHP technology - only the basic outlines were presented. And although applying them can increase the level of security, we cannot forget that the security of the whole environment depends not only on Apache's or PHP's configuration, but also and foremost - on the web application itself.

Ref: http://www.securityfocus.com/infocus/1706