mod-security-users — General discussion about mod_security

Re: [mod-security-users] Recommeded vs Minimum Configuration

[Ivan R. <iv...@we...>]

Ann Hopkins wrote:
> DOCUMENTATION:
> SecFilterCheckCookieFormat Off

   Since 1.8.7 the SecFilterCheckCookieFormat directive does
   nothing (read about it in the manual). I don't see this
   changing in the future.


> (Includes HEAD and a semicolon at the end)
> # Only accept request encodings we know how to handle
> # we exclude GET requests from this because some (automated)
> # clients supply "text/html" as Content-Type
> SecFilterSelective REQUEST_METHOD "!^(GET|HEAD)$" chain
> SecFilterSelective HTTP_Content-Type \
> "!(^application/x-www-form-urlencoded$|^multipart/form-data;)"

   This is better. HTTP clients are not required to send a
   Content-Type header when HEAD is used.

   The semicolon at the end is not very important - I am yet
   to encounter a valid HTTP client that does not use it.


> Also is default status code 403 (forbidden) a better choice than 500 
> (server bad) as I have seen 500 recommended in an article.

   They are the same. 500 is somewhat "more stealthy" because
   it could be interpreted as internal error (and error often
   occur when someone is trying to hack). 403 implies the web
   server determined the request may be bad in some way.

-- 
Ivan Ristic
Apache Security (O'Reilly) - http://www.apachesecurity.net
Open source web application firewall - http://www.modsecurity.org

Re: [mod-security-users] [ANNOUNCE] ModSecurity 1.8.7 has been released

[Ivan R. <iv...@we...>]

Mark wrote:
>>>Does this version contain the functionality for 
>>>"SecFilterExternal" ?
>>
>>   No, that's still in the development branch.
> 
> 
> Hmm, interesting; :) Would that be like a sendmail
> program map? Might come with a performance penalty,
> but still.

   It's a way to execute external scripts and have
   them inspect the request. There will certainly be a
   performance penalty associated with the execution but it
   should be good enough for the casual blogger who wants
   to fight blog spam.

   BTW, at some point in the future I will expose the
   mod_security functionality so that other Apache modules
   can use its services.

-- 
Ivan Ristic
Apache Security (O'Reilly) - http://www.apachesecurity.net
Open source web application firewall - http://www.modsecurity.org

Re: [mod-security-users] problem with SecFilter "<(.|\n)+>"

[Ivan R. <iv...@we...>]

Thomas B=F6rnert wrote:
> Hi List,
>=20
> I've a problem with the following URL:
>=20
> http://www.domain.de/module/lauftext.swf?text=3D%3Cb%3ENeu%3A+F%C3%B6rd=
er-
> +und+Siebrinnen+VCS%3C%2Fb%3E+-+Sch%C3%BCttg%C3%BCter+kostensparend
> +transportieren&link=3Dverfahrenstechnik%2Frinnen%2Fvcs%2F%3Fde
>=20
> i found no "." and no "\n" in the URL. Why matches mod_security
> this URL by this Rule ?

   That's because . is a special character in regular expressions,
   and stands for any one character (except for \n in some cases).

   In your case the rule matched <b>

[www.domain.de/sid#8269140][rid#830cd88][/module/lauftext.swf] Checking
against "/module/lauftext.swf?text=3D<b>Neu: F\xc3\xb6rder- und Siebrinne=
n
VCS</b> - Sch\xc3\xbcttg\xc3\xbcter kostensparend
transportieren&link=3Dverfahrenstechnik/rinnen/vcs/?de"

   See here for more information about regular expressions:

   http://www.pcre.org/

--=20
Ivan Ristic
Apache Security (O'Reilly) - http://www.apachesecurity.net
Open source web application firewall - http://www.modsecurity.org

[mod-security-users] Recommeded vs Minimum Configuration

[Ann H. <sea...@ha...>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

This is just a question between the difference between the recommended minimum
configuration in the documentation and the minimum configuration for httpd.conf
in the distribution.

DOCUMENTATION:
SecFilterCheckCookieFormat Off

(Includes HEAD and a semicolon at the end)
# Only accept request encodings we know how to handle
# we exclude GET requests from this because some (automated)
# clients supply "text/html" as Content-Type
SecFilterSelective REQUEST_METHOD "!^(GET|HEAD)$" chain
SecFilterSelective HTTP_Content-Type \
"!(^application/x-www-form-urlencoded$|^multipart/form-data;)"

DISTRIBUTION COPY:
SecFilterCheckCookieFormat On

# Only accept request encodings we know how to handle
# we exclude GET requests from this because some (automated)
# clients supply "text/html" as Content-Type
SecFilterSelective REQUEST_METHOD "!^GET$" chain
SecFilterSelective HTTP_Content-Type
"!(^$|^application/x-www-form-urlencoded$|^multipart/form-data)"




Also is default status code 403 (forbidden) a better choice than 500 (server
bad) as I have seen 500 recommended in an article.


Thanks,
Beginning mod_security user and small-time webmaster
Ann

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.0 (MingW32)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFCL5o7hs7JGk93PT0RAg9bAKC2OiKsymYvmLidX8ksOKMvF4Ua4gCguJas
VqTQ0A38mJmSdKSXlAl4Hc0=
=l8el
-----END PGP SIGNATURE-----

[mod-security-users] problem with SecFilter "<(.|\n)+>"

[Thomas <tb...@tb...>]

Hi List,

I've a problem with the following URL:

http://www.domain.de/module/lauftext.swf?text=%3Cb%3ENeu%3A+F%C3%B6rder-
+und+Siebrinnen+VCS%3C%2Fb%3E+-+Sch%C3%BCttg%C3%BCter+kostensparend
+transportieren&link=verfahrenstechnik%2Frinnen%2Fvcs%2F%3Fde

the debug shows

[09/Mar/2005:22:53:17 +0100]
[www.domain.de/sid#8269140][rid#830cd88][/module/lauftext.swf] Signature
check returned 0
[09/Mar/2005:22:53:17 +0100]
[www.domain.de/sid#8269140][rid#830cd88][/module/lauftext.swf] Checking
signature "<(.|\\n)+>" at THE_REQUEST
[09/Mar/2005:22:53:17 +0100]
[www.domain.de/sid#8269140][rid#830cd88][/module/lauftext.swf] Checking
against "/module/lauftext.swf?text=<b>Neu: F\xc3\xb6rder- und Siebrinnen
VCS</b> - Sch\xc3\xbcttg\xc3\xbcter kostensparend
transportieren&link=verfahrenstechnik/rinnen/vcs/?de"
[09/Mar/2005:22:53:17 +0100]
[www.domain.de/sid#8269140][rid#830cd88][/module/lauftext.swf] Signature
check returned 500
[09/Mar/2005:22:53:17 +0100]
[www.domain.de/sid#8269140][rid#830cd88][/module/lauftext.swf] Access
denied with code 500. Pattern match "<(.|\\n)+>" at THE_REQUEST
[09/Mar/2005:22:53:17 +0100]
[www.domain.de/sid#8269140][rid#830cd88][/module/lauftext.swf] Rule
match, returning code 500

i found no "." and no "\n" in the URL. Why matches mod_security
this URL by this Rule ?

Many thanks for help.

-Thomas

RE: [mod-security-users] [ANNOUNCE] ModSecurity 1.8.7 has been released

[Mark <ad...@as...>]

> -----Original Message-----
> From: mod...@li... 
> [mailto:mod...@li...] On 
> Behalf Of Ivan Ristic
> Sent: woensdag 9 maart 2005 12:18
> To: mod...@li...
> Subject: Re: [mod-security-users] [ANNOUNCE] ModSecurity 
> 1.8.7 has been released
> 
> 
> Spence, Ian (ELS-CAM) wrote:
> > Ivan,
> > 
> > Does this version contain the functionality for 
> > "SecFilterExternal" ?
> 
>    No, that's still in the development branch.

Hmm, interesting; :) Would that be like a sendmail
program map? Might come with a performance penalty,
but still.

- Mark 
 
        System Administrator Asarian-host.org
 
---
"If you were supposed to understand it,
we wouldn't call it code." - FedEx

Re: [mod-security-users] [ANNOUNCE] ModSecurity 1.8.7 has been re leased

[Ivan R. <iv...@we...>]

Spence, Ian (ELS-CAM) wrote:
> Ivan,
> 
> Does this version contain the functionality for "SecFilterExternal" ?

   No, that's still in the development branch.

-- 
Ivan Ristic
Apache Security (O'Reilly) - http://www.apachesecurity.net
Open source web application firewall - http://www.modsecurity.org

RE: [mod-security-users] [ANNOUNCE] ModSecurity 1.8.7 has been re leased

[Spence, I. (ELS-CAM) <I.S...@El...>]

Ivan,

Does this version contain the functionality for "SecFilterExternal" ?

Regards,
Ian Spence 

-----Original Message-----
From: mod...@li...
[mailto:mod...@li...] On Behalf Of Ivan
Ristic
Sent: 09 March 2005 09:54
To: mod...@li...
Subject: [mod-security-users] [ANNOUNCE] ModSecurity 1.8.7 has been released


ModSecurity 1.8.7 has been released. It is available for immediate download
from:

     http://www.modsecurity.org/download/

This release brings a mixture of small bug fixes, one minor security fix,
and minor enhancements. Cookie parsing has been enhanced.
ModSecurity now has two cookie parsers, one for each major version of the
specification. Failures to execute external scripts are now properly logged.
If the approver script is missing or not working the request is now
rejected. A bug that allows attacker to bypass some of the checks is now
fixed.


About ModSecurity
-----------------
ModSecurity is a web application firewall, designed to protect vulnerable
applications and reject manual and automated attacks.
It is an open source intrusion detection and prevention system. It can work
embedded in Apache, or as a standalone security device when configured to
work as part of an Apache-based reverse proxy.

Optionally, ModSecurity creates application audit logs, which contain the
full request body in addition to all other details. Requests are filtered
using regular expressions. Some of the things possible are:

   * Apply filters against any part of the request (URI,
     headers, either GET or POST)
   * Apply filters against individual parameters
   * Reject SQL injection attacks
   * Reject Cross site scripting attacks
   * Store the files uploaded through the web server, and have them
     checked by external scripts

With few general rules ModSecurity can protect from both known and unknown
vulnerabilities. A Java version is also available, which works with any
Servlet 2.3 compatible web server.


Changes (v1.8.7)
----------------

* Stefan Esser discovered a trivial way to craft request to sneak
   in the request parameters that are in the request body past the
   named parameter syntax (e.g. ARG_name). Non-selective filtering
   (SecFilter), other variables (e.g. THE_REQUEST, ARGS, POST_PAYLOAD),
   and the audit log worked fine. Fixed.

* Stefan Esser also pointed out PHP parses cookies differently from
   mod_security, and demonstrated a way to exploit the differences
   to sneak in a cookie past the named cookie syntax (e.g. COOKIE_name).
   So I decided to add another cookie parser to mod_security. A new
   directive, SecFilterCookieFormat, determines which parser is used.
   Possible values are 0 (default, for Netscape-style cookies, aka
   version 0) and 1 (for RFC 2965 aka version 1 cookies). Without
   spending more time on research (to determine how different platforms
   parse cookies) -- which is on my TODO list -- I can't give a
   definitive answer whether the COOKIE_name syntax is good enough. It
   should be, but if you are very paranoid you may choose to use the
   HTTP_Cookie syntax to examine the whole cookie header. Look for more
   details in the documentation. As a consequence of the recent changes,
   the SecFilterCheckCookieFormat directive is now obsolete and has
   no effect.

* BUG Request error messages are now escaped properly when logged
   to the audit log.

* BUG (Apache 2 only) Failure to execute external scripts is now
   properly detected and logged.

* BUG If the approver script does not exist the file is rejected.

* BUG (Apache 2 only) Made the allow action work with output
   filtering.

* BUG (Apache 2 only) Warning messages (e.g. "log,pass") did
   not get logged in output filtering.

* Cookie normalization is now off by default (as was stated in the
   documentation previously).

* BUG (Apache 2 only) The audit logging code can cause a segfault
   when it isn't explicitly configured in the configuration, and
   the main handler does not run for some reason. Fixed.

* BUG (Apache 2 only) Fixed a bug in the code that handles the exec
   action, which would sometimes cause a segfault (when an external
   script is executed).

--
Ivan Ristic
Apache Security (O'Reilly) - http://www.apachesecurity.net Open source web
application firewall - http://www.modsecurity.org




-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
_______________________________________________
mod-security-users mailing list
mod...@li...
https://lists.sourceforge.net/lists/listinfo/mod-security-users

[mod-security-users] External Web Application Protection: Impedance Mismatch

[Ivan R. <iv...@we...>]

Here's another post that addresses the issues inherent to external
web application protection. (It also explains why I changed cookie
parsers in a minor release.)

External Web Application Protection: Impedance Mismatch
http://www.modsecurity.org/blog/archives/000053.html

-- 
Ivan Ristic
Apache Security (O'Reilly) - http://www.apachesecurity.net
Open source web application firewall - http://www.modsecurity.org

Re: [mod-security-users] [ANNOUNCE] ModSecurity 1.8.7 has been released

[Ivan R. <iv...@we...>]

Mark wrote:
 >
> But I already downloaded 1.8.7 on the 6th. Is this still the
> same release?

   Yes it is. I just couldn't find the time to write & send the
   announcements sooner.

-- 
Ivan Ristic
Apache Security (O'Reilly) - http://www.apachesecurity.net
Open source web application firewall - http://www.modsecurity.org

RE: [mod-security-users] [ANNOUNCE] ModSecurity 1.8.7 has been released

[Mark <ad...@as...>]

> -----Original Message-----
> From: mod...@li... 
> [mailto:mod...@li...] On 
> Behalf Of Ivan Ristic
> Sent: woensdag 9 maart 2005 11:07
> To: mod...@li...
> Subject: Re: [mod-security-users] [ANNOUNCE] ModSecurity 
> 1.8.7 has been released
> 
> 
> Gerwin Krist -|- Digitalus Webhosting wrote:
> > -----BEGIN PGP SIGNED MESSAGE-----
> > Hash: SHA1
> > 
> > Great ivan :) Will do some testing ....
> 
>    Maybe next time I can notify you *before* I make a release
>    for testing? :)

Great!

But I already downloaded 1.8.7 on the 6th. Is this still the
same release?

- Mark 
 
        System Administrator Asarian-host.org
 
---
"If you were supposed to understand it,
we wouldn't call it code." - FedEx

Re: [mod-security-users] [ANNOUNCE] ModSecurity 1.8.7 has been released

[Ivan R. <iv...@we...>]

Gerwin Krist -|- Digitalus Webhosting wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Great ivan :) Will do some testing ....

   Maybe next time I can notify you *before* I make a release for
   testing? :)

   Speaking of which, if there's anyone interested to give a RC
   release a quick compile and test drive please let me know. I still
   test only on Linux.

-- 
Ivan Ristic
Apache Security (O'Reilly) - http://www.apachesecurity.net
Open source web application firewall - http://www.modsecurity.org

Re: [mod-security-users] [ANNOUNCE] ModSecurity 1.8.7 has been released

[Gerwin K. -|- D. W. <ge...@di...>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Great ivan :) Will do some testing ....

Ivan Ristic wrote:
|
| ModSecurity 1.8.7 has been released. It is available for immediate
| download from:
|
|     http://www.modsecurity.org/download/
|
| This release brings a mixture of small bug fixes, one minor security
| fix, and minor enhancements. Cookie parsing has been enhanced.
| ModSecurity now has two cookie parsers, one for each major version of
| the specification. Failures to execute external scripts are now properly
| logged. If the approver script is missing or not working the request is
| now rejected. A bug that allows attacker to bypass some of the checks is
| now fixed.
|
|
| About ModSecurity
| -----------------
| ModSecurity is a web application firewall, designed to protect
| vulnerable applications and reject manual and automated attacks.
| It is an open source intrusion detection and prevention system. It
| can work embedded in Apache, or as a standalone security device when
| configured to work as part of an Apache-based reverse proxy.
|
| Optionally, ModSecurity creates application audit logs, which contain
| the full request body in addition to all other details. Requests are
| filtered using regular expressions. Some of the things possible are:
|
|   * Apply filters against any part of the request (URI,
|     headers, either GET or POST)
|   * Apply filters against individual parameters
|   * Reject SQL injection attacks
|   * Reject Cross site scripting attacks
|   * Store the files uploaded through the web server, and have them
|     checked by external scripts
|
| With few general rules ModSecurity can protect from both known
| and unknown vulnerabilities. A Java version is also available, which
| works with any Servlet 2.3 compatible web server.
|
|
| Changes (v1.8.7)
| ----------------
|
| * Stefan Esser discovered a trivial way to craft request to sneak
|   in the request parameters that are in the request body past the
|   named parameter syntax (e.g. ARG_name). Non-selective filtering
|   (SecFilter), other variables (e.g. THE_REQUEST, ARGS, POST_PAYLOAD),
|   and the audit log worked fine. Fixed.
|
| * Stefan Esser also pointed out PHP parses cookies differently from
|   mod_security, and demonstrated a way to exploit the differences
|   to sneak in a cookie past the named cookie syntax (e.g. COOKIE_name).
|   So I decided to add another cookie parser to mod_security. A new
|   directive, SecFilterCookieFormat, determines which parser is used.
|   Possible values are 0 (default, for Netscape-style cookies, aka
|   version 0) and 1 (for RFC 2965 aka version 1 cookies). Without
|   spending more time on research (to determine how different platforms
|   parse cookies) -- which is on my TODO list -- I can't give a
|   definitive answer whether the COOKIE_name syntax is good enough. It
|   should be, but if you are very paranoid you may choose to use the
|   HTTP_Cookie syntax to examine the whole cookie header. Look for more
|   details in the documentation. As a consequence of the recent changes,
|   the SecFilterCheckCookieFormat directive is now obsolete and has
|   no effect.
|
| * BUG Request error messages are now escaped properly when logged
|   to the audit log.
|
| * BUG (Apache 2 only) Failure to execute external scripts is now
|   properly detected and logged.
|
| * BUG If the approver script does not exist the file is rejected.
|
| * BUG (Apache 2 only) Made the allow action work with output
|   filtering.
|
| * BUG (Apache 2 only) Warning messages (e.g. "log,pass") did
|   not get logged in output filtering.
|
| * Cookie normalization is now off by default (as was stated in the
|   documentation previously).
|
| * BUG (Apache 2 only) The audit logging code can cause a segfault
|   when it isn't explicitly configured in the configuration, and
|   the main handler does not run for some reason. Fixed.
|
| * BUG (Apache 2 only) Fixed a bug in the code that handles the exec
|   action, which would sometimes cause a segfault (when an external
|   script is executed).
|


- --
Met vriendelijke groet/With kind regards,

Gerwin Krist

Digitalus
First-class Internet Webhosting

(w) http://www.digitalus.nl
(e) gerwin at digitalus.nl
(p) PGP-ID: 79B325D4
(t) +31 (0) 598 630000
(f) +31 (0) 598 631860


***************************************************************************************
This message may contain information which is confidential or privileged.
If you are not the intended recipient, please advise the sender immediately
by reply e-mail and delete this message and any attachments without
retaining
a copy.
***************************************************************************************


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQFCLsm/CwaJ0XmzJdQRAq5LAJ9OnxePfeUHX9xwAPkdrbKhFPJZbwCghbVI
coBoSBKAm/BQf/xowzs7yF8=
=qi9k
-----END PGP SIGNATURE-----

Re: [mod-security-users] regex for matching urls

[Ivan R. <iv...@we...>]

Peter Wood wrote:
> P.S.
> 
> The mod_security reference manual is excellent. Had I bothered to
> fully read the section on Path Normalization, I could have avoided
> asking this question. :-)

   Thanks. The manual does contain everything I know of ModSecurity,
   or at least everything I know I know. In retrospective, I wish it
   were more structured (e.g. a proper reference manual) but I "grew"
   it organically and it shows.

-- 
Ivan Ristic
Apache Security (O'Reilly) - http://www.apachesecurity.net
Open source web application firewall - http://www.modsecurity.org

[mod-security-users] [ANNOUNCE] ModSecurity 1.8.7 has been released

[Ivan R. <iv...@we...>]

ModSecurity 1.8.7 has been released. It is available for immediate
download from:

     http://www.modsecurity.org/download/

This release brings a mixture of small bug fixes, one minor security
fix, and minor enhancements. Cookie parsing has been enhanced.
ModSecurity now has two cookie parsers, one for each major version of
the specification. Failures to execute external scripts are now properly
logged. If the approver script is missing or not working the request is
now rejected. A bug that allows attacker to bypass some of the checks is
now fixed.


About ModSecurity
-----------------
ModSecurity is a web application firewall, designed to protect
vulnerable applications and reject manual and automated attacks.
It is an open source intrusion detection and prevention system. It
can work embedded in Apache, or as a standalone security device when
configured to work as part of an Apache-based reverse proxy.

Optionally, ModSecurity creates application audit logs, which contain
the full request body in addition to all other details. Requests are
filtered using regular expressions. Some of the things possible are:

   * Apply filters against any part of the request (URI,
     headers, either GET or POST)
   * Apply filters against individual parameters
   * Reject SQL injection attacks
   * Reject Cross site scripting attacks
   * Store the files uploaded through the web server, and have them
     checked by external scripts

With few general rules ModSecurity can protect from both known
and unknown vulnerabilities. A Java version is also available, which
works with any Servlet 2.3 compatible web server.


Changes (v1.8.7)
----------------

* Stefan Esser discovered a trivial way to craft request to sneak
   in the request parameters that are in the request body past the
   named parameter syntax (e.g. ARG_name). Non-selective filtering
   (SecFilter), other variables (e.g. THE_REQUEST, ARGS, POST_PAYLOAD),
   and the audit log worked fine. Fixed.

* Stefan Esser also pointed out PHP parses cookies differently from
   mod_security, and demonstrated a way to exploit the differences
   to sneak in a cookie past the named cookie syntax (e.g. COOKIE_name).
   So I decided to add another cookie parser to mod_security. A new
   directive, SecFilterCookieFormat, determines which parser is used.
   Possible values are 0 (default, for Netscape-style cookies, aka
   version 0) and 1 (for RFC 2965 aka version 1 cookies). Without
   spending more time on research (to determine how different platforms
   parse cookies) -- which is on my TODO list -- I can't give a
   definitive answer whether the COOKIE_name syntax is good enough. It
   should be, but if you are very paranoid you may choose to use the
   HTTP_Cookie syntax to examine the whole cookie header. Look for more
   details in the documentation. As a consequence of the recent changes,
   the SecFilterCheckCookieFormat directive is now obsolete and has
   no effect.

* BUG Request error messages are now escaped properly when logged
   to the audit log.

* BUG (Apache 2 only) Failure to execute external scripts is now
   properly detected and logged.

* BUG If the approver script does not exist the file is rejected.

* BUG (Apache 2 only) Made the allow action work with output
   filtering.

* BUG (Apache 2 only) Warning messages (e.g. "log,pass") did
   not get logged in output filtering.

* Cookie normalization is now off by default (as was stated in the
   documentation previously).

* BUG (Apache 2 only) The audit logging code can cause a segfault
   when it isn't explicitly configured in the configuration, and
   the main handler does not run for some reason. Fixed.

* BUG (Apache 2 only) Fixed a bug in the code that handles the exec
   action, which would sometimes cause a segfault (when an external
   script is executed).

-- 
Ivan Ristic
Apache Security (O'Reilly) - http://www.apachesecurity.net
Open source web application firewall - http://www.modsecurity.org

Re: [mod-security-users] regex for matching urls

[Tom A. <tan...@oa...>]

----- Original Message ----- 
From: "Ivan Ristic" <iv...@we...>
>   Try replacing \w with [:word:], but beware [:word:] works only
>   when used in [ and ]. So [\w\-_.]* becomes [[:word:]\-_.]

Or you could be a little more liberal and replace [\w\-_.]* with [^/]*

Tom

Re: [mod-security-users] regex for matching urls

[Peter W. <prw...@gm...>]

> 
>    Is he running Apache 1.x and you Apache 2.x?
> 

I'm running Apache 2.x... not sure what he's running, but you may be
on to something here. I keep forgetting that not everybody has jumped
on the Apache 2.x bandwagon. :-)

>    In my experience (I can't test now) \w does not work in Apache 1.x.
>    (Neither do \d and \s.) The really interesting thing is that the
>    documentation for Apache 1.x regex engine does not exist.
> 
>    Try replacing \w with [:word:], but beware [:word:] works only
>    when used in [ and ]. So [\w\-_.]* becomes [[:word:]\-_.]

Thanks, I'll have him try this.

Peter
-- 
Peter R. Wood | email: prw...@gm... | blog: http://prwdot.org/

Re: [mod-security-users] regex for matching urls

[Ivan R. <iv...@we...>]

Peter Wood wrote:
> I'm having someone help me test these rules. On my machine, this rule
> matches just fine. On his machine, it doesn't match at all. He is
> running mod_security 1.8.6, I'm running 1.8.7. Is there any difference
> in between the two that might cause this not to match?

   No, there shouldn't be any.

   Is he running Apache 1.x and you Apache 2.x?

   These two have completely different regular expression
   engines. (The one in Apache 2.x being much better.)

   In my experience (I can't test now) \w does not work in Apache 1.x.
   (Neither do \d and \s.) The really interesting thing is that the
   documentation for Apache 1.x regex engine does not exist.

   Try replacing \w with [:word:], but beware [:word:] works only
   when used in [ and ]. So [\w\-_.]* becomes [[:word:]\-_.]

-- 
Ivan Ristic
Apache Security (O'Reilly) - http://www.apachesecurity.net
Open source web application firewall - http://www.modsecurity.org

Re: [mod-security-users] regex for matching urls

[Peter W. <prw...@gm...>]

I'm having someone help me test these rules. On my machine, this rule
matches just fine. On his machine, it doesn't match at all. He is
running mod_security 1.8.6, I'm running 1.8.7. Is there any difference
in between the two that might cause this not to match?

SecFilterSelective HTTP_Referer|ARGS
"[a-z]+:/[\w\-_.]*online[\w\-_.]*\.[a-z]{2,}"

Matches e.g. http://www.buy-online.com/ on my machine, but not on his.

- Peter

On Mon, 07 Mar 2005 16:58:26 +0000, Ivan Ristic <iv...@we...> wrote:
> Peter Wood wrote:
> > Ivan,
> >
> > Thanks for the response. Can you suggest any way to work around this
> > so that we can match 'http://'? Would '/{2}' work, or would that also
> > be normalized?
> 
>    Normalisation is not performed against the regex, only against
>    the incoming data. In the regex just use "http:/" instead of
>    "http://" and you should be fine.
> 
> --
> Ivan Ristic
> Apache Security (O'Reilly) - http://www.apachesecurity.net
> Open source web application firewall - http://www.modsecurity.org
> 
> -------------------------------------------------------
> SF email is sponsored by - The IT Product Guide
> Read honest & candid reviews on hundreds of IT Products from real users.
> Discover which products truly live up to the hype. Start reading now.
> http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
> _______________________________________________
> mod-security-users mailing list
> mod...@li...
> https://lists.sourceforge.net/lists/listinfo/mod-security-users
> 


-- 
Peter R. Wood | email: prw...@gm... | blog: http://prwdot.org/

Re: [mod-security-users] regex for matching urls

[Peter W. <prw...@gm...>]

Tom,

> Then it will match whether you use normalization or not.  Better still:
> 
> SecFilterSelective HTTP_Referer|ARGS
> "(ht|f)tps?:/{1,2}[\w\-_.]*poker[\w\-_.]*\.[a-z]{2,4}(/|$)"
> 

Thanks for this. I had considered using {2,4} for the TLD... as far as
I know there aren't any TLD's with length > 4, but it could always
happen, which is why I had left that as just {2,}... also I'd
personally prefer to be a bit liberal as to what can appear before the
:// in a URL... you never know what crazy schemes attackers will think
up...

Peter
-- 
Peter R. Wood | email: prw...@gm... | blog: http://prwdot.org/

Re: [mod-security-users] regex for matching urls

[Tom A. <tan...@oa...>]

SecFilterSelective HTTP_Referer|ARGS
"[a-z]+:/+[\w\-_.]*poker[\w\-_.]*\.[a-z]{2,}"

That will work whether there's one or two (or more) slashes.  For just one 
or two, try:

SecFilterSelective HTTP_Referer|ARGS
"[a-z]+:/{1,2}[\w\-_.]*poker[\w\-_.]*\.[a-z]{2,}"

Then it will match whether you use normalization or not.  Better still:

SecFilterSelective HTTP_Referer|ARGS
"(ht|f)tps?:/{1,2}[\w\-_.]*poker[\w\-_.]*\.[a-z]{2,4}(/|$)"

Tom


----- Original Message ----- 
From: "Peter Wood" <prw...@gm...>
To: <mod...@li...>
Sent: Monday, March 07, 2005 11:55 AM
Subject: Re: [mod-security-users] regex for matching urls


> Hrm, never mind, I just tried that, and it didn't work either... any
> other way around it?
>
>
> On Mon, 7 Mar 2005 11:45:37 -0500, Peter Wood <prw...@gm...> wrote:
>> Ivan,
>>
>> Thanks for the response. Can you suggest any way to work around this
>> so that we can match 'http://'? Would '/{2}' work, or would that also
>> be normalized?
>>
>> Thanks,
>>
>> Peter
>>
>>
>> On Mon, 07 Mar 2005 16:45:58 +0000, Ivan Ristic <iv...@we...> 
>> wrote:
>> > Peter Wood wrote:
>> > > Greetings,
>> >
>> > > What is wrong with '[a-z]+://' ?
>> >
>> >    Before regular expression is applied to a piece of data
>> >    mod_security performs data normalization and reduces
>> >    redundant forward slashes. Thus "http://" becomes "http:/".
>> >
>> >    (No, I don't like it either. That's why in 1.9 normalization
>> >     will become optional and configurable per-rule.)
>> >
>> > --
>> > Ivan Ristic
>> > Apache Security (O'Reilly) - http://www.apachesecurity.net
>> > Open source web application firewall - http://www.modsecurity.org
>> >
>> > -------------------------------------------------------
>> > SF email is sponsored by - The IT Product Guide
>> > Read honest & candid reviews on hundreds of IT Products from real 
>> > users.
>> > Discover which products truly live up to the hype. Start reading now.
>> > http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
>> > _______________________________________________
>> > mod-security-users mailing list
>> > mod...@li...
>> > https://lists.sourceforge.net/lists/listinfo/mod-security-users
>> >
>>
>> --
>> Peter R. Wood | email: prw...@gm... | blog: http://prwdot.org/
>>
>
>
> -- 
> Peter R. Wood | email: prw...@gm... | blog: http://prwdot.org/
>
>
> -------------------------------------------------------
> SF email is sponsored by - The IT Product Guide
> Read honest & candid reviews on hundreds of IT Products from real users.
> Discover which products truly live up to the hype. Start reading now.
> http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
> _______________________________________________
> mod-security-users mailing list
> mod...@li...
> https://lists.sourceforge.net/lists/listinfo/mod-security-users 

Re: [mod-security-users] regex for matching urls

[Peter W. <prw...@gm...>]

P.S.

The mod_security reference manual is excellent. Had I bothered to
fully read the section on Path Normalization, I could have avoided
asking this question. :-)

Peter


On Mon, 07 Mar 2005 16:58:26 +0000, Ivan Ristic <iv...@we...> wrote:
> Peter Wood wrote:
> > Ivan,
> >
> > Thanks for the response. Can you suggest any way to work around this
> > so that we can match 'http://'? Would '/{2}' work, or would that also
> > be normalized?
> 
>    Normalisation is not performed against the regex, only against
>    the incoming data. In the regex just use "http:/" instead of
>    "http://" and you should be fine.
> 
> --
> Ivan Ristic
> Apache Security (O'Reilly) - http://www.apachesecurity.net
> Open source web application firewall - http://www.modsecurity.org
> 
> -------------------------------------------------------
> SF email is sponsored by - The IT Product Guide
> Read honest & candid reviews on hundreds of IT Products from real users.
> Discover which products truly live up to the hype. Start reading now.
> http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
> _______________________________________________
> mod-security-users mailing list
> mod...@li...
> https://lists.sourceforge.net/lists/listinfo/mod-security-users
> 


-- 
Peter R. Wood | email: prw...@gm... | blog: http://prwdot.org/

Re: [mod-security-users] regex for matching urls

[Peter W. <prw...@gm...>]

Ah, excellent! I just took the extra / out and it works great now. Thanks!


On Mon, 07 Mar 2005 16:58:26 +0000, Ivan Ristic <iv...@we...> wrote:
> Peter Wood wrote:
> > Ivan,
> >
> > Thanks for the response. Can you suggest any way to work around this
> > so that we can match 'http://'? Would '/{2}' work, or would that also
> > be normalized?
> 
>    Normalisation is not performed against the regex, only against
>    the incoming data. In the regex just use "http:/" instead of
>    "http://" and you should be fine.
> 
> --
> Ivan Ristic
> Apache Security (O'Reilly) - http://www.apachesecurity.net
> Open source web application firewall - http://www.modsecurity.org
> 
> -------------------------------------------------------
> SF email is sponsored by - The IT Product Guide
> Read honest & candid reviews on hundreds of IT Products from real users.
> Discover which products truly live up to the hype. Start reading now.
> http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
> _______________________________________________
> mod-security-users mailing list
> mod...@li...
> https://lists.sourceforge.net/lists/listinfo/mod-security-users
> 


-- 
Peter R. Wood | email: prw...@gm... | blog: http://prwdot.org/

Re: [mod-security-users] regex for matching urls

[Peter W. <prw...@gm...>]

Hrm, never mind, I just tried that, and it didn't work either... any
other way around it?


On Mon, 7 Mar 2005 11:45:37 -0500, Peter Wood <prw...@gm...> wrote:
> Ivan,
> 
> Thanks for the response. Can you suggest any way to work around this
> so that we can match 'http://'? Would '/{2}' work, or would that also
> be normalized?
> 
> Thanks,
> 
> Peter
> 
> 
> On Mon, 07 Mar 2005 16:45:58 +0000, Ivan Ristic <iv...@we...> wrote:
> > Peter Wood wrote:
> > > Greetings,
> >
> > > What is wrong with '[a-z]+://' ?
> >
> >    Before regular expression is applied to a piece of data
> >    mod_security performs data normalization and reduces
> >    redundant forward slashes. Thus "http://" becomes "http:/".
> >
> >    (No, I don't like it either. That's why in 1.9 normalization
> >     will become optional and configurable per-rule.)
> >
> > --
> > Ivan Ristic
> > Apache Security (O'Reilly) - http://www.apachesecurity.net
> > Open source web application firewall - http://www.modsecurity.org
> >
> > -------------------------------------------------------
> > SF email is sponsored by - The IT Product Guide
> > Read honest & candid reviews on hundreds of IT Products from real users.
> > Discover which products truly live up to the hype. Start reading now.
> > http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
> > _______________________________________________
> > mod-security-users mailing list
> > mod...@li...
> > https://lists.sourceforge.net/lists/listinfo/mod-security-users
> >
> 
> --
> Peter R. Wood | email: prw...@gm... | blog: http://prwdot.org/
> 


-- 
Peter R. Wood | email: prw...@gm... | blog: http://prwdot.org/

Re: [mod-security-users] regex for matching urls

[Ivan R. <iv...@we...>]

Peter Wood wrote:
> Ivan,
> 
> Thanks for the response. Can you suggest any way to work around this
> so that we can match 'http://'? Would '/{2}' work, or would that also
> be normalized?

   Normalisation is not performed against the regex, only against
   the incoming data. In the regex just use "http:/" instead of
   "http://" and you should be fine.

-- 
Ivan Ristic
Apache Security (O'Reilly) - http://www.apachesecurity.net
Open source web application firewall - http://www.modsecurity.org