AltostratusHello everyone. In a security policy I am alarmed by an attack signature due to the detection of "cp", this identifies it as a command, however, it is part of the character string that is used to fill out a form on our website. How could this be mitigated without disabling said attack signature?
MVPFirst, this signature is a "low accuracy" signature so it may occasionally generate false positives as in your example. The description of the signature also says: "False Positives: Some applications may accept valid input which matches these signatures."
And second, as F5 ASM regular signatures are pattern based, meaning that they are triggered whenever there is a matching string pattern ('cp', 'or 1=1', '/etc/passwd'... for example) then you have almost no choice apart from disabling the detected signature in case you need to allow the related pattern.
In terms of security, the decision to allow or not the signature is not obvious, it depends on each customer desired tradeoff between usability and security level (insane, strong, acceptable, low). You don't want to allow OS commands to be executed by exploiting a form parameter but at the same time you can not block legitimate users.
AltostratusSo there is no signature that can be used to avoid leaving that area uncovered? That is to say, so that the execution of malicious commands is not allowed, without this macho with some other string of characters.
Nacreouswaf config needs to involve application team.
if they can ensure that those input data will not be executed in windows powershell, then you can unblock that particular filter.
Nacreousensure that you select correct server tech entries in the asm profile, e.g. dont include windows if the webserver is not windows based.
if above is correctly done but you still get false positive then you need to allow that particular traffic.
i had similar thing on waf config for car dealership.
there were sql injection false positives because of many "select" in the submited web forms.