When enabled, Admin Tools will try to detect common SQL injection attacks against your site and block them.

But what is a SQLi attack? A few Joomla extension developers are hobbyists, without experience and / or security training; or mistakes do happen, as Joomla itself has found out the hard way. One of the common mistakes they do is to make assumptions about the nature or the content of user-submitted data, interpolating them into database queries as-is. Database queries are also called SQL queries (SQL, pronounced "sequel", is the shorthand for Structured Query Language, the programming language the database queries are written in). An attacker can exploit this mistake by sending data which have the effect of terminating the developer's database query and starting a new one which either dumps privileged data -such as usernames and passwords- or modifies data into the database - such as adding a new Super User under the control of the attacker. This class of attacks is called an SQL Injection, or SQLi for short, since the attacker "injects" his own code into a SQL query running on the site.

Many hackers will try to access your site using a browser configured to send malicious PHP code in its user agent string (a small piece of text used to describe the browser to your server). The idea is that buggy log processing software will parse it and allow the hacker to gain control of your website. When enabled, this feature allows Admin Tools to detect such attacks and block the request.

Some hackers will try to force a vulnerable extension into loading PHP code directly from their server. This is done by passing an http(s):// or ftp:// URL in their request, pointing to their malicious site. When this option is enabled, Admin Tools will look for such cases, try to fetch the remote URL and scan its contents. If it is found to contain PHP code, it will block the request.

Some hackers will try to read the files of your site using the php:// wrapper and some advanced PHP filters. When this option is enabled, Admin Tools will block every request that contains the php:// string.

Some hackers try to trick vulnerable components into loading arbitrary files. Depending on the vulnerable component, the file will either be output verbatim or parsed as a PHP file. This allows attackers to disclose sensitive information about your site or run malicious code uploaded to your site through another vulnerable vector, e.g. an unfiltered upload of executable PHP code. When this option is enabled, Admin Tools will search the request parameters for anything which looks like a file path. If one is found, it will be scanned. If it is found to contain PHP code, the request will be rejected.

Prevents malicious input data which can be used to trick PHP's internal session handler into executing arbitrary code when it's restoring the user session.

The PHP session unserializer has a major bug which makes it misinterpret stored session data if they contain specific character combinations, overwriting the legitimate session data with the attacker-defined contents. Combined with some other features of PHP this can lead to the execution of arbitrary PHP code. In short, attackers can send malicious data in one page load and get arbitrary code to execute in the next page load. This feature of Admin Tools detects and blocks this kind of malicious data. CAUTION: It may block some legitimate requests as well.

session.serialize_handler = php

session.serialize_handler = php_serialize

When enabled, all requests containing at least one word in the Bad Words list (configured separately, see the next sessions) will be blocked. By default the Bad Words list is empty; you have to configure it to match your site's needs. One good idea is to include pharmaceutical, luxury watches and shoes brand names, as this makes up the majority of comment and contact spam received on web sites.

Joomla's powerful frontend display comes, to a large extent, from being to configure its components and modules per menu item. Each menu item has a numeric ID, called “Itemid” in Joomla parlance. In fact, the Itemid is always present in the request parameters. When you have ‘Search Engine Friendly URLs’ turned off you can see it in the request. When it's enabled, Joomla automatically populates it from the URL query, i.e. the path in the URL you are using to access a page on your site (but in this case it can also be overridden in the URL). This is such a basic concept that Joomla's core code make the assumption that the Itemid is always a positive integer.

If someone makes a request with an Itemid which is not a positive integer, for example something like https://www.example.com/foobar?Itemid=123/ (note the slash after the number 123, it's part of the Itemid value!), Joomla will throw an error and a PHP exception email will be sent to you if you've configured this feature in Admin Tools. In most cases it's due to a search engine having cached an invalid URL like the one above. In some cases it might be a malicious probe with a technique called fuzzing, i.e. sending random data in known URL parameters to see if the site breaks in a way that can be exploited by an attacker. While Joomla itself will merely throw an exception, it is possible that system plugins executing before Joomla's router kicks in read the invalid Itemid and behave unexpectedly.

The ItemidShield deals with these requests in one of the following ways:

Joomla! has a number of query string parameters with a special meaning. These parameters cannot be used by extensions for any other purpose. Therefore, these parameters have a well-defined expected format. This feature checks whether these parameters follow this format. If not, the request is blocked.

Discrepancies between the expected format and the value in the HTTP request usually happen because of one of two reasons. The first reason is an attacker is trying to test your site for Reflected Cross-Site Scripting (Reflected XSS). In this case, the attacker tries to pass malicious JavaScript code, hoping that your template will output the malicious code verbatim in the output, making it executable. This can then be used to create maliciously crafted links which can lead to admins or users of your site getting hacked. The other reason is that there is a simple coding mistake in an extension, usually one which happens either under unexpected circumstances, or one which went by undetected because Joomla! “cleans” the content of core parameter query strings before using them. In the latter case, please contact the developer of the affected extension – NOT the developers of Admin Tools! – to address the problem in their code.

How this feature works

Admin Tools checks the value of the following query string parameters to ensure they are either unset, or their value follows the expected core Joomla! filter format for each one of them. This Admin Tools feature DOES NOT inspect the contents of each value, i.e. it does not try to make inferences about their meaning and validity, with the sole exception of the type parameter when format=feed (see below). The checks take place twice: in the onAfterInitialise and onAfterRoute events. The former runs as early as possible, checking the values coming into the application from the request (checking the $_REQUEST, $_GET, and $_POST PHP superglobals, as parsed by Joomla!). The latter checks the same values after Joomla! has performed SEF URL routing. Therefore, it makes sure that neither the request contains tainted data, nor that a rogue database entry or plugin corrupted the values of core variables.

The meaning of the filters listed above is exactly what Joomla! defines them to be, namely:

This is a list of fully qualified domain names your site can be accessed on, one domain per line. DO NOT enter http:// or https:// in front, do NOT enter the / after the domain name or the path that follows it. This is a domain name, not a URL. For example: example.com. You do not need to enter the www/non-www versions of the domain names or domain names which resolve to the localhost IP address (127.0.0.1 for IPv4 or ::1 for IPv6). If an attacker tries to access your site with an HTTP Host header that does not match these domain names (or their www/non-www versions) they will receive an HTTP 421 Misdirected Request error message.

This feature mitigates a class of attacks called “HTTP Host spoofing” which affects a stark minority of servers, mostly servers which were set up by someone who doesn't understand web server security enough or at all. On those servers you can send an HTTP Host header which confuses the server into believing that this is the domain name it's running on. So, even though you are accessing a site on www.example.com you can send it a Host: www.evil.hack HTTP header and now all URLs generated by the server will use the www.evil.hack domain name. This is used in phishing attacks to misdirect a submitted form with login credentials to a server under the attacker's control even though the browser's address bar shows a legitimate domain name.

If you are on an affected server you are VERY STRONGLY recommended to use this feature INSTEAD OF setting the $live_site URL in configuration.php, the latter being the traditional but incorrect way of mitigating such an issue. Setting the $live_site URL limits your site to exactly one domain name (remember that example.com and www.example.com are two different domain names!) and protocol (HTTP vs HTTPS). Therefore using $live_site is extremely limiting and can cause your site to stop working if you try to enable/disable HTTPS everywhere in Joomla's Global Configuration, enable/disable www to non-www redirections etc. Moreover, the $live_site URL in configuration.php does NOT protect against all host spoofing attacks. What Admin Tools does will indeed protect all requests handled by Joomla against such attacks without causing any of the adverse effects of Joomla's recommended course of action.