Thanks Christian. What is the recommended Paranoia Level for an enterprise Internet facing application, that does not break the application functionality?
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? From: Christian Folini [mailto:christian.fol...@netnea.com] Sent: Tuesday, March 20, 2018 3:52 PM To: Hiranmayi Palanki <hiranmayi.pala...@aexp.com> Cc: owasp-modsecurity-core-rule-set@lists.owasp.org Subject: Re: False Negatives (was: OWASP ModSecurity Core Rule Set Community Summit: July 4, 2018, in London) Hello Hiranmayi, On Tue, Mar 20, 2018 at 02:19:50PM +0000, Hiranmayi Palanki wrote: > Having recently tried out ModSecurity, it appears that lower paranoia levels > (Basic, PL1, PL2, PL3) are not fully blocking all flavors of XSS and SQL > injection. > > Encoded XSS attacks are bypassing the CRS rules. Example below: > http://localhost:8082/xss2?uid=%3Balert%281%29%3B This results in a 3 rule alerts in CRS 3.0.2 for me: 942110 PL2 SQL Injection Attack: Common Injection Testing Detected 920273 PL4 Invalid character in request (outside of very strict set) 942432 PL4 Restricted SQL Character Anomaly Detection (args): # of special characters exceeded (2) > Similarly for SQLi, the below pattern is getting through. > > http://localhost:8082/sqli2?uid=3-2 What's wrong with this parameter. "3-2" is by no means an SQL Injection. The very fact that a security scanner is launching a request does not make it an attack. > When the Paranoia Level is set to PL4, the encoded XSS attack is blocked, > however it crashes the application. I am not sure what you mean by "crashes the application". You are probably meaning to say that the application is no longer working properly with PL4. That is expected behaviour at this high paranoia level. What you are facing are false positives, that you need to tune away. There is a tutorial dedicated to this work over at https://www.netnea.com<https://isolate.menlosecurity.com/1/3735928037/https:/www.netnea.com> > Is it possible to selectively add custom rules (for encoded XSS attacks) to > the basic level or other lower levels that do not adversely impact the > application? One of the criterias for putting rules in the higher paranoia levels is there tendency to cause false positives. If they were less likely to have this effect, we would shift them to a lower PL. With that being said: No, you can not easily move rules around even if the false positives were a non-issue. Ahoj, Christian P.S. You responded to a message about the CRS summit and quoted that subject line. Yet your message has a completely different topic. Please start a new message when you want to start a new subject. -- There are two primary choices in life: (1) To accept conditions as they exist, or (2) accept responsibility for changing them. -- Denis Waitley 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
