Last Modified: Sep 13, 2023
Affected Product(s):
BIG-IP APM
Known Affected Versions:
12.1.0, 12.1.1, 12.1.2, 12.1.3, 12.1.3.1, 12.1.3.2, 12.1.3.3, 12.1.3.4, 12.1.3.5, 12.1.3.6, 12.1.3.7, 12.1.4, 12.1.4.1, 12.1.5, 12.1.5.1, 12.1.5.2, 12.1.5.3, 12.1.6
Fixed In:
13.0.0
Opened: Jan 04, 2016 Severity: 3-Major
Previously the URL Filter Assign agent was always expected to be after Categorization and Response Analytics. In the case where Categorization returned only "recommend to scan" and Response Analytics returned nothing, "recommend to scan" would be treated as "uncategorized" before enforcing actions. BIG-IP now has Request Analytics. When this is used, there will be a URL Filter Assign agent after Request Analytics, and then another instance of this after Response Analytics. In such a situation, treating "recommend to scan" as "uncategorized" is incorrect in the instance of URL filter assign after Request Analytics.
A "recommend to scan" categorization after Request Analytics is treated as "uncategorized". This is undesirable because the first URL Filter Assign instance deals with it as uncategorized instead of evaluating further by sending it to Response Analytics. If the first URL Filter allowed it through, Response Analytics would no longer see the "recommend to scan" classification and would not scan.
Per request policy looks like: Category Lookup -> Request Analytics -> URL Filter -> Response Analytics -> URL Filter
None.
Instead of switching "recommend to scan" to "uncategorized" in URL Filter, the system now leaves it as "recommend to scan" and takes the action of "uncategorized". Response Analytics was changed to strip the "recommend to scan" category if other categories exist, and to otherwise change it to "uncategorize". Because the system expects that Response Analytics is the last category evaluation agent in the policy, this is reasonable and safe to do.