WAF: Request Filtering
The Request Filtering section contains the essential defenses of the Web Application Firewall feature. Admin Tools will monitor incoming requests and the data that is submitted to your site, filter them using these options and decide which requests seem to be nefarious, blocking them.
When enabled, Admin Tools will try to detect common SQL injection attacks against your site and block them. This solves one of the most common attacks against WordPress plugins so we recommend that you always leave it enabled.
But what is a SQLi attack? Quite a lot of WordPress plugin developers are hobbyists, without experience and / or security training; or mistakes do happen, as WooCommerce famously found out the hard way in early 2017. 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 administrator 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.
Some hackers will try to coerce a vulnerable plugin 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 requests, try to fetch the remote URL and scan its contents. If it is found to contain PHP code, it will block the request.
If your site starts throwing white pages when submitting a URL in your site's front-end, please disable this option. The white page means that your server is not susceptible to this kind of attack and doesn't properly advertise this to Admin Tools when requested. In this case, Admin Tools crashes while trying to scan the contents of the remote location, causing the white page error. Disabling this option in such a case poses no security risk.
The best way to deal with this issue is at the PHP
level, by adding
allow_url_include = 0 in a new
line inside your server's
php.ini file or
.user.ini file in your site's root
(if the latter file doesn't exist you can create it). In this
case you can disable this Admin Tools option.
Some hackers will try to pass a request parameter beginning with the php:// wrapper and specially crafted filters to coerce the server into executing malicious code. This is an advanced attack which can be easily blocked by Admin Tools when you enable this option. We recommend that you always enable this option.
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 local file path. If one is found, it will be scanned. If it is found to contain PHP code, the request will be rejected.
This feature does NOT prevent dumping of non-PHP
files, e.g. the
When this option is enabled, Admin Tools will proactively scan all files which are uploaded through WordPress. If any of these files is found to contain PHP code the request is blocked. This can prevent some kinds of very tricky attacks, like uploading malicious PHP code wrapped inside avatar images. Do note that not all servers support this feature. If the uploaded files directory is blocked by open_basedir restrictions, no scanning will take place. If unsure, ask your host if they have put open_basedir restrictions which block access to the PHP uploads directory. If they answer affirmatively, this Admin Tools feature will not work unless this restriction is lifted.
NOT ALL PLUGINS ALLOW ADMIN TOOLS TO SCAN THEIR UPLOADS! Some components do not use WordPress' index.php entry point file. Instead, they use their own. Since these uploads do not pass through the WordPress application, Admin Tools' code doesn't run and these uploaded files are not scanned UNLESS you have used the Optimize WAF feature. In this case and if you have not enabled the Optimize WAF feature, if a plugin is found vulnerable your site will still be at risk. We suggest using the Optimize WAF feature for maximum protection of your site.
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.