Path Check Fields

Path Check Fields is the detail panel that shows how a page type (WAF rule) inspects the request. When a rule is clicked in the Page Types list, the panel opens on the right and divides the request into seven sections: Path, Query, Header, JSON, XML, Form and RAW. Every tab reads and opens for editing only the inspections that belong to its own section of the request.

This division carries the positive security side of WAF. While the signature scanning answers the question "is there a known attack pattern in this request?", the field inspections answer the question "can the request coming to this path carry this parameter, can it be of this length, can it contain these characters?". The shape of the request the application expects is defined tab by tab; every deviation from the shape is added to the attack score of the request and when the score reaches the blocking threshold, the request is blocked in the Blocking mode.

Where do the inspections come from?

The field inspections are mostly not written manually: Analysis & Learning examines the past traffic and derives the expected parameters, the value lengths and the value patterns for every path. This panel is the place where the learned shape is read and, when necessary, corrected manually.

Accessing the Panel

The Page Types list of a host group is opened.
A rule is clicked in the list; the detail panel of the rule opens on the right. When another rule is passed to, the panel shows the information of that rule, and when the highlight of the row is removed, it closes. The panel has no separate close button. This highlight is independent of the row check box that enables the Edit and Delete operations on the toolbar.

In the panel title there is the path of the rule (the Any Paths label in the catch-all rule), and below it the name of the host group and the copy icon that copies the path to the clipboard. The Edit and Delete buttons in the title do the same as the Edit and Delete operations on the toolbar.

The tab set is the same for every rule; the tabs for which the rule defines its own inspection are shown distinct, the ones it does not define pale. A pale tab may not be empty: its content may have been inherited. The panel comes with the Path tab at the first opening; at the following openings the last viewed tab is remembered (this preference is not per rule but per user).

The exact spelling of the tab labels

In the interface the tabs are written as Path, Query, Header, JSON, Xml, Form and Raw. In this document the XML and RAW forms are used for readability.

The Tabs and the Section They Inspect

Tab	The inspected section of the request	The variable unit
Path	The request line: the HTTP method, the path length and depth, the signature scanning of the path content.	None (only the common rule)
Query	The query string (`?user=john&lang=en-US`).	The query parameter name
Header	The request headers.	The header name
JSON	The request body whose content type is JSON.	The JSON key path
XML	The request body whose content type is XML.	The XML element or attribute path
Form	The requests that carry a form body and the file uploads.	The form field name
RAW	The raw (unparsed) state of the body: its size, its content type and the fate of the content that cannot be parsed.	None (only the common rule)

The body tabs come into play according to the content type of the request: a request with a JSON body passes through the inspections of the JSON tab, a request with a form body through the inspections of the Form tab. The fate of a body that fits no parser or that cannot be parsed, on the other hand, is determined by the RAW tab.

Two Layers: The Common Rule and the Argument Rule

The Query, Header, JSON, XML and Form tabs consist of two layers:

The common rule The whole of the section

They are the inspections applied to all the fields the tab covers: the number of fields, the key length, the allowed fields and, according to the tab, the required fields, the total size or the nesting depth, the validity of the body format and the general restrictions on the value. Which inspection is in which tab is detailed on the tab pages. It is shown in the upper table of the tab.

The argument rule A single field

They are the inspections specific to a single parameter, header, key or form field whose name is given: the value length of that field, the pattern its value must match, how many times at most it can be repeated, whether the signature scanning is on for that field and whether it will be written to the detailed log. They are listed in the variable table below the common rule.

In the Path and RAW tabs there is no variable table; these two tabs consist only of the common rule.

The argument rule does not inherit the value inspections of the common rule

When an argument rule is defined for a field, all the value inspections of that field are taken from this rule; the value inspections of the common rule are no longer applied to that field. The pre-filling in the form is only a starting convenience: a field left empty after the save does not return to the value in the common rule, it means no restriction for that inspection. The section-wide inspections such as the number of fields and the total size, on the other hand, are not affected by the argument rule and continue to be applied.

The Inheritance and Rule Source

A rule does not have to define its own inspection for a tab. If it has not defined one, the inspections are inherited from the glob rule that matches the path or from the Any Paths rule according to the rule matching priority:

The Rule Source row at the end of the table shows the path of the rule the inspections come from. If the rule defines its own inspection, this row is not present.
In the variable table the rows the rule defines itself are shown in bold, the inherited ones in italic. In the inherited rows there are no edit and delete buttons; an inherited rule is edited only from the rule that is its source.
The moment the rule defines its own common rule or its own argument rule with the same name, the inheritance ends for that rule.

The Path tab is outside this behavior: the path inspections are not inherited, they always belong to the rule itself. The reason for this is that the common rule in the Path tab is not a separate inspection piece but the rule itself.

The panel shows the inheritance only in the full path rules

The inherited rows and the Rule Source row are displayed only in the panel of the exact (full path) rules. In the panel of a glob rule no inherited row is seen; yet at runtime the request is again completed with the Any Paths rule. To see with which inspections a glob rule actually works, the same tab of the Any Paths rule should be looked at as well.

The Main Switches of the Inspections

The greater part of the inspections in the tabs depends on two main switches across the vService. When one of the switches on the Checks screen is turned off, the related inspections are not produced at all and the fields of these inspections are hidden in the rule forms and in the detail panel. The values in the rules are not deleted; when the switch is turned on again, they come into play with the same values.

The scope of the two switches is different from what their names suggest:

Switch	The inspections it covers
Structure Checks	The key length and number, the total size, the depth, the validity of the body format and all the inspections on the field value: the value length, the value pattern, the maximum repetition.
Argument Checks	Only the allowed field lists and the required field lists.

The practical result of this distinction is the following: when Argument Checks is turned off, the argument rules are not lost, only the field lists are disabled. In contrast, when Structure Checks is turned off, all the value inspections of the argument rules fall as well.

Some inspections are entirely independent of these switches and are always produced: the allowed methods, the switches that block the body type outright, the MIME type lists and the unparsable body and unexpected error inspections in the RAW tab.

The inspections that are dropped silently

The two numeric limits on the Checks screen make the rule ineffective without a warning when they are exceeded: if the allowed field list of a rule exceeds the Max. Allowed Arguments value, that list is dropped entirely, and if the OWASP exclusions exceed the Max. OWASP Exclusions value, the signature scanning of that field is turned off. The values continue to be seen in the rule but are not applied.