Re: Secure way to deal with ModSecurity SQLI False Positives on AJAX pages
Todd Michael Bushnell <todd <at> toorsecurity.com>
2011-09-21 04:44:34 GMT
Ryan (et al.),
Appreciate the help. Attached is a sample event log entry in gzip format. Not sure if this will even take, but
worth a shot. It's been scrubbed and the majority of the request data truncated, but you'll get the
picture. As you can see from this, there are a lot of strings that trip the SQL injection rules. Even pipe
delimiters in the cookie header are contributing to this, but the vast majority in this case comes from the
3k AJAX request body. I'm trying to find that balance between reasonably protective and unnecessarily
noisy and most of my difficulties are with the SQL injection rules given the sheer number of "interesting"
characters and strings that will trip it. Appreciate the assist.
todd
On Sep 20, 2011, at 4:36 PM, Ryan Barnett wrote:
> Can you provide an example audit log or two of some false positives? This will help in recommending some
exception options.
>
> You might be able to use the ctl:ruleUpdateTargetById action to exclude certain AJAX params from
inspection for specific pages. See this blog post -
> http://blog.spiderlabs.com/2011/08/modsecurity-advanced-topic-of-the-week-exception-handling.html
>
> -Ryan
>
> From: Todd Michael Bushnell <todd <at> toorsecurity.com<mailto:todd <at> toorsecurity.com>>
> Date: Tue, 20 Sep 2011 18:19:26 -0500
> To:
"mod-security-users <at> lists.sourceforge.net<mailto:mod-security-users <at> lists.sourceforge.net>" <mod-security-users <at> lists.sourceforge.net<mailto:mod-security-users <at> lists.sourceforge.net>>
> Subject: [mod-security-users] Secure way to deal with ModSecurity SQLI False Positives on AJAX pages
>
> Running into an issue where AJAX pages are taking 7-10 seconds to load. Dug in deeper and noticed that it's
indeed due to 30+ false positives detected during request body processing (phase 2). I'm trying to
determine the most secure way to deal with this. I run in anomaly based mode. I thought about just
increasing the threshold, but I don't think this will address the performance issue because all the rules
will still still be triggered. The only thing I'll save on is the generation of the alert which my data tell
me is not the delay. I see my remaining options as:
>
> - disable the rules that are firing (about 10 or so sql injection pattern matching rules) globally. SQL
Injection rules are generating 95% of my false positives on the site.
> - disable all modsecurity processing of anything with Body that starts with ^AJAXREQUEST
> - disable all or partial rules on page by page basis, feeding that data in using something like <at> pfFromFile.
>
> Would appreciate advice from folks who've dealt with this before. Much obliged.
>
> todd
>
>
>
>
>
>
>
>
>
>
>
> ________________________________
> This transmission may contain information that is privileged, confidential, and/or exempt from
disclosure under applicable law. If you are not the intended recipient, you are hereby notified that any
disclosure, copying, distribution, or use of the information contained herein (including any reliance
thereon) is STRICTLY PROHIBITED. If you received this transmission in error, please immediately
contact the sender and destroy the material in its entirety, whether in electronic or hard copy format.
>
------------------------------------------------------------------------------
All the data continuously generated in your IT infrastructure contains a
definitive record of customers, application performance, security
threats, fraudulent activity and more. Splunk takes this data and makes
sense of it. Business sense. IT sense. Common sense.
http://p.sf.net/sfu/splunk-d2dcopy1
_______________________________________________
mod-security-users mailing list
mod-security-users <at> lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mod-security-users
ModSecurity Services from Trustwave's SpiderLabs:
https://www.trustwave.com/application-security.php
RSS Feed