RAW

What Is RAW?

RAW shows the inspections applied to the raw (unparsed) state of the request body. Like the Path tab, RAW too consists only of the common rule: in this section there is no variable (argument) table, all the settings are kept in a single table.

What Is a Raw Body?

The JSON, XML and Form bodies are processed by being parsed with the inspections in their own tabs; all the other content types (plain text, binary data, unknown types) are inspected within the RAW scope. Two of the RAW inspections, on the other hand, are independent of the content type: Raw Body Size works in every request that carries a body, and Block Unparsed Contents determines the fate of the bodies that do not fit into the inspection buffer. Additionally, the JSON, XML and Form bodies that cannot be parsed in their own tab fall into the RAW signature scanning as raw content; the multipart form bodies are also passed through the RAW signature scanning as a safety net (as long as OWASP Check is on in this section).

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 RAW 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 RAW Tab

The inheritance and Rule Source

If the rule has not defined its own RAW 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 RAW inspection, the Rule Source row is not present.

The Add Common Rule for Raw Screen

When the green plus icon Add common rule for Raw button above the table is clicked, the form that defines the rule's own RAW common inspection opens; with the save, the inheritance ends for that rule. If the rule already has its own RAW inspection, the same button is seen as the pencil icon Edit common rule for Raw (it opens the form with the current values) and Delete common rule for Raw (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 Raw button shows the same fields below with the current values of the rule.

The Add Common Rule for Raw 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 RAW tab, it comes as RAW and cannot be changed. Since there is no argument rule in the RAW section, the Argument Name field does not take place either.

INFO

Raw Body Size

The restriction of the declared total size of the request body (the Content-Length header) is defined, in bytes. The inspection works, independently of the content type, in every request that carries a body and before all the body inspections; the requests that have no body do not enter this inspection at all, and for this reason the lower-limit restrictions do not catch the requests without a body:

Option	Meaning
No Restriction	No size restriction is applied.
Less Than or Equal To	The body size must be equal to or below the entered value.
Equals To	The body size must be equal to the entered value.
Greater Than or Equal To	The body size must be equal to or above the entered value.
Range	The body size 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 a Raw Body Size violation in the Structure Limits category and falls into the attack record.

INFO

Block Unparsed Contents

It is a two-position switch that determines the fate of the requests that stay unparsed because their body does not fit into the inspection buffer. The tooltip of the field (Maximum parsable body size) shows the biggest body size that can be processed; this limit comes from the greater of the Buffer Size value in the limit profile of the vService and the Max. Body Size to Process value in the WAF options:

• Block Unparsed Body: a request that carries a body exceeding the buffer is scored as a Block Unparsed Contents violation in the Content Integrity category.
• Allow Unparsed Body: a body that exceeds the buffer is forwarded to the Backend Service without any inspection being run on it.

None of the JSON, XML, Form and RAW inspections can be applied to the bodies that exceed the buffer; this switch decides whether the content that cannot be inspected will be blocked or not.

INFO

Block Unexpected Parser Errors

When it is checked, if the inspection engine encounters an unexpected error while processing a request, the request is scored as a Block Unexpected Parser Errors violation in the Content Integrity category and the error summary falls into the attack record. While it is not checked (the default), in the case of an error the remaining inspections are skipped and the request is let through; the violations produced up to the moment of the error are still scored.

INFO

Allowed Raw Body Mime Types

The list of the allowed content types of the bodies inspected within the RAW scope is defined; it is not applied to the bodies processed as JSON, XML and Form. The type is detected from the body content, not from the content type header the request declares; the allow entries match with the detected type as a substring and must be written in lower-case letters. While the list is empty, no restriction is applied; while the restriction is on, every body that does not comply with the list is scored as an Allowed Raw Body Mime Types violation in the Structure Policies category and the detected type is seen in the attack record.

The default configuration of the Any Paths rule comes with an allow list consisting of the following two types:

text/plain
application/octet-stream

These two types are the two general results of the content detection: text/plain meets the plain text that does not comply with a certain format, application/octet-stream the unrecognized binary data. That is, in the default behavior the ordinary text and the unrecognized binary bodies pass; the bodies from whose content a certain type is detected (for example HTML or ZIP) produce a violation.

INFO

OWASP Check

When it is checked, the whole of the body in a single piece and in its raw state that falls within the RAW scope is subjected to the OWASP signature scanning. Since the JSON and XML bodies pass through the parsed scanning of their own tabs, this scanning is especially meaningful for the content types that are not parsed. 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.

The file contents scanned with OWASP Check in Upload in the Form tab also use the OWASP configuration of this section (including its exclusions and the Detailed Log setting).

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 (the size comparison, the detected content type) is always written independently of this setting.

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.

Runtime: The RAW Inspection Order

A request that carries a body passes through three stages in terms of RAW:

01 · SizeRaw Body SizeIndependently of the content type, the declared body size is inspected in every request that carries a body.

02 · BufferBlock Unparsed ContentsA body that does not fit into the buffer cannot enter any other inspection; this switch makes the decision of blocking or letting through without processing.

03 · ContentMime + OWASPIn the bodies that are not processed as JSON, XML or Form, the content type detection and the raw signature scanning are done.

The bodies processed as JSON and XML do not enter the third stage; they continue with the inspections of their own tabs. The multipart form bodies, even if the parsing is successful, additionally pass through the signature scanning of the third stage as a safety net. The bodies that cannot be parsed in their own tab, on the other hand, return to the signature scanning of the third stage as raw content.

The mode behavior and the scoring

The structure inspections in this tab are scored in the Blocking and Monitor modes; in the Learning mode no scoring is done, 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.