This blog post elaborates on how the Barracuda rulesets operate and an overview of the associated auto-update mechanisms. For the purposes of this post, we will use cross-site scripting (XSS) examples.
The Barracuda Web Application Firewall XSS rulesets divides XSS signatures into categories. Each category contains a comprehensive list of all possible exploit violations under that category. One such category is for event based XSS covering events like onmouseover, oninput, onformchange, etc. A comprehensive list of these event handlers can be found at OWASP.
The XSS rulesets in the Barracuda Web Application Firewall attempts to handle all such obfuscations. Without giving the whole pattern away, the rulesets looks like the following under the ADVANCED > Internal Patterns page:
As mentioned above, all accommodations are made for different browser behaviors on different platforms and in different versions. The \xNN represent the hex values of the ASCII characters such as backspace (08), carriage return (0D), etc. The actual names of the event handlers do not show up here in the screenshot but can be viewed by clicking on the Details button in the actual UI.
Corner cases often come from legacy browsers or when new handlers are introduced such as in HTML5. Barracuda Labs continuously updates the patterns by monitoring the threat landscape and inputs from the security research community. When a pattern is updated the behavior differs slightly by model.
For Models 460 and below the modifications or new categories are applied in active mode, whereas for models 660 and above (or equivalent) they are applied in passive mode. In the later, the admin is expected to review the changes before applying them in active mode.
To find out the details of changes in an update definition, click on the Release Notes for the Attack Types.
In addition, irrespective of the model, you can change the behavior for new patterns from the ADVANCED > System Configuration page:
Another consideration in such patterns is the tradeoff between security and availability. A very strict pattern could block all on* events but that could block genuine inputs like one=xyz which is not an XSS attack.
That said, a pattern is also available to block all inputs which resemble on followed by 3 to 16 characters (along with all the other anti-evasion constructs). As you can see, this is a stricter pattern but could lead to false positives in some remote cases (e.g. an input which has onerously followed directly by an = sign).
The above discussion assumes a policy based on block lists for parameter inputs. Of course, when using allow-listing, either manually or via the automated profiler, such issues do not arise at all in the first place.
The ideal scenario is of course to fix to the code. However this becomes infeasible when the source code is not available, or there is a lack of expertise or resources to fix the code. The Barracuda Web Application Firewall rulesets and other advanced features provide a highly robust remediation mechanism against such application layer attacks without requiring any source code modifications.
For more information about the Barracuda Web Application Firewall, visit our corporate site here. You can get more information on deployment types, download whitepapers and data sheets, and order a risk-free, 30-day demo.