This page allows you to configure exceptions to the WAF filtering rules. Some components are designed to properly and safely parse and use data which triggers WAF protection rules. Most usually, a component accepts an absolute path to files on your server or can parse complex data which normally trigger WAF's filters. Without any exceptions set, these components would be blocked and you wouldn't be able to properly use your site. While you could disable the entire WAF feature which got in your way, this would also end up degrading the security of your site. Using the WAF Exceptions view you can fine tune which components, views and query parameters are in the "safe list" and should never be blocked.
WAF Exceptions is a very useful and powerful tool. It's also possible that you apply too many exceptions, opening potential security wholes in the firewall. Be very cautious when using it. Please keep in mind that when you add an exception, WAF is COMPLETELY TURNED OFF for all requests matching the exception. If you apply a too broad exception you will be deteriorating your site's security to the level it was before installing Admin Tools.
WAF Exceptions are defined by specifying a combination of three things:
Component. Which component the exception applies to. If you want to apply the exception to all components, no matter what, leave this blank (“– Component –”).
View. The component's view (component area) or controller name which need to be present in the URL for this rule to match. Turn off SEF URLs and you will see either view=ViewName or task=ViewName.TaskName where ViewName is the View Name you need to enter here. Leaving empty matches all views. If you want to match a SEF URL path leave the Component set to “(All)” and enter the SEF path WITH a leading slash but WITHOUT index.php. For example, use /foo/bar. On multi-language sites you must NOT include the language prefix e.g. /en/example is wrong, whereas /example is correct. Please note that this can be a partial path i.e. /foo/bar matches both /foo/bar/test and /foo/bar.html.
Due to the way Joomla! works, if you are using Joomla!'s SEF URLs it is possible that WAF Exceptions will not work with some components. In this case, change the ordering of the System - Admin Tools and your SEF router plugins so that the SEF router plugin is published BEFORE Admin Tools' plugin. This way Admin Tools will not be able to protect your site against potential vulnerabilities in your SEF component, but it will be able to apply WAF Exceptions even when SEF URLs are turned on.
Query Parameter. Everything after the
question mark in a non-SEF URL is called the URL query. You will
see a lot of key/value pairs, like
category=1:test and so on. The word at the left hand
side of the equals sign is called the Query
Parameter. The same-named parameter in WAF Exceptions
allows you to target a very specific query parameter. If you leave
it blank, all query parameters will be matched.
You can not leave all three options blank. That would match all components, all views and all query strings or, in other words, EVERY PAGE you access. This would imply that WAF would be effectively turned off. Admin Tools detects an attempt to do that and won't allow you to perform such a change.
The best way to understand WAF exceptions is by some practical examples.
Whole-component exception. Set
JCE Editor, leave view and query
parameter empty. This tells WAF that if it sees a request for JCE's
utility component (com_jce) is should turn off WAF no matter which
view or which query parameters are set. Essentially, WAF is turned off
for the entire JCE component.
Excepting a single component's
view. Let's say we want to disable WAF for all front-end
logins to avoid a complex password throwing a 403 error to our users.
Front-end logins are handled by com_user's login view. So just set
Users, view to
and leave the query parameter blank. WAF is now disabled for the
login/logout page of your site.
Excepting a query parameter of a specific
component and view. Let's say we have a com_foobar
component whose test view accepts a pass parameter. Strong passwords
may accidentally trigger WAF. Just create a new exception where
Foobar, view is
and query parameter is
pass. WAF will not deal with
that specific query parameter on that specific component and view, but
will be triggered by unsafe content passed in any other query
parameter on that particular view.
Excepting a query parameter across all
components and views. Let's say that you see a lot of 403s
in your site because various components use a password query parameter
to accept passwords and, as we mentioned above, complex passwords can
trigger WAF. Instead of hunting down all the views across all
components, you can simply leave component and view empty and set the
query parameter to
password. From now on, when WAF
sees a password parameter coming into Joomla! it will not try to apply
its protection filters against it. If other query parameters come in
with the user request they will be filtered and, if they contain
unsafe content, the request will still be blocked.