Workflow Detection (Value Added Services)

By analyzing the distribution of client access resource types over a period of time, or setting pre request conditions and restrictions, requests that do not meet normal workflow can be disposed of. Workflow Detection supports the following typical scenarios:

Web: For the hostname that dynamic and static files are not separated, the distribution of resource types accessed by normal users is usually scattered. To improve efficiency, bots usually only visit dynamic interfaces and do not request static resources. Using this mechanism, Workflow Detection will analyze the distribution of client access resource types over a period of time, identify requests that do not conform to normal workflow, and block them.

API: Users usually have necessary pre requests before accessing a certain API interface , such as booking: before initiating an order request, there are usually pre requests such as querying tickets and confirming orders. Bots usually initiate order requests directly to improve order efficiency. Using this mechanism, Workflow Detection will analyze the distribution of URL types accessed by clients over a period of time, identify requests that do not conform to normal workflow, and block them.

Example
The situation of the website http://www.test.com/ is as follows:

• The website manager does not want the booking interface of the website to be directly accessed, and visitor must visit the API of CAPTCHA firstly before logining within 300 seconds.
• booking interface: /booking.do
• API of CAPTCHA: /get_verification

According to the above scenario, the configuration is as follows:

1. Go to Security part, Configurations > Policies

2. Find the hostname for which you want to configure security policies, click .

3. Go to Bot Management, In the Anomaly Behavior Detection part, Enable Workflow Detection.

4. Expand the Workflow Detection folding panel, create the following rules and click Confirm.

   • Rule Name: Ticket Booking Scenario
   • Protection path: /booking.do
   • Protected Target: API
   • Trigger Conditions:
     Within [300] seconds [IP] requests match:
     1 : [Custom URL requests] [Regex Match] /123 < 1
     2 : [Custom URL requests] [Regex Match] /booking.do >= 1

5. Find the rule created above and set the action to Block.

6. Click the Publish button at the bottom of the page, click on the Publish to Staging button on the page of Confirm Changes, and verify according to the prompts on the page to ensure that the configured rules meet expectations.

7. Reconfigure the above rules, click the Publish Changes button at the bottom of the page, and click on Publish to Production on the page of Confirm Changes to make the configuration effective.