Re: [mod-security-users] Filter Rule...
Brought to you by:
victorhora,
zimmerletw
Menu
▾
▴
Re: [mod-security-users] Filter Rule...
|
From: Ryan B. <Rya...@Br...> - 2007-03-26 17:59:56
|
There are some semantic differences between the v1.9 and v2.0 rulesets that everyone should be aware of. Please refer to my recent Blog post - http://www.modsecurity.org/blog/archives/2007/03/2x1x_rule_diffe.html as it outlines a similar issue. =20 In this case, the following rule means 2 separate things - =20 SecFilterSelective ARG_Lpassword "![a-zA-Z0-9\:;,\.\$\%]{1,13}" =20 First, it means - if the request does not have the "Lpassword" argument with the following data then deny. This matches when the Lpassword arg isn't even present. Second, it means - if the request does have the "Lpassword" argument, and it doesn't have the authorized characters or is too large/small then deny. =20 Actually, after testing, there seems to be a bug in the syntax of the rule. The entire RegEx should be surrounded by parentheses in order to have the Inverted rule applied on both the allowed character class and the size limitation. Otherwise, the invert was only being applied to the character class. This means that you could send a request with 100 "a" characters and it would be allowed through. The rule should be this - =20 SecFilterSelective ARG_Lpassword "!^([a-zA-Z0-9\:;,\.\$\%]{1,13})$" =20 That being said, the easiest way to correct this is to include a Scope context to the rule. The following ruleset uses the Apache Location directive to only apply the Mod rule if the URL is the "script.php" script. This is assuming that the script.php script is the one that legitimately has the Lpassword argument. =20 <Location "/cgi-bin/script.php"> SecFilterSelective ARG_Lpassword "!^([a-zA-Z0-9\:;,\.\$\%]{1,13})$" </Location> =20 If you want to use ModSecurity only directives, you could do one of the following - =20 1) Create a chained rule that first checks the URI - =20 SecFilterSelective REQUEST_URI "^/cgi-bin/script\.php$ "chain,log,deny,msg:'Lpassword Argument has illegal data.'" SecFilterSelective ARG_Lpassword "!^([a-zA-Z0-9\:;,\.\$\%]{1,13})$" =20 2) Create a chained rule that first checks to see if the Lpassword arg is present, if so, then check the format/size, etc... =20 SecFilterSelective ARG_Lpassword "!^$" "chain,log,deny,msg:'Lpassword Argument has illegal data.'" SecFilterSelective ARG_Lpassword "!^([a-zA-Z0-9\:;,\.\$\%]{1,13})$" =20 I hope this helps. Let me know if you run into any more issues. =20 --=20 Ryan C. Barnett ModSecurity Community Manager Breach Security: Director of Application Security Training Web Application Security Consortium (WASC) Member Author: Preventing Web Attacks with Apache =20 -------------- Web Security Threat Report Webinar on May 9, 2007 (12 pm EST) Learn More About the Breach Webinar Series: http://www.breach.com/webinars.asp -------------- =20 ________________________________ From: mod...@li... [mailto:mod...@li...] On Behalf Of Russ Lavoie Sent: Monday, March 26, 2007 11:51 AM To: Ofer Shezaf; mod...@li... Subject: Re: [mod-security-users] Filter Rule... =20 Hmm... =20 I used the following and it alerts on every page of the site on my dev box even though the Lpassword variable is not present on those pages. =20 SecFilterSelective ARG_Lpassword "![a-zA-Z0-9\:;,\.\$\%]{1,13}" SecFilterSelective ARGS|!ARG_Lpassword ";[[:space:]]*(ls|id|pwd|wget)" =20 It isn't working for me... =20 mod_security: Access denied with code 403. Pattern match "![a-zA-Z0-9\\\\:;,\\\\.\\\\$\\\\%]{1,13}" at ARG("Lpassword") [msg "Command execution attack"] [severity "EMERGENCY"] [hostname "devbox"] [uri "/cgi-bin/script.pl"] [unique_id "RgfpZawfFgMAADTcAVA"] =20 I just browse to the front page of the site and bang... I get this error... the uri will be different every time though. =20 Not sure what the issue is here :-( Russ =20 =20 =20 ________________________________ From: Ofer Shezaf [mailto:Of...@Br...]=20 Sent: Monday, March 26, 2007 9:06 AM To: Russ Lavoie; mod...@li... Subject: RE: [mod-security-users] Filter Rule... =20 Well it seems the Chris (in another e-mail) paid more attention to your exact problem, so white listing the password field would be your solution =20 >From Chris e-mail SecFilterSelective ARG_passwd "![a-zA-Z0-9\:;,\.\$\%]{1,10}" SecFilterSelective ARGS|!ARG_passwd ";[[:space:]]*(ls|id|pwd|wget)" =20 If Chris rule for the password field was too limited, you may want to keep only the length limitation as it would be hard to squeeze a whole command injection attack in 10 characters. =20 ~ Ofer =20 From: Russ Lavoie [mailto:rl...@nc...]=20 Sent: Monday, March 26, 2007 3:58 PM To: Ofer Shezaf; mod...@li... Subject: RE: [mod-security-users] Filter Rule... =20 I would love to upgrade... But we would have to upgrade apache first... These are the last set of servers that are running apache 1.3.x releases. =20 I want to have free reign for password creations, but want to still have some security in it. How does \b help out in this instance? I don't fully understand. =20 Thanks =20 ________________________________ From: Ofer Shezaf [mailto:Of...@Br...]=20 Sent: Monday, March 26, 2007 4:05 AM To: Russ Lavoie; mod...@li... Subject: RE: [mod-security-users] Filter Rule... =20 Well, you could use ModSecurity 2.x and the Core Rule Set.... =20 But if you insist not to upgrade than the following will help: =20 SecFilterSelective ARGS_VALUES ";[[:space:]]*(ls|id|pwd|wget)\b" =20 The additional \b at the end of the regular expression ensures that a word boundary, so any white space, symbol or the end of the string would be accepted but not a letter or a digit. =20 ~ Ofer Shezaf ModSecurity Core Rule Set project leader. =20 =20 =20 From: mod...@li... [mailto:mod...@li...] On Behalf Of Russ Lavoie Sent: Saturday, March 24, 2007 8:51 PM To: mod...@li... Subject: [mod-security-users] Filter Rule... =20 I have the below filter rule for modsecurity 1.9 =20 SecFilterSelective ARGS_VALUES ";[[:space:]]*(ls|id|pwd|wget)" =20 I am having a problem with valid attempts are coming through.. Say a password with a semi colon followe by a space then an ls(some random characters). =20 How can I make this a working rule that will not block these types of comments in a password field of a web page? =20 Thanks |
