[WAF] Update payload logging (#22291)

Author: pedrosousa

src/assets/images/waf/transform-rules/payload-decrypted.png

@@ -3,14 +3,13 @@ title: Store decrypted matched payloads in logs
 pcx_content_type: how-to
 sidebar:
   order: 5
-
 ---
 
-import { GlossaryTooltip } from "~/components"
+import { GlossaryTooltip, RuleID } from "~/components";
 
 You can include the encrypted matched payload in your [Logpush](/logs/about/) jobs by adding the **General** > [**Metadata**](/logs/reference/log-fields/zone/firewall_events/#metadata) field from the Firewall Events dataset to your job.
 
-The payload, in its encrypted form, is available in the `encrypted_matched_data` property of the `Metadata` field.
+The payload, in its encrypted form, is available in the [`encrypted_matched_data` property](#structure-of-encrypted_matched_data-property-in-logpush) of the `Metadata` field.
 
 However, you may want to decrypt the matched payload before storing the logs in your <GlossaryTooltip term="SIEM">SIEM system</GlossaryTooltip> of choice. Cloudflare provides a [sample Worker project](https://github.com/cloudflare/matched-data-worker) on GitHub that does the following:
 
@@ -21,3 +20,65 @@ However, you may want to decrypt the matched payload before storing the logs in
 You will need to make some changes to the sample project to push the logs containing decrypted payload data to your log storage system.
 
 Refer to the Worker project's [README](https://github.com/cloudflare/matched-data-worker/blob/main/README.md) for more information on configuring and deploying this Worker project.
+
+## Structure of `encrypted_matched_data` property in Logpush
+
+Matched payload information includes the specific string that triggered a rule, along with some text that appears immediately before and after the matched string.
+
+Once you decrypt its value, the `encrypted_matched_data` property of the `Metadata` field in Logpush has a structure similar to the following:
+
+```json
+{
+	// for fields with only one match (such as URI or user agent fields):
+	"<match_location>": {
+		"before": "<text_before_match>",
+		"content": "<matched_text>",
+		"after": "<text_after_match>"
+	},
+	// for fields with possible multiple matches (such as form, header, or body fields):
+	"<match_location>": [
+		{
+			"before": "<text_before_match_1>",
+			"content": "<matched_text_1>",
+			"after": "<text_after_match_1>"
+		},
+		{
+			"before": "<text_before_match_2>",
+			"content": "<matched_text_2>",
+			"after": "<text_after_match_2>"
+		}
+	]
+}
+```
+
+The `before` and `after` properties are optional (there may be no content before/after the matched text) and will contain at most 15 bytes of content appearing before and after the match.
+
+Below are a few examples of payload matches:
+
+```json title="URI match"
+{
+	"http.request.uri": {
+		"before": "/admin",
+		"content": "/.git/",
+		"after": "config"
+	}
+}
+```
+
+```json title="Header value match"
+{
+	"http.request.headers.values[3]": [
+		{ "content": "phar://", "after": "example" }
+	]
+}
+```
+
+```json title="Raw body content match"
+{
+	"http.request.body.raw": {
+		"before": "NY>",
+		"content": "<!ENTITY xxe SYSTEM \"file:///dev/random\">] > ",
+		"after": "<foo>&xxe;</foo>"
+	}
+}
+```

src/assets/images/waf/transform-rules/payload-logging-example.png

@@ -7,12 +7,12 @@ sidebar:
 
 import { GlossaryTooltip } from "~/components";
 
-The WAF allows you to log the request information that triggered a specific rule of a managed ruleset. This information is known as the payload. Payload logging is especially useful when diagnosing the behavior of WAF rules. Since the values that triggered a rule may contain sensitive data, they are encrypted with a customer-provided public key so that only you can examine them later.
+The WAF allows you to log the request information that triggered a specific rule of a managed ruleset. This information is known as the payload. Payload information includes the specific string that triggered the rule, along with the text that appears immediately before and after the match.
 
-:::note
+Payload logging is especially useful when diagnosing the behavior of WAF rules. Since the values that triggered a rule may contain sensitive data, they are encrypted with a customer-provided public key so that only you can examine them later.
 
+:::note
 This feature is only available for customers on an Enterprise plan.
-
 :::
 
 ## Turn on payload logging

src/content/docs/waf/managed-rules/payload-logging/decrypt-in-logs.mdx

@@ -11,18 +11,16 @@ View the content of the matched rule payload in the dashboard by entering your p
 
 2. Under **Sampled logs**, expand the details of an event triggered by a rule whose managed ruleset has payload logging enabled.
 
-3. Under **Payload match**, select **Decrypt payload log**.
+3. Under **Matched service**, select **Decrypt payload match**.
 
    ![Example of a firewall event with available payload match data (still encrypted)](~/assets/images/waf/transform-rules/payload-logging-example.png)
 
-   The **Payload match** section is not available if the action taken by the matched rule is _Log_.
-
 4. Enter your private key in the pop-up window and select **Decrypt**.
 
    :::note
    The private key is not sent to a Cloudflare server. The decryption occurs entirely in the browser.
    :::
 
-If the private key you entered decrypts the encrypted payload successfully, the **Payload match** card displays the payload content in clear text.
+If the private key you entered decrypts the encrypted payload successfully, the dashboard will show the name of the fields that matched and the matched string in clear text, along with some text appearing before and after the match.
 
 ![Viewing the decrypted payload match data after entering your private key in the dashboard](~/assets/images/waf/transform-rules/payload-decrypted.png)