[Owasp-modsecurity-core-rule-set] False Negatives (was: OWASP ModSecurity Core Rule Set Community Summit: July 4, 2018, in London)

Manuel Spartan spartantri at gmail.com
Thu Mar 22 17:30:47 UTC 2018

 Hi Hiranmayi,

Do you think in implementing input validation at all in your app?

>* Encoded XSS attacks (stopped at PL2 as Christian said)
*>* http://localhost:8082/xss2?uid=%3Balert%281%29%3B
>* SQLi
*>* http://localhost:8082/sqli2?uid=3-2 <http://localhost:8082/sqli2?uid=3-2>*

If the response display the same as uid=1 you have a nice injection as the
back-end engine is evaluating the operation, however sending long
complicated payloads will be difficult in Paranoia Level 2 due to
libinjection inspections on ARGS and very hard in PL 4 as all non
alphanumeric characters will cause a blocked request but that will be
extremely annoying to implement if you use non-alphanumeric characters.

Why don't you simply make positive validation rules additional to CRS in
paranoia level 2? That will be easier, faster and more effective if your
app is not so complex but requires tailor made configurations and
application knowledge while the CRS is generic and do not require much
application knowledge.

i.e. This rule will accept only numeric values on the uid parameter on GET
requests, with this you will get rid of both issues with the least effort,
this is the kick... positive security power in action :)
SecRule ARGS:uid "!@rx [0-9]+" "id:1,phase:1,deny,log,msg:'Bad value

Notice that the phase:1 is only for GET parameters and cannot be placed
inside Apache locations or it may be silently ignored but is faster as most
CRS rules are in phase:2 it will execute earlier and save you the execution
of many rules.

You may find very useful to learn the basics on ModSecurity rule writing,
other than the netnea tutorial to deal with False Positives shared by
Web Application Defender's Cookbook: Battling Hackers and Protecting Users
(RBarnett) for quick receipes
ModSecurity Handbook (CFolini, IRistic) for general knowledge
https://coreruleset.org/category/blog/ (CRS blog)
https://spartantri.com/ModSecurity/ (My blog, read the whitepaper on white

Have fun!

2018-03-21 20:20 GMT+01:00 Christian Folini <christian.folini at netnea.com>:

> Hey Hiranmayi,
> On Wed, Mar 21, 2018 at 02:25:32PM +0000, Hiranmayi Palanki wrote:
> > What is the recommended Paranoia Level for an enterprise Internet facing
> > application, that does not break the application functionality?
> I'd say you should put it at least on level 2. This will bring some false
> positives and you deal with those as described in the documentation.
> > Let’s say if I have the default configuration enabled, and the encoded
> > attacks are getting through, what is the best way to block the encoded
> > attacks without enabling the higher Paranoia Levels?
> If you do not want to use CRS rules, you need to write your own XSS rules
> that do a better job than CRS. There are very good XSS documents around,
> many of them several pages long with lots of example payloads. You need to
> cover all these without breaking your application.
> Most people find it easier to use CRS and deal with the false positives.
> Ahoj,
> Christian
> --
> I have always observed that to succeed in the world one should appear
> like a fool but be wise.
> -- Charles de Montesquieu
> _______________________________________________
> Owasp-modsecurity-core-rule-set mailing list
> Owasp-modsecurity-core-rule-set at lists.owasp.org
> https://lists.owasp.org/mailman/listinfo/owasp-modsecurity-core-rule-set
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.owasp.org/pipermail/owasp-modsecurity-core-rule-set/attachments/20180322/597dbc28/attachment.html>

More information about the Owasp-modsecurity-core-rule-set mailing list