A few points to clear up –


1) The issue with the RegEx in rule ID 950107 has been identified previously and we have a fix.  It will be included in future releases of the Core Rules. I am including it here for you to test/use immediately –


# Check decodings


        "chain, deny,log,auditlog,status:400,msg:'URL Encoding Abuse Attack Attempt',,id:'950107',severity:'4'"



The main difference with the rule is that we added “$|” to the alternation string so that it will all a single “%” that does not have any data after it until the end of the line.  This is normally not an issue as the single % signs that are seeing seem to be placeholders for certain variable values.  So, when Mod parses and inspects ARGS, the variable in question (such as your example INPUT1=%25) will pass this rule.


2) Yeah, this RegEx can been a bit misleading and non-obvious for interpreting what it is actually doing (as Christian pointed out).  The bang symbol “!” is doing an inversion but it is for the entire parentheses grouping and not just the first portion.


3) As to why your SecRuleRemoveById didn’t work, here is the relevant section from my Blog post (http://www.modsecurity.org/blog/archives/2007/02/handling_false.html) on handling false positives –


Adding new negative policy rules  

If you need to add new negative policy rules, such as when you need to update a Core Rule that is causing a false positive, you should add these rules to a new rule file that come AFTER all of the other Core Rules. Call this new file something like – modsecurity_crs_60_customrules.conf. Just make sure that number in the filename is higher than any other rules file so it is read last. The rationale for placing these types of rules after the other rules is that you can then match up these new replacement rules with corresponding SecRuleRemoveByID directives that will then disable the specific Core Rule(s) that are causing False Positives. It is important to note that you need to use SecRuleRemoveById AFTER ModSecurity has knowledge of the Rule ID you are actually removing. If you were to place this directive in the modsecurity_crs_15_customrules.conf file, it would not work correctly as the rule ID you are specifying does not exist yet. That is why this directive should be called up in your custom rules file that comes at the end. Using this method allows you to turn off rules without having to actually go into the Core Rules files and comment out or update specific rules.


Ryan C. Barnett
ModSecurity Community Manager

Breach Security: Director of Application Security Training
Web Application Security Consortium (WASC) Member
CIS Apache Benchmark Project Lead

Author: Preventing Web Attacks with Apache



From: mod-security-users-bounces@lists.sourceforge.net [mailto:mod-security-users-bounces@lists.sourceforge.net] On Behalf Of Don
Sent: Thursday, May 31, 2007 5:52 PM
To: Christian Bockermann
Cc: mod-security-users@lists.sourceforge.net
Subject: Re: [mod-security-users] Apache 2.2 and URL encoding


These are the core rules. I have not modified them at all. I am new to mod security. Do I need to change something?


Christian Bockermann wrote:

I'd see this as a bug in the core-rules. The rule 950107 is checking ARGS by using
validateURLencoding. As far as I see, the encoding is clean. The only thing, which
is alerted by the rule is your parameter "INPUT1" holding the string "%". When
using double-url-encoding in your app this could become dangerous.

To me it looks as if the pattern of the rule was applied against the __urldecoded__
argument (that is against "%" but not "%25", possibly the t:urldecode was inherited?).

The pattern says, that after "%" [0-9a-fA-F]{2} must follow.

Or am I missing anything?


P.S.: Looking at the pattern for a little longer makes me curious:


alerts, if "%" is followed by something that ( is NOT [0-9a-fA-F]{2} )
OR that IS u[0-9a-fA-F]{4}, right?

Shouldn't this be like


that is to be meant as

     IF NOT  (  [0-9a-fA-F]{2}  OR  u[0-9a-fA-F]{4}  )

Am 31.05.2007 um 21:42 schrieb Don:


I have an Apache Lounge version of apache 2.2 with mod security 2.1.1
on a Windows XP PC. I am running a C++ cgi application that uses url
encoding. I am using the core rules that came with mod security. Since I
am using url encoding in my program, I am getting a Bad Response error. In the error log
I have:
[Tue May 22 12:51:04 2007] [error] [client] ModSecurity: Access denied with code 400 (phase 2).
Pattern match "\\\\%(?![0-9a-fA-F]{2}|u[0-9a-fA-F]{4})" at ARGS:INPUT1. [id "950107"] [msg "URL Encoding Abuse Attack Attempt"]
[severity "WARNING"] [hostname "localhost"] [uri "/cgi-bin/ttgxxx.exe/SearchIt?DBNAME=200703xxxxxx&NEWUSER=xxxx

I have tried overriding this rule as per the mod security help file. I
created a file named modsecurity_crs_15_customrules.conf and added the
following to try to override the rule.

SecRuleRemoveByID "960901"
SecRuleRemoveByID "950107"
SecRuleRemoveByMsg "URL Encoding Abuse Attack Attempt"

This seems to have no effect at all and I continue to get the Bad Response error.

Thanks for any assistance with this.

This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
mod-security-users mailing list

--No virus found in this incoming message.
Checked by AVG Free Edition.Version: 7.5.472 / Virus Database: 269.8.4/825 - Release Date: 5/30/2007 3:03 PM