PCRE match limit excedeed

[Cristina Marletta Livi]

In Netscaler ADC VPX 12, we have a log message due to a DENY_URL relaxation rule:

default APPFW Message 392589284 0 :  "PCRE match limit exceeded with regex (83, ^http(s)?:\/\/www\.aaaa\.it\/bbbb\/it.+\?.+[^&](?=.*\bOR\b)(?=.*['\;]).*$) for subject (210, https://www.aaaa.it/bbbb/it/mg_1_7.page?facetNode_1=0_2&facetNode_2=0_2_2_7&facetNode_3=2_8&facetNode_4=2_8_28&facetNo). "
Why?

Is WAF protection guaranteed?

 

 

Regards

Cristina

 

[Rhonda Rowland1709152125]

Is there more in the WAF syslog event regarding the module (appfw feature reporting the error) or is that the full syslog message for this particular event?

 

What risk/violation/pattern are you trying to get this denyurl to block:

this whole section appears to be problematic:

.+[^&](?=.*\bOR\b)(?=.*['\;])

 

I think that based on the pattern you are concerned about 1) there may already be a signature to prevent it or 2) the regex you need to define the thing you are trying to block needs to be defined differently, but two lookaheads with the .*\bOR\b is also not helping on the performance.  Bottom line, there might be a better way to identify the pattern you are trying to block than what is implemented.

 

Here's a similar error that was thrown (back in 11.1):  https://docs.citrix.com/en-us/netscaler/downloads/release-notes-11-1-60-13.html

The message for this older signature was generated when the expressions was too computationally expensive to be evaluated. In this case, a new signature replaced it in a later build.

I think that's what's happening with your rule the pattern for deny URLs you have defined is too expensive to evaluate and so the appfw has to abandon the processing.  (Though support or an engineer may need to confirm that i'm right on the cause here.)

 

In this case, I don't know if this will result in the WAF blocking the traffic or not. If it results in an "undefined" result, then the traffic would be blocked. If it just can't evaluate the rule, on the other security checks that relaxation would fail to process so that rule wouldn't be allowing traffic and traffic would be blocked if not permitted by some other relaxation.

 

But on the deny URL, it doesn't get to match the deny rule, so it probably won't be blocked in this case, some other rule may catch but this one can't be evaluated.  At least, that's my best guess...i'm not sure if the WAF decides to block traffic if the deny rule can't evaluate in this case.