What is Check Fields; into which seven parts does the WAF split a request to inspect it?

Short answer

Check Fields is the detail panel that shows with which rules a page type (WAF rule) inspects the request; it divides the request into seven sections, Path, Query, Header, JSON, Xml, Form and Raw, and every tab shows and opens for editing only the inspections of its own section (the tabs and the section they inspect). While signature scanning looks for known attack patterns, Check fields carries the positive security side: it defines which parameters the request coming to the path can carry, and their length, number and format. Every structural violation is 24 points; since this score is also equal to the loosest OWASP Protection Level threshold, a single violation blocks the request in Blocking mode. Structural inspections run only in the Blocking and Monitor modes; the inspections are mostly learned with Analysis & Learning.

How Does It Work?

1. When a request comes, its path is matched with the rules in the Page Types list; the request is inspected with the inspections of the matching rule.
2. The Path inspections of the rule (allowed methods, path length and depth) and the query and header inspections are applied to every request, independently of the body.
3. In a request that has a body, Content-Type determines which body tab comes into play: types in the …/json or …+json form go through the inspections of the JSON tab, types in the …/xml or …+xml form through those of the Xml tab, and application/x-www-form-urlencoded and multipart/form-data through those of the Form tab. Types other than these go through the inspections of the Raw tab; a JSON or XML body that cannot be parsed, and a form body that cannot be parsed while Block Invalid Form Contents is off, are left to the signature scanning of the Raw tab. The Raw Body Size limit is applied to every body, independently of the body type (What does the Raw tab inspect; what happens to content that cannot be parsed?).
4. Every violation adds 24 points to the attack score of the request and appears in the Attacks tab of the Event Logs record with the name of the rule (e.g. Query value length) and the violation detail.

Seven Sections

The tab labels are given as they are written in the interface (the tabs and the section they inspect).

Tab	Section it inspects	Argument rule unit	Main fields
Path	Request line	None (only the rule itself)	Allowed methods, Path length, Path depth, OWASP check
Query	Query string	Parameter name	Allowed Query Parameters, Required Query Parameters, Query Value Length, Query Value Pattern
Header	Request headers	Header name	Total Header Size, Required headers, Header Value Count
JSON	JSON body	Key path (user.name)	Allowed JSON Keys, JSON depth, Block Invalid JSON Contents
Xml	XML body	Element or attribute path (user._attr.type)	Allowed XML Keys, XML depth, Block All XML Contents
Form	Form body and file upload	Field name	Required Form Fields, Allowed Upload Mime Types, OWASP Check in Upload
Raw	Raw body	None (only the common rule)	Raw Body Size, Block Unparsed Contents, Allowed Raw Body Mime Types

• The Query, Header, JSON, Xml and Form tabs have two layers: the common rule applied to all the fields of the section and the argument rule opened for a single name (two layers). The Path and Raw tabs have no variable table.
• The tabs for which the rule defines its own inspection appear distinct in the panel, and the ones it does not define appear pale; the inspections of a pale tab may have been inherited from the glob rule that matches the path or from the Any Paths rule (How do inheritance and "Rule Source" work in rules?).

Check Fields in TR7

• Where it is seen: Left Monitor Panel → WAF-Protected vServices → vService → WAF Management → the N page types row of the host group → the rule in the list is clicked; the detail panel opens on the right (accessing the panel). The Check Fields column in the Page Types list lists the sections the rule defines itself.
• Main switches: Most of the inspections depend on the vService-wide Structure Checks and Argument Checks switches; both come on when WAF is turned on (What do the Structure Checks and Argument Checks master switches do; what happens if I turn them off?).
• Path values: The values in the Path tab are not a separate part but the rule itself; the Edit Common Rule for Path button opens the Edit form of the rule.
• Applying: With the save, the change is applied without a separate deployment step; in a cluster setup, it is also sent to the peer device with the default auto-sync, and if Manual Sync Mode is on, it is sent to the peer device manually.

Common Misconceptions

• "Check fields is a signature list." The signatures are in the Signature & Rule Library; Check fields are positive inspections that define the expected shape of the request. The OWASP Check field in every tab only determines whether signature scanning is on in that section.
• "There is no inspection in a pale tab." The rule has no definition of its own for that section; the inspection that comes from the glob rule or from the Any paths rule runs.
• "Structural violations are blocked in Learning mode as well." In Learning mode, structural inspections are not run, signature hits are not added to the score and no blocking decision is made; in Monitor mode, the violation is recorded but the request is let through (WAF modes).

How it is done in the documentation

• Path Check Fields · The Tabs and the Section They Inspect
• Path Check Fields · Two Layers: The Common Rule and the Argument Rule
• Path Check Fields · The Main Switches of the Inspections
• WAF Rules · Runtime: Rule Matching

Related questions

• What are the basic building blocks of TR7 WAF (WAF Mode, Virtual Host Group, Page Types, Any Paths, Check Fields, Signature)?
• What is the difference between the negative security model (signature scanning) and the positive security model?
• What is the attack score and how is it calculated?