Leveraging the Power of the “defines.php” File to Monitor POST Requests on Joomla Websites

As of version 1.6.0 (which was released 6 years ago in January of 2011), Joomla checks for the presence of a defines.php file at the main directory of the website. If it finds it, then it includes it.

The defines.php file is not part of the Joomla core, it doesn’t even come packaged with Joomla. It is, in fact, a user defined file, and not many people in the world know about it. Unfortunately, most of those who know about it associate with a horrible experience, because it was used to exploit their website (someone took advantage of their Joomla website and uploaded a malicious defines.php to their website).

For us, we think that the defines.php is an excellent tool for security. Yes – we know that the reaction to this statement would be similar to that of Professor Slughorn when Tom Riddle (aka Lord Voldemort) asked him about the Horcruxes, but let us explain…

The defines.php file is the first file to be loaded by Joomla. In fact, the code to load the defines.php is in the top of the main index.php, and not much code is executed before it (save for a few lines of code for checking if the version of PHP is OK and for getting the current time and the current memory usage). This means that it is impossible, from an application perspective, to hack the Joomla website before the inclusion of the defines.php file. This in turn means that, assuming that the website is clean, one can add additional security in the defines.php file mainly by monitoring POST requests (or any type of requests) to the website. Here’s how:

  • You create a file called defines.php at the main directory of your Joomla website.
  • In the define.php, you add the following PHP code:

    $strPostData = file_get_contents('php://input');

    The above code will grab all the data submitted using POST.

  • You check the above data for any suspicious pattern using the PHP function stripos, and, in the case of some malicious content, you just block further processing of the page using the die function.

As you can imagine, you can do a lot of powerful things when it comes to security with the defines.php file. There is one caveat, however, is that the code in the defines.php will only intercept POST requests made to the main index.php file. So, if you have an additional PHP file that is directly accessible by the outside world, then the defines.php code will not be executed for that file. If you want to ensure that all traffic goes through your defines.php filter, then you should ensure that the index.php file is the only PHP file directly accessible by the outside world.

So, was additional security the original purpose behind the defines.php file? If yes, why wasn’t this additional security added to the Joomla core?

No. Additional security was not the original purpose. The defines.php concept was created by Joomla developers to store user defined global constants. For example, if some of your extensions use the now obsolete DS constant, then you can add the following to your defines.php file:

define('DS', '/');

The above line will ensure that any DS constants are properly replaced by the forward slash (/).

Do you need to place code in the defines.php file inside PHP tags?

Definitely! The defines.php must be treated like any other PHP file. You must have the opening and closing PHP tags.

We hope you found this post useful, and we hope that you take advantage of the defines.php file in order to strengthen the security of your Joomla website. If you need help doing so, then please contact us. We are always there for you, our prices are super affordable, and we are experts in Joomla security.

One Response to “Leveraging the Power of the “defines.php” File to Monitor POST Requests on Joomla Websites”
  1. Comment by Michael — February 15, 2017 @ 10:32 am

    Actually the intent was to one day be able to set up Joomla in a way where you could move the core filesystem around (i.e. take everything out of the web space except web assets, a good security practice). Unfortunately getting Joomla in a state to make that feasible seems to be such a low priority I doubt it’ll ever happen.

Leave a comment