Barracuda Web Application Firewall Attack Definitions and Updates – Technical Overview

Druckfreundlich, PDF & E-Mail

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.

XSS becomes possible when user-supplied inputs are mixed together with the server response. If a malicious user supplies input that is reflected back and is executed by the browser as JavaScript, then (s)he can take control of the browser DOM. Such inputs can take the form of script tags, Data URI references, onEvent references, iframes, etc.

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.

What complicates matter somewhat is that the parsing engines of different browsers vary widely when recognizing JavaScript inside server responses. This allows for a lot of obfuscation strategies to the attacker, like embedding various characters in and around the event handlers. Some examples are embedding carriage returns, null breaks, newlines, encoded characters, extraneous brackets, comment tags, etc. to break up the input so that the security filters fail to block them but when they are reflected back to the browser they still get executed.

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:


Click here to enlarge

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.


Click here to enlarge

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.

Nach oben scrollen