Like in the case of all apache modules,in apache mod_php you can either compile PHP as a static module or compile it as a dynamic module. In the case of static module , you can’t perform any modification for the module without recompiling the binary to which it is attached. For eg. you can’t add ssl support for the mod_php without re-compiling apache as a whole. And any failure in the compilation may cause downtime for the entire webserver also, including plain html support.
The advantage is that it provides a faster performance, because the module is initialized whenever the apache binary is started.
In the case of a dynamic mod_php installation, the necessary modifications or module additions can be done by recompiling the module alone. There is no need to recompile the Apache as the mod_php is not linked with the binary of apache. But since the webserver loads the module on the fly, it needs to load, initialize and then execute the module. So it can create some level of slowness while processing php pages.
How does apache mod_php work?
When PHP is loaded into Apache as a module (using mod_php), each Apache process will contain an instance of mod_php or PHP interpreter also. The interpreter comes with a bundle of libraries we enabled during compilation and each process can make use of these libraries to process the requests. This means that the Apache process that just started to load a simple HTML page too will contain a PHP interpreter with all assigned libraries which inturn means resource consumption.
When the webserver gets an HTTP request. The request header contains the path to the requested document
e.g. access.log: xx.xx.xx.xx – – [22/June/2010:21:14:53 -0700] “GET /info.php?=PHPE9568F35-D428-11d2-A769-00AA001ACF42 HTTP/1.1” 200 2146 “http://domain.com/info.php” “Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.7) Gecko/20100106 Ubuntu/9.10 (karmic) Firefox/3.5.7”
1. The request will be redirected to the document root of the domain and then to the file “info.php” , if it fails then the corresponding error message will be given.
2. The info.php file is to be processed. It follows the following steps
Normally every httpd.conf file will have an entry like this
AddType application/x-httpd-php .php5 .php4 .php
AddType instructs the webserver that the files with extension .php ,.php4,.ph5 are of MIME type application/x-httpd-php. This helps the webserver to recognize files with .php are to be associated with the MIME type application/x-httpd-php
The TypesConfig directive sets the location of the MIME types configuration file. This file controls what Internet media types are sent to the client for given file extension(s). Sending the correct media type to the client is important so they know how to handle the content of the file.
root@new [/usr/local/apache/conf]# cat mime.types | grep x-httpd-php
application/x-httpd-php-source phps
application/x-httpd-php php php3 php4 php5 php6
root@new [/usr/local/apache/conf]#
Here we can see that the Mime type to be used for files with extension .php is application/x-httpd-php , while the file with .phps is to be mapped to the php mime type application/x-httpd-php-source .
The webserver identifies that the requested file is of Mime type x-httpd-php.
To handle or process it , the apache has to load the corresponding module. Since it is a php type , the module mod_php will be loaded and it will execute the file.
Since apache is a HTTP server. It gets the HTTP requests and answers with the HTML code. So the apache mod_php will execute the commands within php flag and creates the HTML page dynamically and send it back to the client – internet browser which sent HTTP request.
Security concerns / Implications
You can see that every request or execution of a php file through web is initiated by the webserver. So the webserver acts as the parent of every php execution through web. It imposes a great security threat. Since apache is being executed as an apache user, all process will be owned by that user. By default it is “nobody” or “apache”. Let me try to explain.
If your web application performs some operations in the db, unless that database (eg: a flat text DB) has built-in access control, you will have to make the database accessible to the “nobody” user. This means a malicious script could access and modify the database, even without a username and password. Such can be the case with various configuration files too. Unless you protect these directories or applications with necessary authorization techniques like .htaccess, session control etc. There is a high possibility of attack through webapplication.
Another dangerous issue is of root escalation. If the webserver has a bug, by exploiting that bug, a malicious user can gain some root privileges or escalated to root. Its quite alarming situation as an escalated apache user can do any sort of actions without any level of authentication.
Also it is difficult to identify the script which performs the malicious activity as all php scripts will be executed as “nobody”
Since PHP applications are executed as web server user, you need to give access and write permissions for the directories wherever the application is supposed to be working. Sometimes you may be forced to give 777 permissions and it invites lot of attacks.
The files created by php applications will be owned by user “nobody” . So the user will not be able to delete the files unless it is done through another php application. Otherwise he needs to contact the server admin to get the same.
As a security measure, we may be forced to block mails from “nobody” users . But it can create mails generated from php applications being blocked in the server. Various php applications widely used for spamming . So some servers are configured to block mails from nobody users. This creates inconvenience to users.
Further Readings:
https://www.supportsages.com/2010/06/php-behind-the-scenes/
