> Just to make sure we are on the same boat: This > rule triggers on any argument containing a URI > which does not start with a FQDN identical with the > host-header of the request. Am I right?
Yes :) > 2) In the basic set, clone this rule, but ensure it doesn’t work on ARGS:url > I understand your reasoning. But is not that too much fiddling? > Or is ARGS:url that common? I have the same functionality on > ARGS:target > ARGS:remote > ARGS:back > ... > > Can't we leave that sort of tuning to the sysadmins? Why don't we simply move > the rule from standard to paranoia mode as it has too many false positives. Well, such a tuning was just one proposal to reduce FP for non-paranoid users so it might tip the balance in favor of keeping the rule in base. (Moving it to paranoid is just one possible way to change the FP / protection balance) I’m not 100% sure we should go very far with whitelistings in the default set. But there is some precedent (excluding Google Analytics cookies, formerly also Piwik I think). The CRS does carve little holes sometimes in order to deal with reality of the current web and still be strict on the rest (while commercial WAFs are necessarily much less strict on this, since it causes them too many support calls). I would hate to see the rule totally disappear from base just on my one FP note though. Maybe more people can check their audit logs for the rule since it’s in CRSv2 too. It does rule out a lot of exploits on legacy / in house PHP apps and attackers try it daily. So it’s a hard call... -- Walter Hop | PGP key: https://lifeforms.nl/pgp
_______________________________________________ Owasp-modsecurity-core-rule-set mailing list Owasp-modsecurity-core-rule-set@lists.owasp.org https://lists.owasp.org/mailman/listinfo/owasp-modsecurity-core-rule-set
