Re: [mod-security-users] Apache 2.2 and URL encoding
Brought to you by:
victorhora,
zimmerletw
From: Ryan B. <Ryan.Barnett@Breach.com> - 2007-06-01 11:51:13
|
I got an email from Christian that pointed out some other scenarios where you could still run into problems with a single percent sign. So, here is an updated Ruleset (with an updated RegEx) that should work for this issue. Keep in mind that this is NOT an official Core Rules update as of yet and will still need to be QA'ed before being included in the rule archive. My initial tests, however, showed this to work. =20 # Check decodings SecRule REQUEST_FILENAME|ARGS|ARGS_NAMES|REQUEST_HEADERS|!REQUEST_HEADERS:Refere r "@validateUrlEncoding" \ "chain, deny,log,auditlog,status:400,msg:'URL Encoding Abuse Attack Attempt',,id:'950107',severity:'4'" SecRule REQUEST_FILENAME|ARGS|ARGS_NAMES|REQUEST_HEADERS|!REQUEST_HEADERS:Refere r "\%(?!$|\W|[0-9a-fA-F]{2}|u[0-9a-fA-F]{4})" =20 This will also allow the % sign to be followed by a non-alphanumeric character (so a whitespace, \r and \n should be fine). This would allow for text strings like this - "Today's special is 50% off!"=20 =20 --=20 Ryan C. Barnett ModSecurity Community Manager Breach Security: Director of Application Security Training Web Application Security Consortium (WASC) Member CIS Apache Benchmark Project Lead SANS Instructor, GCIA, GCFA, GCIH, GSNA, GCUX, GSEC Author: Preventing Web Attacks with Apache =20 =20 ________________________________ From: Ryan Barnett=20 Sent: Thursday, May 31, 2007 6:12 PM To: Don; Christian Bockermann Cc: mod...@li... Subject: RE: [mod-security-users] Apache 2.2 and URL encoding =20 A few points to clear up - =20 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 - =20 # Check decodings SecRule REQUEST_FILENAME|ARGS|ARGS_NAMES|REQUEST_HEADERS|!REQUEST_HEADERS:Refere r "@validateUrlEncoding" \ "chain, deny,log,auditlog,status:400,msg:'URL Encoding Abuse Attack Attempt',,id:'950107',severity:'4'" SecRule REQUEST_FILENAME|ARGS|ARGS_NAMES|REQUEST_HEADERS|!REQUEST_HEADERS:Refere r "\%(?!$|[0-9a-fA-F]{2}|u[0-9a-fA-F]{4})" =20 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=3D%25) will pass this rule. =20 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. =20 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 - =20 Adding new negative policy rules =20 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. =20 --=20 Ryan C. Barnett ModSecurity Community Manager Breach Security: Director of Application Security Training Web Application Security Consortium (WASC) Member CIS Apache Benchmark Project Lead SANS Instructor, GCIA, GCFA, GCIH, GSNA, GCUX, GSEC Author: Preventing Web Attacks with Apache =20 =20 ________________________________ From: mod...@li... [mailto:mod...@li...] On Behalf Of Don Sent: Thursday, May 31, 2007 5:52 PM To: Christian Bockermann Cc: mod...@li... Subject: Re: [mod-security-users] Apache 2.2 and URL encoding =20 These are the core rules. I have not modified them at all. I am new to mod security. Do I need to change something? Thanks, Don Christian Bockermann wrote:=20 I'd see this as a bug in the core-rules. The rule 950107 is checking ARGS by using=20 validateURLencoding. As far as I see, the encoding is clean. The only thing, which=20 is alerted by the rule is your parameter "INPUT1" holding the string "%". When=20 using double-url-encoding in your app this could become dangerous.=20 To me it looks as if the pattern of the rule was applied against the __urldecoded__=20 argument (that is against "%" but not "%25", possibly the t:urldecode was inherited?).=20 The pattern says, that after "%" [0-9a-fA-F]{2} must follow.=20 Or am I missing anything?=20 Regards,=20 Chris=20 P.S.: Looking at the pattern for a little longer makes me curious:=20 \%(?![0-9a-fA-F]{2}|u[0-9a-fA-F]{4})=20 alerts, if "%" is followed by something that ( is NOT [0-9a-fA-F]{2} )=20 OR that IS u[0-9a-fA-F]{4}, right?=20 Shouldn't this be like=20 \%?!([0-9a-fA-F]{2}|u[0-9a-fA-F]{4})=20 that is to be meant as=20 IF NOT ( [0-9a-fA-F]{2} OR u[0-9a-fA-F]{4} )=20 Am 31.05.2007 um 21:42 schrieb Don:=20 Hi,=20 I have an Apache Lounge version of apache 2.2 with mod security 2.1.1=20 on a Windows XP PC. I am running a C++ cgi application that uses url=20 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=20 I have:=20 [Tue May 22 12:51:04 2007] [error] [client 127.0.0.1] ModSecurity: Access denied with code 400 (phase 2).=20 Pattern match "\\\\%(?![0-9a-fA-F]{2}|u[0-9a-fA-F]{4})" at ARGS:INPUT1. [id "950107"] [msg "URL Encoding Abuse Attack Attempt"]=20 [severity "WARNING"] [hostname "localhost"] [uri "/cgi-bin/ttgxxx.exe/SearchIt?DBNAME=3D200703xxxxxx&NEWUSER=3Dxxxx=20 &CODE=3Dxxxx&DBALIAS=3DMAR%2B2007%2BB%2BOF%2BA%2BLOCKBOXES=20 &STARTSESSION=3D5%2F22%2F2007%2B12%3A50%3A51%2BPM=20 &R1=3DV1&INPUT1=3D%25&SUBMIT.x=3D23&SUBMIT.y=3D12&SUBMIT=3DSEARCH"] = [unique_id "XrASOwpYJAQAAADQDDkAAAD5"]=20 I have tried overriding this rule as per the mod security help file. I=20 created a file named modsecurity_crs_15_customrules.conf and added the=20 following to try to override the rule.=20 SecRuleRemoveByID "960901"=20 SecRuleRemoveByID "950107"=20 SecRuleRemoveByMsg "URL Encoding Abuse Attack Attempt"=20 This seems to have no effect at all and I continue to get the Bad Response error.=20 Thanks for any assistance with this.=20 Don=20 ------------------------------------------------------------------------ -=20 This SF.net email is sponsored by DB2 Express=20 Download DB2 Express C - the FREE version of DB2 express and take=20 control of your XML. No limits. Just data. Click to get it now.=20 http://sourceforge.net/powerbar/db2/____________________________________ ___________=20 mod-security-users mailing list=20 mod...@li...=20 https://lists.sourceforge.net/lists/listinfo/mod-security-users=20 --No virus found in this incoming message.=20 Checked by AVG Free Edition.Version: 7.5.472 / Virus Database: 269.8.4/825 - Release Date: 5/30/2007 3:03 PM=20 |