Thanks Manuel and Christian for your responses. The application will have a thin layer of business rule whitelist regex based input validation – therefore the issue with XSS noted below may not be that much of a problem. For SQLinjection, it’s hard to guarantee that developers will always use parameterized queries consistently throughout the SDLC. In my opinion, encoded XSS attacks should be tackled at the lower paranoia levels.
I’d have to familiarize myself with the process of creating custom rules. Is there a plan to enforce Content Security Policy Directives and other HTTP security response headers (e.g. X-Frame-Options/Frame-Ancestors). In some of the testing that I did, it is evident that these security headers are not being injected. From: owasp-modsecurity-core-rule-set-bounces+hiranmayi.palanki=aexp....@lists.owasp.org [mailto:owasp-modsecurity-core-rule-set-bounces+hiranmayi.palanki=aexp....@lists.owasp.org] On Behalf Of Manuel Spartan Sent: Thursday, March 22, 2018 1:31 PM To: Christian Folini <christian.fol...@netnea.com> Cc: OWASP CRS <owasp-modsecurity-core-rule-set@lists.owasp.org> Subject: Re: [Owasp-modsecurity-core-rule-set] False Negatives (was: OWASP ModSecurity Core Rule Set Community Summit: July 4, 2018, in London) 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 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 received'" 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 Christian: 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/<https://isolate.menlosecurity.com/1/3735928037/https:/coreruleset.org/category/blog/> (CRS blog) https://spartantri.com/ModSecurity/<https://isolate.menlosecurity.com/1/3735928037/https:/spartantri.com/ModSecurity/> (My blog, read the whitepaper on white listing) Have fun! 2018-03-21 20:20 GMT+01:00 Christian Folini <christian.fol...@netnea.com<mailto:christian.fol...@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 XSS > attacks are getting through, what is the best way to block the encoded XSS > 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@lists.owasp.org<mailto:Owasp-modsecurity-core-rule-set@lists.owasp.org> https://lists.owasp.org/mailman/listinfo/owasp-modsecurity-core-rule-set<https://isolate.menlosecurity.com/1/3735928037/https:/lists.owasp.org/mailman/listinfo/owasp-modsecurity-core-rule-set> American Express made the following annotations ****************************************************************************** "This message and any attachments are solely for the intended recipient and may contain confidential or privileged information. If you are not the intended recipient, any disclosure, copying, use, or distribution of the information included in this message and any attachments is prohibited. If you have received this communication in error, please notify us by reply e-mail and immediately and permanently delete this message and any attachments. Thank you." American Express a ajouté le commentaire suivant le Ce courrier et toute pièce jointe qu'il contient sont réservés au seul destinataire indiqué et peuvent renfermer des renseignements confidentiels et privilégiés. Si vous n'êtes pas le destinataire prévu, toute divulgation, duplication, utilisation ou distribution du courrier ou de toute pièce jointe est interdite. Si vous avez reçu cette communication par erreur, veuillez nous en aviser par courrier et détruire immédiatement le courrier et les pièces jointes. Merci. ******************************************************************************
_______________________________________________ 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
