Help Center> Web Application Firewall> Best Practices> Configuring Protection Policies> Verifying a Global Protection Whitelist Rule by Simulating Requests with Postman
Updated on 2024-04-10 GMT+08:00
View PDF

Verifying a Global Protection Whitelist Rule by Simulating Requests with Postman

After your website is connected to WAF, you can use an API test tool to send HTTP/HTTPS requests to the website and verify that WAF protection rules take effect. This topic uses Postman as an example to describe how to verify a global protection whitelist rule.

Example

Assume that your workloads are deployed in the /product directory, and parameter ID contains scripts or rich text submitted by your customers. To ensure service running and improve WAF protection accuracy, you plan to mask false alarms generated for content submitted by the customers.

Prerequisites

  • You have connected the website you want to protect to WAF.
  • Basic Web Protection has been enabled and its Mode is Block. General Check has been enabled.

Procedure

  1. Download and install Postman.
  2. On Postman, set the request path to /product and parameter ID to a common test script and send the request. The access request to the protected website is blocked.

  3. Handle the false alarm.

    1. Log in to the management console.
    2. Click in the upper left corner of the management console and select a region or project.
    3. Click in the upper left corner and choose Web Application Firewall under Security & Compliance.
    4. In the navigation pane on the left, choose Events.
    5. On the Events page, WAF 010000 rule for XSS Attack is hit.
    6. In the row containing the event, click Handle as False Alarm.
    7. In the Handle False Alarm dialog box, add a global protection whitelist rule as shown in Figure 1.
      Figure 1 Add Global Protection Whitelist Rule
    8. Click OK.

      It takes about 5 minutes for a protection rule to take effect.

  4. On Postman, set the request path to /product and parameter ID to a common test script and send the request again. The access request to the protected website is blocked again.

  5. Handle the false alarms that hit the 110053 XSS attack rule by referring to Step 3.

    Figure 2 Add Global Protection Whitelist Rule

  6. On Postman, set the request path to /product and parameter ID to a common test script and send the request third time. The access request to the protected website is still blocked.

  7. Handle the false alarm that hits the 110060 rule for XSS attack by referring to Step 3.

    Figure 3 Add Global Protection Whitelist Rule

  8. On Postman, set the request path to /product and the parameter ID to a common test script and send the request forth time. In this case, the access request to the protected website is not blocked. All global protection whitelist rules have taken effect.

    Go to the Event page, no new XSS attack event is displayed.

  9. Simulate an attack on Postman to verify that the configured global protection whitelist rules do not stop WAF from blocking XSS attacks against other parameters.

    1. On Postman, set the request path to /product and parameter item to a common test script and send the request. The access request to the protected website is blocked.

    2. On the Events page, view the XSS attack against parameter item.

  10. Simulate an attack on Postman to verify that the configured global protection whitelist rules do not stop WAF from blocking XSS attacks against other paths.

    1. On Postman, set the request path to /order and parameter ID to a common test script and send the request. The access request to the protected website is blocked.

    2. On the Events page, view the event generated for blocked XSS attack against /order (URL) and parameter ID.