XML

What Is XML?

XML shows the inspections applied to the request bodies whose content type is XML. The tab consists of two layers: at the top the common rule applied to all the XML content, at the bottom the variable table in which the argument rules specific to certain elements or attributes are listed.

What Is an XML Body?

The XML inspections work in the requests that have a body and whose content type points to XML (application/xml, text/xml and the types with the +xml suffix). The body is parsed and the elements and the attributes are evaluated in a tree structure: the names are referred to with dotted paths joined with . for the nested levels, the attributes are represented with the _attr node below the element (for example, in the user element the type attribute with the user._attr.type path). The measurements are made in UTF-8 bytes; since all the values in XML are text, the value inspections are applied both to the element contents and to the attribute values. The XML comments and the processing instructions are not evaluated as content. Every one of the inspections in this tab targets a certain element of the body:

An example body:

<user type="admin">
  <name>john</name>
  <address>
    <city>london</city>
  </address>
</user>

Element	Its counterpart in the example	The related inspections
The element and attribute names	user, name, address, city, type	XML Key Length
The dotted paths of the names	user.name, user.address.city, user._attr.type	Allowed XML Keys, the argument rules
The text values	john, london and the attribute value admin	XML Value Length, XML Value Pattern, OWASP Check
The number of values (leaves)	3	XML Key Count
The nesting depth	3 for london, the deepest value; the attribute values count as one level deeper because of the _attr node	XML Depth

Accessing the Screen

1. The rule is clicked in the Page Types list; the detail panel of the rule opens on the right.
2. The XML tab is clicked in the tab strip of the panel.

For the title elements of the panel and the behavior of the tab strip see Path. The value displays in the table also use the same form as in the Path tab: if there is no restriction No Restriction, the one-way restrictions ≤ n / ≥ n, the ranges [a - b], and the fields that are on/off are seen as ✓ / -.

The Detail Panel - The XML Tab

The inheritance and Rule Source

If the rule has not defined its own XML inspection, the values 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 (for example Any Paths). If the rule defines its own XML inspection, the Rule Source row is not present.

The Add Common Rule for XML Screen

When the green plus icon Add common rule for Xml button above the table is clicked, the form that defines the rule's own XML common inspection opens; with the save, the inheritance ends for that rule. If the rule already has its own XML inspection, the same button is seen as the pencil icon Edit common rule for Xml (it opens the form with the current values) and Delete common rule for Xml (it removes the common rule without asking a confirmation question). The add form does not open empty; it comes pre-filled with the related inspection values of the Any Paths rule. In the Any Paths rule itself, on the other hand, there is no delete button: the common inspection of the catch-all rule cannot be removed.

This screen is at the same time the edit screen: whether the common inspection has been added manually or has been formed by the learning, the form that opens with the Edit common rule for Xml button shows the same fields below with the current values of the rule.

The Add Common Rule for XML Screen

INFO

Virtual Host Group

The host group to which the inspection will be added is shown as read-only; it is determined according to which group's Page Types screen the panel is opened from and cannot be changed from the form.

INFO

Path

The path of the rule to which the inspection will be added is shown; the form is bound to the rule for which the detail panel has been opened.

INFO

Area

It shows to which section of the request the inspection is applied. The field is locked to the tab the form is opened from: when the form is opened from the XML tab, it comes as Xml and cannot be changed.

INFO

Argument Name

It shows the scope of the inspection. In the common rule form this field is locked as Any Arguments and the fields are applied to all the XML content; a rule specific to a certain element or attribute, on the other hand, is defined from the Add Argument Rule for XML screen. The name is written as the full dotted path: in the user.name form for an element, in the user._attr.type form for an attribute value.

If a path has its own argument rule, the value inspections of that path (XML Value Length, XML Value Pattern, OWASP Check, Detailed Log) are taken entirely from this rule; the value inspections of the common rule are no longer applied to that path. The section-wide inspections (XML Key Length, XML Key Count, XML Depth, Allowed XML Keys), on the other hand, continue to be applied. Defining a rule specific to a path does not add that path to the Allowed XML Keys list by itself.

INFO

XML Key Length

The length restriction of the element and attribute names in the body is defined; every different name is measured once in UTF-8 bytes:

Option	Meaning
No Restriction	No length restriction is applied.
Less Than or Equal To	The length must be equal to or below the entered value.
Equals To	The length must be equal to the entered value.
Greater Than or Equal To	The length must be equal to or above the entered value.
Range	The length must be between the two entered values (the limits included).

Only a number can be entered in the value field. Every name that does not comply with the restriction is scored as an XML Key Length violation in the Structure Limits category and falls into the attack record.

INFO

XML Key Count

The restriction of the number of values (leaves) in the body is defined: what is counted is not the element names but the text values at the end of the tree (the element contents and the attribute values). Every text of the repeating sibling elements is counted separately; the empty elements that have no content do not enter the counting:

Option	Meaning
No Restriction	No number restriction is applied.
Less Than or Equal To	The number of values must be equal to or below the entered value.
Equals To	The number of values must be equal to the entered value.
Greater Than or Equal To	The number of values must be equal to or above the entered value.
Range	The number of values must be between the two entered values (the limits included).

Only a number can be entered in the value field. A request that does not comply with the restriction is scored as an XML Key Count violation in the Structure Limits category and falls into the attack record.

INFO

Block All XML Contents

When it is checked, every request whose content type is XML and that carries a body is scored as a Block All XML Contents violation in the Structure Policies category without the body being parsed. It is used for the paths that do not accept an XML body.

INFO

Block Invalid XML Contents

When it is checked, the bodies that cannot be parsed as XML (unbalanced or unmatching tags, broken syntax) are scored as a Block Invalid XML Contents violation in the Content Integrity category. While it is not checked, a body that cannot be parsed is not left uninspected; it is passed through the RAW signature scanning as raw content.

INFO

XML Depth

The nesting depth restriction of the body is defined; every element layer around the value counts as one level and the attribute values are one level deeper than the element they are in, because of the _attr node:

Option	Meaning
No Restriction	No depth restriction is applied.
Less Than or Equal To	The depth must be equal to or below the entered value.
Equals To	The depth must be equal to the entered value.
Greater Than or Equal To	The depth must be equal to or above the entered value.
Range	The depth must be between the two entered values (the limits included).

Only a number can be entered in the value field. A request that does not comply with the restriction is scored as an XML Depth violation in the Structure Limits category and falls into the attack record.

INFO

Allowed XML Keys

The list of the allowed paths is defined (a positive list). The names are entered as the full dotted path, using . for every depth and are compared case sensitively. The list must contain not only the paths that carry a value but the container paths as well: for the body in the example the intermediate element paths (user, user.address) must be listed too; for the elements that carry an attribute, both the _attr container (user._attr) and the attribute path (user._attr.type) must additionally be in the list. While the field is in the No Restriction position, all the paths are allowed; when the restriction is turned on, every different path that is not in the list is scored as an Allowed XML Keys violation in the Structure Policies category and falls into the attack record.

There is no required key list for XML; the Required field in the Query and Form sections has no counterpart in XML. Defining an argument rule specific to a path does not add that path to this list by itself.

INFO

XML Value Length

The length restriction of the text values is defined. The restriction is applied to every value (the element contents and the attribute values) separately, in UTF-8 bytes:

Option	Meaning
No Restriction	No length restriction is applied.
Less Than or Equal To	The value length must be equal to or below the entered value.
Equals To	The value length must be equal to the entered value.
Greater Than or Equal To	The value length must be equal to or above the entered value.
Range	The value length must be between the two entered values (the limits included).

Only a number can be entered in the value field. Every value that exceeds the restriction is scored as an XML Value Length violation in the Structure Limits category and falls into the attack record.

INFO

OWASP Check Default: Checked

When it is checked, every element and attribute name and every value in the parsed body are subjected to the OWASP signature scanning separately; for XML it is checked by default. The signature hits, differently from the structural violations, take part in the attack score by accumulating with their own scores. In the scanning, the signature set that is enabled on the OWASP Rules screen of the vService is used; for the listing of the signatures see Signature & Rule Library.

OWASP Exclusions

With this field that appears in the form when the box is checked, the OWASP rules to be excluded from the scanning are determined with a multiple selection; while the box is not checked, the field is not seen, and when no selection is made, Nothing chosen is written in the field. When an exclusion is defined, the number of the exclusions is shown next to the ✓ mark in the OWASP Check row in the detail panel.

INFO

Detailed Log Default: Checked

It manages the log detail of the signature (OWASP) hits; it is checked by default. While it is on, the matching content is shown together with its surrounding context in the Event Logs record; while it is off, the record still falls but instead of the content the phrase Detailed log disabled is seen. The summary information of the structural violations is always written independently of this setting.

INFO

XML Value Pattern

The regular expression (regex) pattern the text values must match is defined. The inspection is positive: when the value does not match the pattern, an XML Value Pattern violation is produced in the Structure Policies category and the value itself is seen in the attack record. The pattern is searched anywhere in the value; if it is wanted that the whole of the value match, the pattern should be bounded with ^ and $. With the aA button next to the field the matching can be made case insensitive; this option is seen in the detail panel as the (-i) suffix next to the pattern. If no pattern is defined, no pattern inspection is applied to the value content.

INFO

Add

The common rule adding operation is completed by clicking the Add button; the button becomes enabled when no error remains in the form. There is no additional confirmation window or deployment (deploy) step; the WAF configuration is automatically produced again and applied and the values in the panel are updated instantly.

The mode behavior and the scoring

The structure inspections in this tab work only in the Blocking and Monitor modes; they are not run in the Learning mode, instead the restriction suggestions are learned from the observed traffic. The structural violations have a high score; at the default blocking threshold a single violation is enough for the request to be blocked in the Blocking mode (in the Monitor mode it is reported as an attack but the request is let through). The OWASP signature hits, on the other hand, reach the threshold by accumulating with their own scores.

The bodies that exceed the buffer

When the body is too big to fit into the inspection buffer, the XML inspections cannot be run; in this case the behavior is determined by the Block Unparsed Contents setting in the RAW tab.

The Add Argument Rule for XML Screen

The Argument table below the common rule lists the argument rules specific to certain element or attribute paths; with the search box of the table a filtering can be done over the path. The argument rules the rule defines itself are shown in bold, the inherited ones in italic. When the green plus icon Add argument rule for Xml button above the table is clicked, the form that defines an inspection specific to a single path opens.

When a row in the table is clicked, the detail of the argument rule opens below it; in the rule's own argument rule the pencil icon Edit (it opens the form with the current values) and trash can icon Delete (it removes the argument rule without asking a confirmation question) buttons are seen. In the inherited rows these buttons are not present; an inherited rule can be edited only from the rule that is its source.

In the rules specific to a path the add form does not open empty; the inspection fields come pre-filled with the common XML inspection values of the Any Paths rule. In the Any Paths rule itself, on the other hand, the form opens with the field defaults. This screen is at the same time the edit screen: the form that opens with the Edit button shows the same fields below with the current values of the rule; in the editing, differently from the add form, the Argument Name field is also locked; to which path the rule is bound cannot be changed afterwards. The repetition limit field in Query and Header (Value Count) has no XML counterpart; this field does not take place in the form.

The Add Argument Rule for XML Screen

INFO

Virtual Host Group

The host group to which the inspection will be added is shown as read-only; it is determined according to which group's Page Types screen the panel is opened from and cannot be changed from the form.

INFO

Path

The path of the rule to which the inspection will be added is shown; the form is bound to the rule for which the detail panel has been opened.

INFO

Area

It shows to which section of the request the inspection is applied. The field is locked to the tab the form is opened from: when the form is opened from the XML tab, it comes as Xml and cannot be changed.

INFO

Argument Name

The path to which the rule will be bound is defined. The scope selector is locked as One Argument in this form; the path is entered in the text box next to it and cannot be left empty (if it is left empty, the Enter argument name error is seen). The path is written as the full dotted path joined with . for the nested levels and is matched exactly and case sensitively: the user.name form is used for an element content, the user._attr.type form for an attribute value; an entry that contains only the last piece (name) does not catch the nested element. Since the repeating elements are gathered under a single path, the rule bound to the user.roles.item path is applied to every repeating item element.

A second argument rule with the same path cannot be added; on an attempt the part collision error is returned. In the edit form this field cannot be changed; if the rule is wanted to be moved to another path, it must be deleted and added again.

INFO

XML Value Length

The length restriction of the text values of the path is defined. The restriction is applied to every value (an element content or an attribute value) separately, in UTF-8 bytes:

Option	Meaning
No Restriction	No length restriction is applied.
Less Than or Equal To	The value length must be equal to or below the entered value.
Equals To	The value length must be equal to the entered value.
Greater Than or Equal To	The value length must be equal to or above the entered value.
Range	The value length must be between the two entered values (the limits included).

Only a number can be entered in the value field. Every value that exceeds the restriction is scored as an XML Value Length violation in the Structure Limits category and falls into the attack record.

INFO

OWASP Check Default: Checked

When it is checked, the name and every value of the path are subjected to the OWASP signature scanning separately; it is checked by default. When the box is removed, the path goes out of the signature scanning entirely together with the element or attribute name and its values; this is the way of exempting from the scanning a field that frequently produces false positives. In the scanning, the signature set that is enabled on the OWASP Rules screen of the vService is used; for the listing of the signatures see Signature & Rule Library.

OWASP Exclusions

With this field that appears in the form when the box is checked, the OWASP rules to be excluded from the scanning are determined with a multiple selection; while the box is not checked, the field is not seen, and when no selection is made, Nothing chosen is written in the field. The exclusions are applied only to the scanning of this path; the other paths continue to use the exclusion list of the common rule.

INFO

Detailed Log Default: Checked

It manages the log detail of the signature (OWASP) hits; it is checked by default. While it is on, the matching content is shown together with its surrounding context in the Event Logs record; while it is off, the record still falls but instead of the content the phrase Detailed log disabled is seen. The summary information of the structural violations is always written independently of this setting.

INFO

XML Value Pattern

The regular expression (regex) pattern the text values of the path must match is defined. The inspection is positive: when the value does not match the pattern, an XML Value Pattern violation is produced in the Structure Policies category and the value itself is seen in the attack record. The pattern is searched anywhere in the value; if it is wanted that the whole of the value match, the pattern should be bounded with ^ and $. With the aA button next to the field the matching can be made case insensitive; this option is seen in the detail panel as the (-i) suffix next to the pattern. If no pattern is defined, no pattern inspection is applied to the value content.

INFO

Add

The argument rule adding operation is completed by clicking the Add button; the button becomes enabled when no error remains in the form. There is no additional confirmation window or deployment (deploy) step; the WAF configuration is automatically produced again and applied and the values in the table are updated instantly.

An empty field does not mean inheriting from the common rule

When the argument rule is saved, the value inspections of the path are taken entirely from this rule; the value inspections of the common rule are no longer applied to that path. The pre-filling in the form is only a starting convenience: after the save the fields are independent of the common rule and a field left empty (for example XML Value Pattern) does not return to the value in the common rule, it means no restriction for that inspection. The section-wide inspections (XML Key Length, XML Key Count, XML Depth, Allowed XML Keys), on the other hand, are not affected by the argument rule and continue to be applied; an argument rule cannot exempt a path from these inspections or from the Allowed XML Keys list.

The inheritance and the learning

The argument rules are also inherited according to the rule matching priority: if the rule has not defined its own argument rule for a path, the argument rule with the same path of the glob rule that matches the path or of the Any Paths rule becomes valid. The inherited rules are listed in italic in the table; in their detail the Rule Source row shows the path the rule comes from. When the rule defines its own argument rule for the same path, the inherited rule stays invalid for that rule.

Differently from Header, the XML inspections are learned per path. The learning (Conditional Learning, AI Learning, Teacher and teaching over Event Logs) writes the updates to the argument rule if there is one with the path on which the violation occurred; for example an exclusion is added to the OWASP Exclusions list or the length limit is widened. An XML Value Pattern that produces false positives, on the other hand, is not narrowed but cleared entirely. If the path has no argument rule, the change is written to the common rule; the learning does not create a new argument rule by itself.