Forum Discussion

snoonanCLG's avatar
snoonanCLG
Icon for Nimbostratus rankNimbostratus
Apr 18, 2023
Solved

CMS causing False Positives

Hello,

I am recently seeing many false positives relating to CMS (Kentico EMS) on one of my F5 ASM policies.

 

As it is CMS and marketing department would be editing web sites etc. we are seeing many requests being blocked due to various injection attack signatures.

 

The users, and app developers, are getting frustrated with the amount of false positives. Is there any recommended set up such as which attack signatures to include in the learning and blocking settings for CMS?

Trawling through the traffic learning it's hard to determine which attack signature suggestions to disable as difficult to ascertain which as true false positives and which are actual injection  attempts. We are running a manual policy.

  • When protecting a CMS this is a common theme.

    What I have done previously is, if possible, to identify the legitimite users and whitelist or unblock request coming from them.

    It is also important to configure the correct content types on the URL's. You will propably have a bunch of URL's which are being used to upload content. The URL's should be defined in the policy and under header based content profiles, set to not do anything with the request body. This is the single biggest reason for false positives.

    You might also encounter parts for the application which simply cannot be passed correctly by AWAF/ASM and you will be forced to disable the security. This is just a fact of life. You then need to think of alternatives to compensate for this gap.

    Hope it makes sense 😄

     

1 Reply

  • When protecting a CMS this is a common theme.

    What I have done previously is, if possible, to identify the legitimite users and whitelist or unblock request coming from them.

    It is also important to configure the correct content types on the URL's. You will propably have a bunch of URL's which are being used to upload content. The URL's should be defined in the policy and under header based content profiles, set to not do anything with the request body. This is the single biggest reason for false positives.

    You might also encounter parts for the application which simply cannot be passed correctly by AWAF/ASM and you will be forced to disable the security. This is just a fact of life. You then need to think of alternatives to compensate for this gap.

    Hope it makes sense 😄