What is it about?
This blog posting describes a way on how you can patch security problems and real vulnerabilities in your PHP code, when you’re not allowed to change the code or for example if this is just not possible for any reason. What you’ll learn here is something like virtual patching, as we know it from web application firewalls but we don’t change the code of the already existing application in any way and we don’t even need new components like such an application firewall. Does this this sounds like black magic to you? Don’t worry, it’s not complicated at all

What is it not about?
This blog posting will not show you for example how to fix all vulnerabilities you can expect in your PHP code nor is the described technique working against every kind of security problem. If you have the possibility to change the existing code, this is for sure the way to go and not what I’m writing in this posting. This is really only a technique which you can use when you can’t change the existing code.

Please also be aware, that I don’t give you any guarantee, that your PHP web applications are secure after you’ve done what’s written in this posting.

Skills you need
I tried to write everything as clear as possible but it’s good if you’ve got some basic knowledge of the PHP programming language because I won’t describe my simple code examples.

So let’s start with the main content

The php.ini
First we should talk about the so called php.ini, which will be our interface between the fixes and the already existing source code. The php.ini is the configuration file for PHP and you can see it’s actual configuration by simply have a look at the file or by creating a PHP script like the following:

<?php
phpinfo();
?>

Get your own php.ini on shared Servers
(If you’ve got your own dedicated server, this might not be relevant to you)
This subsection now shows you, how you can work with the php.ini even if you’re application is hosted on a shared server and you don’t have access to the main php.ini file. As a first step, you have to create a file with the name .htaccess, which means that it’s a htaccess file. Under Unix like systems this is not a problem at all but under Windows systems you’ll get an error when you try to rename a file to “.htaccess”, so with the following two steps, you can also create such a file under Windows:

1. Open Notepad or any other text editor.
2. Go to Save As, and chose “.htaccess” for the file name including the quotes.

Now you can upload the file into your wwwroot directory and add the following line to the .htaccess file, when your php.ini file can be found at /home/disenchant/php.ini:

suPHP_ConfigPath /home/disenchant

Now, the new defined php.ini will be used instead of the one, your web hoster has set up globally.

The auto_prepend_file Option
So let’s go into the part of the php.ini which is interesting for us, it’s the auto_prepend_file option. Just add a line to your php.ini like the following, so that it points for example to the PHP file we made before to display the PHP info page or just create a smaller file with just <?= "test" ?> in it.

auto_prepend_file = /abc/xyz.php

As you can see, if you now have a look at any of your PHP scripts in your web browser, the auto_prepend_file option in our php.ini has included our script at the beginning of every file. This is exactly what we need because this way, we can interact with the existing code, even if we never changed something in the original source code. So let’s go on and fix some vulnerable code.

The vulnerable Code
First we need some vulnerable PHP. The following code is vulnerable to an attack type called “Cross-Site Scripting“.

<?php
echo $_GET['var'];
?>

We have now to implement an input encoding functionality for the variable called var (of course this can also be done for all variables or just some pre-defined variables). Let’s have a look at how to write a simple patch for this vulnerability.

The Patch
If we can change the original source code, we would probably use something like the following:

<?php
echo htmlentities($_GET['var'], ENT_QUOTES);
?>

This will replace (all) characters which can be dangerous or better say, can be used for executing malicious script code, with their equivalent HTML entity. This makes this piece of code secure but in our situation, we won’t be able to change the code and that’s why we need the technique I described in this posting, over the php.ini. Instead of modifying the existing source code, we create a new file like this:

<?php
$_GET['var'] = htmlentities($_GET['var'], ENT_QUOTES);
?>

Because of the auto_prepend_file option we set in our php.ini, this code will fix our vulnerability

Final words
As you’ve seen, this technique can become very helpful under some circumstances and of course I showed you just the basic use of it and you can go much further and for example implement login stuff, session management, white listings and so on through this.