I wanted to send an update/correction – while what I stated below is true, that we are releasing v1.6.1 to address an issue, this may not be what you are seeing.  What exact rule set are you using?  It may be that you are using the “non-blocking” version.  The rule sets under the “optional_rules” directory are the ones that use “deny” for the XSS rules, etc…


Please confirm.



From: Ryan Barnett
Sent: Thursday, April 24, 2008 6:34 AM
To: J Amuse; mod-security-users@lists.sourceforge.net
Subject: RE: [mod-security-users] SecDefaultAction not denying request


We recently found a bug with the 1.6.0 rules when testing the M1100 appliance and it may be related to what you are seeing.  This issue has to do with some changes to the way SecDefaultAction works and, in this case, if the rules do not specify a “phase”.  We will be releasing 1.6.1 of the rules shortly, but in the meantime, you can test this by adding “phase:2” to your XSS rules and then retest.  It should then properly inherit the SecDefaultAction settings.





From: mod-security-users-bounces@lists.sourceforge.net [mailto:mod-security-users-bounces@lists.sourceforge.net] On Behalf Of J Amuse
Sent: Thursday, April 24, 2008 3:23 AM
To: mod-security-users@lists.sourceforge.net
Subject: [mod-security-users] SecDefaultAction not denying request


I'm using the default Core ModSecurity Rule Set ver.1.6.0 and set the default action to:

SecDefaultAction "phase:2,log,deny,status:403,t:lowercase,t:replaceNulls,t:compressWhitespace"

I then sent a test XSS request like : http://target/?<script>alert('xss')</script> which shows up in the logs as an XSS attack, but I get a 200 response as opposed to a 403 response back. How can I debug this problem?