mod-security-users Mailing List for ModSecurity (Page 529)
Brought to you by:
victorhora,
zimmerletw
Menu
▾
▴
mod-security-users — General discussion about mod_security
You can subscribe to this list here.
| 2003 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
(2) |
Jul
(17) |
Aug
(7) |
Sep
(8) |
Oct
(11) |
Nov
(14) |
Dec
(19) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2004 |
Jan
(46) |
Feb
(14) |
Mar
(20) |
Apr
(48) |
May
(15) |
Jun
(20) |
Jul
(36) |
Aug
(24) |
Sep
(31) |
Oct
(28) |
Nov
(23) |
Dec
(12) |
| 2005 |
Jan
(69) |
Feb
(61) |
Mar
(82) |
Apr
(53) |
May
(26) |
Jun
(71) |
Jul
(27) |
Aug
(52) |
Sep
(28) |
Oct
(49) |
Nov
(104) |
Dec
(74) |
| 2006 |
Jan
(61) |
Feb
(148) |
Mar
(82) |
Apr
(139) |
May
(65) |
Jun
(116) |
Jul
(92) |
Aug
(101) |
Sep
(84) |
Oct
(103) |
Nov
(174) |
Dec
(102) |
| 2007 |
Jan
(166) |
Feb
(161) |
Mar
(181) |
Apr
(152) |
May
(192) |
Jun
(250) |
Jul
(127) |
Aug
(165) |
Sep
(97) |
Oct
(135) |
Nov
(206) |
Dec
(56) |
| 2008 |
Jan
(160) |
Feb
(135) |
Mar
(98) |
Apr
(89) |
May
(115) |
Jun
(95) |
Jul
(188) |
Aug
(167) |
Sep
(153) |
Oct
(84) |
Nov
(82) |
Dec
(85) |
| 2009 |
Jan
(139) |
Feb
(133) |
Mar
(128) |
Apr
(105) |
May
(135) |
Jun
(79) |
Jul
(92) |
Aug
(134) |
Sep
(73) |
Oct
(112) |
Nov
(159) |
Dec
(80) |
| 2010 |
Jan
(100) |
Feb
(116) |
Mar
(130) |
Apr
(59) |
May
(88) |
Jun
(59) |
Jul
(69) |
Aug
(67) |
Sep
(82) |
Oct
(76) |
Nov
(59) |
Dec
(34) |
| 2011 |
Jan
(84) |
Feb
(74) |
Mar
(81) |
Apr
(94) |
May
(188) |
Jun
(72) |
Jul
(118) |
Aug
(109) |
Sep
(111) |
Oct
(80) |
Nov
(51) |
Dec
(44) |
| 2012 |
Jan
(80) |
Feb
(123) |
Mar
(46) |
Apr
(12) |
May
(40) |
Jun
(62) |
Jul
(95) |
Aug
(66) |
Sep
(65) |
Oct
(53) |
Nov
(42) |
Dec
(60) |
| 2013 |
Jan
(96) |
Feb
(96) |
Mar
(108) |
Apr
(72) |
May
(115) |
Jun
(111) |
Jul
(114) |
Aug
(87) |
Sep
(93) |
Oct
(97) |
Nov
(104) |
Dec
(82) |
| 2014 |
Jan
(96) |
Feb
(77) |
Mar
(71) |
Apr
(40) |
May
(48) |
Jun
(78) |
Jul
(54) |
Aug
(44) |
Sep
(58) |
Oct
(79) |
Nov
(51) |
Dec
(52) |
| 2015 |
Jan
(55) |
Feb
(59) |
Mar
(48) |
Apr
(40) |
May
(45) |
Jun
(63) |
Jul
(36) |
Aug
(49) |
Sep
(35) |
Oct
(58) |
Nov
(21) |
Dec
(47) |
| 2016 |
Jan
(35) |
Feb
(81) |
Mar
(43) |
Apr
(41) |
May
(77) |
Jun
(52) |
Jul
(39) |
Aug
(34) |
Sep
(107) |
Oct
(67) |
Nov
(54) |
Dec
(20) |
| 2017 |
Jan
(99) |
Feb
(37) |
Mar
(86) |
Apr
(47) |
May
(57) |
Jun
(55) |
Jul
(34) |
Aug
(31) |
Sep
(16) |
Oct
(49) |
Nov
(53) |
Dec
(33) |
| 2018 |
Jan
(25) |
Feb
(11) |
Mar
(79) |
Apr
(77) |
May
(5) |
Jun
(19) |
Jul
(17) |
Aug
(7) |
Sep
(13) |
Oct
(22) |
Nov
(13) |
Dec
(68) |
| 2019 |
Jan
(44) |
Feb
(17) |
Mar
(40) |
Apr
(39) |
May
(18) |
Jun
(14) |
Jul
(20) |
Aug
(31) |
Sep
(11) |
Oct
(35) |
Nov
(3) |
Dec
(10) |
| 2020 |
Jan
(32) |
Feb
(16) |
Mar
(10) |
Apr
(22) |
May
(2) |
Jun
(34) |
Jul
(1) |
Aug
(8) |
Sep
(36) |
Oct
(16) |
Nov
(13) |
Dec
(10) |
| 2021 |
Jan
(16) |
Feb
(23) |
Mar
(45) |
Apr
(28) |
May
(6) |
Jun
(17) |
Jul
(8) |
Aug
(1) |
Sep
(2) |
Oct
(35) |
Nov
|
Dec
(5) |
| 2022 |
Jan
|
Feb
(17) |
Mar
(23) |
Apr
(23) |
May
(9) |
Jun
(8) |
Jul
|
Aug
|
Sep
(7) |
Oct
(5) |
Nov
(16) |
Dec
(4) |
| 2023 |
Jan
|
Feb
|
Mar
(3) |
Apr
|
May
(1) |
Jun
(4) |
Jul
(1) |
Aug
|
Sep
(2) |
Oct
(1) |
Nov
|
Dec
|
| 2024 |
Jan
(7) |
Feb
(13) |
Mar
(18) |
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
(2) |
Oct
(1) |
Nov
(5) |
Dec
(3) |
| 2025 |
Jan
|
Feb
|
Mar
|
Apr
(12) |
May
(12) |
Jun
(2) |
Jul
(3) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: Justin G. <web...@sw...> - 2006-04-17 18:40:22
|
hi, I'm looking into using gotroot's blacklist.conf but would like to restrict processing rules in this file only to specific scripts that need it, not load it like any other rules file, since the load goes very high on a busy server. thanks, Justin |
|
From: Ivan R. <iva...@gm...> - 2006-04-17 18:06:05
|
On 4/17/06, Jim McCullars <ji...@in...> wrote: > > On Mon, 17 Apr 2006, Ivan Ristic wrote: > > > The bad news is that v2.0 wil not be backward compatible. I have taken > > Will it still work with Apache 1.3x? Yes. But it will be released for Apache 2.0.x first, then ported to Apache 1.3.x. -- Ivan Ristic, Technical Director Thinking Stone, http://www.thinkingstone.com ModSecurity: Open source Web Application Firewall |
|
From: Jim M. <ji...@in...> - 2006-04-17 17:59:49
|
On Mon, 17 Apr 2006, Ivan Ristic wrote: > The bad news is that v2.0 wil not be backward compatible. I have taken Will it still work with Apache 1.3x? Jim McCullars University of Alabama in Huntsville |
|
From: Ivan R. <iva...@gm...> - 2006-04-17 16:59:49
|
Thank you all for your support. Let us forget about this little incident and continue as usual. I've been busy rewriting major parts of ModSecurity code. In a week's time I should have another development version for you to test. The bad news is that v2.0 wil not be backward compatible. I have taken this opportunity to remove some of the old baggage and a lot of small things that did not make sense (but were a byproduct of the evolution process). The good news is there are many exciting improvements. For example: 1. No more built-in normalisation features. One is now able to configure normalisation options exactly as it is needed. Plus, there are several new normalisation options. 2. Processing is split into five phases. One of the phases now runs immediatelly after Apache receives a request. 3. Support for XML processing, DTD and Schema validation, XPath expressions= . -- Ivan Ristic, Technical Director Thinking Stone, http://www.thinkingstone.com ModSecurity: Open source Web Application Firewall |
|
From: Jim M. <ji...@in...> - 2006-04-17 14:14:37
|
On Sat, 15 Apr 2006, Thomas Anderson wrote: > Ivan, for what it's worth, I've found the online documentation to be > above and beyond what most open-source software provides. Mod_security > is fantastic and does just what I need it to. It is not, and never > should become, a hobbyist tool. It is a powerful filter for experienced > sysadmins. I'll second this. I found mod_security when looking for a way to stop SMTP header injection attacks against an unsecured PHP script, after someone used our web server to send mass amounts of spam. Had it not been for mod_security, I would have had to seriously consider removing PHP from my web server. Jim McCullars University of Alabama in Huntsville |
|
From: BassPlayer <bas...@an...> - 2006-04-16 18:42:21
|
I'd also like to thank Ivan for a gret tool. It also is an essential part of my toolbox. It was very easy to instal and the documentation what easy to read. Thanks again. BP Jason Edgecombe wrote: > Thomas Anderson wrote: >> Ivan, for what it's worth, I've found the online documentation to be >> above and beyond what most open-source software provides. Mod_security >> is fantastic and does just what I need it to. It is not, and never >> should become, a hobbyist tool. It is a powerful filter for experienced >> sysadmins. I for one appreciate your unwillingness to add unnecesary >> fluff. >> > > I emphatically second that! > > Mod-security is a crucial defense for my servers. It's one of the first > packages that I install on a new server. > > In addition to the standard usage on my servers, it's a critical spam > fighting tool on my weblog server. I use mod_security along with some > custom scripts to report spammers to the dns blacklists. > > Thanks! > Jason > > > ------------------------------------------------------- > This SF.Net email is sponsored by xPML, a groundbreaking scripting > language > that extends applications into web and mobile media. Attend the live > webcast > and join the prime developer group breaking into this new coding > territory! > http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642 > _______________________________________________ > mod-security-users mailing list > mod...@li... > https://lists.sourceforge.net/lists/listinfo/mod-security-users > > !DSPAM:44424a9c31161483726371! > |
|
From: Jason E. <jed...@ca...> - 2006-04-16 13:15:48
|
Thomas Anderson wrote: > Ivan, for what it's worth, I've found the online documentation to be > above and beyond what most open-source software provides. Mod_security > is fantastic and does just what I need it to. It is not, and never > should become, a hobbyist tool. It is a powerful filter for experienced > sysadmins. I for one appreciate your unwillingness to add unnecesary > fluff. > I emphatically second that! Mod-security is a crucial defense for my servers. It's one of the first packages that I install on a new server. In addition to the standard usage on my servers, it's a critical spam fighting tool on my weblog server. I use mod_security along with some custom scripts to report spammers to the dns blacklists. Thanks! Jason |
|
From: Thomas A. <tan...@oa...> - 2006-04-16 03:18:04
|
Ivan, for what it's worth, I've found the online documentation to be above and beyond what most open-source software provides. Mod_security is fantastic and does just what I need it to. It is not, and never should become, a hobbyist tool. It is a powerful filter for experienced sysadmins. I for one appreciate your unwillingness to add unnecesary fluff. Mr. Barbish clearly did not have the aptitude to use mod_security, even with the extraordinary patience and goodwill from this list. Tom |
|
From: joe b. <joe...@ya...> - 2006-04-15 23:55:30
|
Hay it's all yours, run with it and make it happen or not.
Write it up any way you want.
Calling mod_security a firewall is a great stretch of the truth. A pet hobby of yours is more to the point.
Since this is hosted by sourceforge I though it was a public group development project. Seems I was wrong in that.
The current manual is useless and is an embarrassment coming from some one with your professional background. I seen high school kids write more informative computer software documentation. There is no excuse for this. No need to write a book or create an updated version until you have usable documentation. Invest your time where it will be most useful.
Now I understand why I could not find any one who uses it when asked on different UNIX-like system questions lists.
After reading your repeated references to your upcoming book. Publishing poor public documentation as a way to entice people to purchase this book is not the way to market your talents.
That's the conclusions I have come to from this exchange of emails.
I know a dead end when I bump into it.
You can lead a stubborn horse to water but you can't make it drink.
Leaving the list now never to return
Ivan Ristic <iva...@gm...> wrote:
I appreciate your entusiasm but I am afraid your addition is not going
to make it into the manual. There are several reasons for this. A
major one is that I simply disagree with your statement that
ModSecurity has a "default usage strategy". ModSecurity is just a tool
that you can use one way or another.
Secondly, the advice you are giving in the text simply does not work.
I wish I had the time to explain every single problem in there but I
simply don't. Sorry. And it certainly isn't helping that you are
ignoring the advice I am giving you (see below).You can learn these
things by yourself
but you'd have to learn much more about HTTP and do
a lot of testing.
I said the same thing in the manual documantation I wrote as a reason why mod_security can not be used by normal apache admin people. Thanks for making my point in your own words.
I saw no need to wast more time changing what was all ready written so I did not correct it per your advice.
---------------------------------
How low will we go? Check out Yahoo! Messengers low PC-to-Phone call rates. |
|
From: Ivan R. <iva...@gm...> - 2006-04-15 20:27:17
|
On 4/15/06, joe barbish <joe...@ya...> wrote:
>
> I have written a new section to the manual which may better explain where=
I
> am headed with all this. I have attached it to this email. Check out new
> section called "web Application firewall". This is really the direction I
> think you should be taking with mod_security. This new strategy in using
> mod_security is my "pay it foward" contribution to the project. I await
> your feedback.
I appreciate your entusiasm but I am afraid your addition is not going
to make it into the manual. There are several reasons for this. A
major one is that I simply disagree with your statement that
ModSecurity has a "default usage strategy". ModSecurity is just a tool
that you can use one way or another.
Secondly, the advice you are giving in the text simply does not work.
I wish I had the time to explain every single problem in there but I
simply don't. Sorry. And it certainly isn't helping that you are
ignoring the advice I am giving you (see below).You can learn these
things by yourself but you'd have to learn much more about HTTP and do
a lot of testing.
> > # The logon membership process
> > # This script contains both the show form and process form functions.
> > # Need one rule to allow the show form function
> > # and second rule chained to the POST_PAYLOAD rule for
> > # the process form function.
> > SecFilterSelective REQUEST_URI "^/logon.php$" allow
> > SecFilterSelective REQUEST_URI "^/logon.php$" chain
>
> You don't need (nor want) the first of the two lines above. The first
> line will allow the transaction to proceed based only on the URI.
> Invalid values for parameters would be allowed.
>
> my reply*** I think you did not understand the comments in front of this
> code group.
> The second rule belongs to the 2 rules it is chained to. This way that po=
st
> will only be allowed if it matches all 3 conditions.
I don't think you are reading what I'm saying. The second rule and the
other rules chained to it will *never* execute. Nothing happens after
"allow" takes place.
> > SecFilterSelective COOKIE_PHPSESSID "^[0-9a-fA-F]{32}$" chain
> > SecFilterSelective POST_PAYLOAD \
> > "^id=3D[0-9a-z]{15,}$ \
> > &pw=3D[0-9a-z]{15,}$ \
> > &userdigit=3D[0-9a-z]{5,}$ \
> > &submit=3DSubmit$"
>
> I don't see the above working. You are using multiple lines but you
> may not be realising the empty space at the beginning of every new
> line is becoming part of the regular expression. You should use one
> rule per variable you want checked.
>
> myreply*** so are you saying the continuation has to start on pos 1 of =
new
> line and the \ can not have space before it? Could this be a bug in how
> mod_security handles regular _expression continuations? I dont remember p=
hp
> or perl or shell sh scripting regular _expression acting this way.
No, it isn't a bug. And it isn't even handled by ModSecurity.
> > All feedback is welcome.
>
> You should test your configuration using real-life examples. There's a
> nice utility included in the ModSecurity distribution, run-test.pl,
> which sends a raw request (contained in a file) to the web server.
> What you need to do is gather a bunch of requests, some valid some
> not, throw them against your web server and verify the reponse status
> codes are as you want them to be. That's the only way to foolproof
> your configuration.
>
> myreply*** I did test a lot during development. I have testbench with
> apache server box on same lan as my box I develope the code on. The deb=
ug
> log showed me what was happening.
Then you need to do more tests because your rules aren't working as
you want them to.
> Does this run-test.pl come with file
> containing invalid requests to run? How does a person create these real l=
ife
> requests to test with?
By crafting attacks against the application and watching if the rules
catch them.
> I dont thing you have grasped the strategy I am employing here.
> What I am doing is "outside of the box" of how mod_security is normally
> used. Hopefully reading the section I want to add to the manual will shin=
e
> some light on things.
If that's the case then I am sorry I can't keep up with your thinking.
Good luck with your efforts!
--
Ivan Ristic, Technical Director
Thinking Stone, http://www.thinkingstone.com
ModSecurity: Open source Web Application Firewall
|
|
From: joe b. <joe...@ya...> - 2006-04-15 19:39:03
|
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<!-- saved from url=(0089) -->
<HTML><HEAD><TITLE>ModSecurity for Apache User Guide</TITLE>
<META http-equiv=Content-Type content="text/html; charset=ISO-8859-1"><LINK
href="ModSecurity for Apache User Guide_files/modsecurity-manual.css"
type=text/css rel=stylesheet>
<META content="Microsoft FrontPage 5.0" name=GENERATOR><LINK
title="ModSecurity for Apache User Guide" href="#N10001" rel=start><LINK
title=Introduction href="#01-introduction" rel=next></HEAD>
<BODY text=black vLink=#840084 aLink=#0000ff link=#0000ff bgColor=white>
<DIV
style="BORDER-TOP: #dddddd 1px solid; BACKGROUND: #f5f5f5; WIDTH: 100%; BORDER-BOTTOM: #dddddd 1px solid">
<DIV class=toc>
<P><B>Table of Contents</B></P>
<DL>
<DT><SPAN class=section><A
href="#01-introduction">Introduction</A></SPAN>
<DD>
<DL>
<DT><SPAN class=section><A
href="#N10034">Licensing</A></SPAN>
<DT><SPAN class=section><A
href="#N1004C">Acknowledgements</A></SPAN>
<DT><SPAN class=section><A
href="#N10051">Contact</A></SPAN></DT></DL>
<DT><SPAN class=section><A
href="#02-installation">Installation</A></SPAN>
<DD>
<DL>
<DT><SPAN class=section><A
href="#N10064">CVS
Access</A></SPAN>
<DT><SPAN class=section><A
href="#N10078">Nightly
Snapshot Download</A></SPAN>
<DT><SPAN class=section><A
href="#N10083">Stable
Release Download</A></SPAN>
<DT><SPAN class=section><A
href="#N1008C">Installing
from source</A></SPAN>
<DT><SPAN class=section><A
href="#N100EB">Installing
from binary</A></SPAN></DT></DL>
<DT><SPAN class=section><A
href="#wa-firewall">Web Application Firewall</A></SPAN>
<DD>
<DL>
<DT><SPAN class=section><A
href="#waf-bps">Bullet proof strategy</A></SPAN>
<DT><SPAN class=section><A
href="#waf-rt">Rules Template</A></SPAN>
<DT><SPAN class=section><A
href="#waf-rcn">Rule coding notes</A></SPAN>
</DT></DL>
</DL>
<DIV class=section lang=en>
<DIV class=section lang=en>
<PRE class=programlisting> </PRE></DIV></DIV></DIV>
<DIV class=section lang=en>
<DIV class=titlepage>
<DIV>
<DIV>
<H2 class=title style="CLEAR: both"><A
name=wa-firewall></A>Web Application Firewall</H2></DIV></DIV>
<DIV></DIV></DIV>
<P>ModSecurity default usage strategy has been to define the signatures of all
the known insert attack strings and then use that to scan all remote browser web
server requests for those signatures. The problem with this strategy is that
there are all ways new attack strings being developed by un-scrupulous people.
If an attacker selected an particular web site to study for weakness that
was already using all the published signature files provided on the
mod_security web site home page, this would not be sufficient to deny the attacker
from penetrating the target web application. For this signature strategy to be
successfully, mod_security would need a dedicated team of full time employees to
handle the coding deny rules for the new attack strings. In the MS/Windows world this would be
like what Norton Software does with their customer paid for virus signature
update service. Mod_security being an open source software product makes a
virus signature update service unfeasible. </p>
<P>An addition problem with this strategy is it takes a very knowledgeable
person in the inter-workings of HTTP requests to code an deny rules for new
signatures. This in most
cases precludes the majority of the home computer hobbyists and professional web
server administrators from being able to use this software.</p>
<P>ModSecurity does contain the capabilities for building rules which can bullet
proof an web application. To accomplish this an different strategy is
used. </p>
<P>The author of mod_security comes from the Apache security environment and as such
uses the Apache nomenclatures in the other sections of this manual. The
word 'Directives' is used in Apache documentation and the word 'Rules' is
commonly used in Unix firewall documentation. In this section the words 'rules'
& 'directives' are both used and represent the same thing.</p>
<DIV class=section lang=en>
<DIV class=titlepage>
<DIV>
<DIV>
<H3 class=title><A name=waf-bps></A>Bullet proof strategy</H3></DIV></DIV>
<DIV></DIV></DIV>
<P>This strategy is targeted at providing the home computer hobbyists and
professional web server administrators with an rule template which demonstrates
a standard way of coding rules to protect the 4 common types of web server
requests. This strategy is independent of the programming language used to
create the web application.</p>
<P>All browser requests contain the file name containing the HTML code and/or the
dynamic content programming language code to be executed by the server.
<span style="background-color: #00FFFF">The key to the Bullet proof strategy is
based on the user only having to code rules for each file which gets exchanged
between the host web server and the remote browser.</span> Any files which are
included into other files and/or other files which get processed by the logic
of the web application are excluded from needing mod_security rules. Protection from all malice code insert attempts is achieved by defining what is normally exchanged between the server and the remote browser
thus closeing the places where malice code can be inserted. This results in any
request not meeting the mod_secureity enforced standards per the users
coded rules being denied by default. This
strategy completely negates the need for using the known insert attack string
signatures files provided on the mod_security web site.</p>
<P>From the sample code provided even an novice with no programming knowledge
should be able to cut and past the rules to suit their web application.</p>
<P>The template starts with the mandatory directives section. This section
specifies the default rule values necessary for this template to function. The
user should have no need to change these rules and should use then as is.</p>
<P>After the mandatory directives section are the rules to protect the standard
4 HTTP request types. All the user has to do is copy the sample rule and modify
it to meet their needs. Basically that means changing the request file names to
ones in his web application and the post argument names to their own.</p>
<P>Type 1. is the most commonly used request type. This covers the normal
vanilla HTML display static content on the users remote browser.</p>
<P>Type 2. covers the use of HTML forms being processed by the very popular php
programming language. Using a different programming language for dynamic content
would only affect the file suffix. (i.e. .php to .pl for perl, ect). </p>
<P>Type 3. covers string parameter content attached to the requested file.</p>
<P>Type 4. covers the use of cookies </p>
<DIV class=section lang=en>
<DIV class=titlepage>
<DIV>
<DIV>
<H3 class=title><A name=waf-rt></A>Rules Template</H3></DIV></DIV>
<DIV></DIV></DIV>
<P>############# Start of mandatory directives ###################<br>
# Turn the filtering engine on or off<br>
secfilterengine on<br>
<br>
# Normalize cookie support<br>
SecFilterNormalizeCookies On<br>
<br>
# Enable version 1 (RFC 2965) cookies<br>
SecFilterCookieFormat 1<br>
<br>
# Check that url encoding is valid<br>
secfiltercheckurlencoding on<br>
<br>
# Unicode encoding check<br>
secfiltercheckunicodeencoding off<br>
<br>
# Only allow bytes from this range<br>
secfilterforcebyterange 1 255<br>
<br>
# Should forms post payloads be inspected<br>
secfilterscanpost on<br>
<br>
# The default setting sends the most important messages <br>
# (errors and warnings) to the Apache /var/log/httpd-error.log<br>
# only if there is no debug or custom log specified.<br>
SecFilterDefaultAction deny,log,status:404<br>
<br>
############# End of mandatory directives ###################<br>
<br>
# This is just for use during development to observe what happens.<br>
# In production the following 2 rules should be commented out.<br>
# You can change the unix path and log name to anything you want<br>
SecFilterDebugLog /var/log/modsec_debug_log<br>
SecFilterDebugLevel 9<br>
<br>
<br>
# Rule type 1.<br>
# Most heavily used files go first<br>
SecFilterSelective REQUEST_URI "^/web_style_sheet.css$" allow<br>
<br>
<br>
# Rule type 1.<br>
# This services the sample application frame home page<br>
SecFilterSelective REQUEST_URI "^/index.htm$"
allow<br>
SecFilterSelective REQUEST_URI "^/Header.htm$"
allow<br>
SecFilterSelective REQUEST_URI "^/home_page.php$"
allow<br>
SecFilterSelective REQUEST_URI "^/products.htm$" allow <br>
SecFilterSelective REQUEST_URI "^/powered_by_FreeBSD.gif$" allow<br>
SecFilterSelective REQUEST_URI "^/powered_by_apache.gif$"
allow <br>
<br>
# Rule type 2.<br>
# The logon membership process<br>
# Here the show form and process form functions are in separate files.<br>
# Need one rule to allow the show form function<br>
# The process form function file needs 2 rules, 1 for the file name & <br>
# 1 for the POST_PAYLOAD rule. <br>
<br>
SecFilterSelective REQUEST_URI "^/logon_showform.php$" allow<br>
<br>
SecFilterSelective REQUEST_URI "^/logon_processform.php$"
chain<br>
SecFilterSelective POST_PAYLOAD
\<br>
"^id=[0-9a-z]{15,}$ \<br>
&pw=[0-9a-z]{15,}$ \<br>
&submit=Submit$"
allow</p>
<br>
# This could also be coded this way<br>
SecFilterSelective REQUEST_URI "^/logon_processform.php$" chain<br>
SecFilterSelective POST_PAYLOAD
"^id=[0-9a-z]{15,}$&pw=[0-9a-z]{15,}$&submit=Submit$" allow<br>
<br>
<br>
# Rule type 2.<br>
# The sign up membership process<br>
# This single script contains both the show form and process form functions.<br>
# Need one rule to allow the show form function<br>
# and second rule chained to the POST_PAYLOAD rule for<br>
# the process form function. <br>
<br>
SecFilterSelective REQUEST_URI "^/signup.php$" allow<br>
<br>
SecFilterSelective REQUEST_URI "^/signup.php$" chain<br>
SecFilterSelective POST_PAYLOAD
\<br>
"^id=[0-9a-z]{15,}$
\<br>
&pw=[0-9a-z]{15,}$
\<br>
&pw2=[0-9a-z]{15,}$
\<br>
&email=[0-9a-zA-Z\.-_]{45,}$ \<br>
firstname=[a-zA-Z]{30,}$
\<br>
&lastname=[a-zA-Z]{30,}$
\<br>
&add1=[a-zA-Z -]{30,}$
\<br>
&add2=[a-zA-Z -]{30,}$
\<br>
&city=[a-zA-Z -]{20,}$
\<br>
&state=[a-zA-Z -]{20,}$
\<br>
&zip=[0-9-]{15,}$
\<br>
&phone_home=[0-9-]{15,}$
\<br>
&phone_office=[0-9-]{15,}$
\<br>
&phone_cell=[0-9-]{15,}$
\<br>
mothers_maiden_name=[a-zA-Z]{30,}$
\<br>
&userdigit=[0-9a-z]{5,}$
\<br>
&submit=Submit$" allow<br>
<br>
<br>
# Rule type 1. & Rule type 4.<br>
# After user logs in php session control is started so now cookies are passed
around<br>
# The membership menu process<br>
SecFilterSelective REQUEST_URI "^/menu.php$" chain<br>
SecFilterSelective COOKIE_PHPSESSID "^[0-9a-fA-F]{32}$" allow<br>
SecFilterSelective REQUEST_URI "^/terminate_member.php$" chain<br>
SecFilterSelective COOKIE_PHPSESSID "^[0-9a-fA-F]{32}$" allow<br>
SecFilterSelective REQUEST_URI "^/std_exit.php$" chain<br>
SecFilterSelective COOKIE_PHPSESSID "^[0-9a-fA-F]{32}$" allow<br>
<br>
<br>
# Rule type 3.<br>
# Handles this kind of request string<br>
# /mls_verifyemail.php?hash=content<br>
SecFilterSelective REQUEST_URI "^/verifyemail.php" chain<br>
SecFilterSelective ARG_hash "^[0-9a-zA-Z=]+$" allow<br>
<br>
# The catch-all deny rule to block all requests except <br>
# those above with allow option. <br>
SecFilter "."<br>
</p>
<DIV class=section lang=en>
<DIV class=titlepage>
<DIV>
<DIV>
<H3 class=title><A name=waf-rcn></A>Rule codings notes</H3></DIV></DIV>
<DIV></DIV></DIV>
<DL>
Mod_security rules selection is coded using regexp notation. If your regexp is as bad as
mine then the following will be helpfull.<br>
1. The $ is an anchor. Appending a $ to the end of the file name or a regexp notation as in [0-9a-z]{15,}$<br>
means no arguments are allowed to follow. This denies all malice code insert attempts a location<br>
in the string arguments to insert their code into.<br>
2. [0-9a-fA-F]{32} means upper & lower case Alpha-Numeric characters are tested for and may <br>
occur multiple times in the 32 character field size.<br>
3. [0-9a-zA-Z\.-_]{45,} this also allows a period, a dash, and a underscore <br>
4. [a-zA-Z -]{30,} this also allows a blank, and a dash<br>
5. [0-9-]{15,} this allows all digits and a dash<br>
6. [0-9a-zA-Z] here the field size is unknown, means only accept 1 char in this list (0-9a-zA-Z)<br>
7. [0-9a-zA-Z]? means accept blank or 1 char in this list (0-9a-zA-Z) <br>
8. [0-9a-zA-Z]+ means accept 1 or more char(s) in this list (0-9a-zA-Z)<br>
9. [0-9a-zA-Z]* means accept 0 or more chars in this list (0-9a-zA-Z) meaning empty is ok.<br>
10. Long regexp notation can be continued to the next line using the \ char<br>
11. COOKIE_PHPSESSID "^[0-9a-fA-F]{32}$" protects the default php session cookie.<br>
12. The chain command can be though of like creating a compound IF statement.<br>
13. The use of the "allow" command completely changes the default logic of mod_security.<br>
Allow means if rule is true them let it pass. <br>
14. Use of the debug log function results in a kind of logic trace of the loop processing
of he coded rules.<br>
That will greatly increase your understanding of what is happening.<br>
15. I found it very helpful to view the Apache httpd-access.log after doing a complete test of the web<br>
application to determine what files were being exchanged with the remote browser.<br>
16. Use of the mod...@li... question list is well supported by experienced members.<br>
17. All search engine robots do not issue get requests the same way. So watch the httpd-access.log to see<br>
what that do and add rules to accommodate them if you want to be indexed by<br>
every search engine that finds your site.<br>
18. When you have your rules tested and ready for production you should monitor their effect by changing<br>
SecFilterDefaultAction deny,log,status:404 to<br>
SecFilterDefaultAction pass,log,status:404<br>
</p>
</DIV>
</dl>
</dl>
</dl>
</dl>
</dl>
</dl>
</dl>
</dl>
</dl>
</dl>
</dl>
</dl>
</dl>
</dl>
</dl>
</dl>
</dl>
</dl>
</dl>
</DIV>
</dl>
</BODY></HTML> |
|
From: Ivan R. <iva...@gm...> - 2006-04-15 09:37:57
|
On 4/14/06, joe barbish <joe...@ya...> wrote:
>
> I am interested in knowing if there is any other generic type rules I nee=
d
> to add to this web application rule set to make it more secure? Have I
> covered all the different request types?
>
> ############# Start of mandatory directives ###################
> # Turn the filtering engine on or off
> secfilterengine on
> # Normalize cookie support
> SecFilterNormalizeCookies On
> # Enable version 1 (RFC 2965) cookies
> SecFilterCookieFormat 1
Why did you decide to go with 1 here? I see you are using PHP and PHP
only supports version 0 cookies.
> # The logon membership process
> # This script contains both the show form and process form functions.
> # Need one rule to allow the show form function
> # and second rule chained to the POST_PAYLOAD rule for
> # the process form function.
> SecFilterSelective REQUEST_URI "^/logon.php$" allow
> SecFilterSelective REQUEST_URI "^/logon.php$" chain
You don't need (nor want) the first of the two lines above. The first
line will allow the transaction to proceed based only on the URI.
Invalid values for parameters would be allowed.
> SecFilterSelective COOKIE_PHPSESSID "^[0-9a-fA-F]{32}$" chain
> SecFilterSelective POST_PAYLOAD \
> "^id=3D[0-9a-z]{15,}$ \
> &pw=3D[0-9a-z]{15,}$ \
> &userdigit=3D[0-9a-z]{5,}$ \
> &submit=3DSubmit$"
I don't see the above working. You are using multiple lines but you
may not be realising the empty space at the beginning of every new
line is becoming part of the regular expression. You should use one
rule per variable you want checked.
> allow
>
> # The sign up membership process
> # This script contains show form and process form functions.
> # Need one rule to allow the show form function
> # and second rule chained to the POST_PAYLOAD rule for
> # the process form function.
> SecFilterSelective REQUEST_URI "^/signup.php$" allow
> SecFilterSelective REQUEST_URI "^/signup.php$"
> chain
> SecFilterSelective COOKIE_PHPSESSID "^[0-9a-fA-F]{32}$" chain
The above will not allow requests that do not have the cookie set.
> All feedback is welcome.
You should test your configuration using real-life examples. There's a
nice utility included in the ModSecurity distribution, run-test.pl,
which sends a raw request (contained in a file) to the web server.
What you need to do is gather a bunch of requests, some valid some
not, throw them against your web server and verify the reponse status
codes are as you want them to be. That's the only way to foolproof
your configuration.
--
Ivan Ristic, Technical Director
Thinking Stone, http://www.thinkingstone.com
ModSecurity: Open source Web Application Firewall
|
|
From: joe b. <joe...@ya...> - 2006-04-14 22:01:25
|
I am interested in knowing if there is any other generic type rules I need to add to this web application rule set to make it more secure? Have I covered all the different request types?
############# Start of mandatory directives ###################
# Turn the filtering engine on or off
secfilterengine on
# Normalize cookie support
SecFilterNormalizeCookies On
# Enable version 1 (RFC 2965) cookies
SecFilterCookieFormat 1
# Check that url encoding is valid
secfiltercheckurlencoding on
# Unicode encoding check
secfiltercheckunicodeencoding off
# Only allow bytes from this range
secfilterforcebyterange 1 255
# Should forms post payloads be inspected
secfilterscanpost on
# The default setting sends the most important messages
# (errors and warnings)to the Apache /var/log/httpd-error.log
# only if there is no debug or custom log specified.
SecFilterDefaultAction deny,log,status:404
############# End of mandatory directives ###################
# This is just for development to observe what happens.
# In production the following 2 rules should be commented out.
SecFilterDebugLog /var/log/modsec_debug_log
SecFilterDebugLevel 9
# Most heavly used scripts go first
SecFilterSelective REQUEST_URI "^/web_style_sheet.css$" allow
SecFilterSelective REQUEST_URI "^/button.php$" allow
# This services the frame home page
SecFilterSelective REQUEST_URI "^/index.htm$" allow
SecFilterSelective REQUEST_URI "^/Header.htm$" allow
SecFilterSelective REQUEST_URI "^/home_page.php$" allow
SecFilterSelective REQUEST_URI "^/products.htm$" allow
SecFilterSelective REQUEST_URI "^/powered_by_FreeBSD.gif$" allow
SecFilterSelective REQUEST_URI "^/powered_by_apache_bsd.gif$" allow
# The logon membership process
# This script contains both the show form and process form functions.
# Need one rule to allow the show form function
# and second rule chained to the POST_PAYLOAD rule for
# the process form function.
SecFilterSelective REQUEST_URI "^/logon.php$" allow
SecFilterSelective REQUEST_URI "^/logon.php$" chain
SecFilterSelective COOKIE_PHPSESSID "^[0-9a-fA-F]{32}$" chain
SecFilterSelective POST_PAYLOAD \
"^id=[0-9a-z]{15,}$ \
&pw=[0-9a-z]{15,}$ \
&userdigit=[0-9a-z]{5,}$ \
&submit=Submit$" allow
# The sign up membership process
# This script contains show form and process form functions.
# Need one rule to allow the show form function
# and second rule chained to the POST_PAYLOAD rule for
# the process form function.
SecFilterSelective REQUEST_URI "^/signup.php$" allow
SecFilterSelective REQUEST_URI "^/signup.php$" chain
SecFilterSelective COOKIE_PHPSESSID "^[0-9a-fA-F]{32}$" chain
SecFilterSelective POST_PAYLOAD \
"^id=[0-9a-z]{15,}$ \
&pw=[0-9a-z]{15,}$ \
&pw2=[0-9a-z]{15,}$ \
&email=[0-9a-zA-Z\.-_]{45,}$ \
firstname=[a-zA-Z]{30,}$ \
&lastname=[a-zA-Z]{30,}$ \
&add1=[a-zA-Z -]{30,}$ \
&add2=[a-zA-Z -]{30,}$ \
&city=[a-zA-Z -]{20,}$ \
&state=[a-zA-Z -]{20,}$ \
&zip=[0-9-]{15,}$ \
&phone_home=[0-9-]{15,}$ \
&phone_office=[0-9-]{15,}$ \
&phone_cell=[0-9-]{15,}$ \
mothers_maiden_name=[a-zA-Z]{30,}$ \
&userdigit=[0-9a-z]{5,}$ \
&submit=Submit$" allow
SecFilterSelective REQUEST_URI "^/Read_setup_verify_email.php$" chain
SecFilterSelective COOKIE_PHPSESSID "^[0-9a-fA-F]{32}$" allow
# Handles this kind of request string
# /mls_verifyemail.php?hash=$hash
SecFilterSelective REQUEST_URI "^/mls_verifyemail.php" chain
SecFilterSelective ARG_hash "^[0-9a-zA-Z=]+$" allow
# A catch-all deny rule to block all requests except
# those above with allow option.
SecFilter "."
All feedback is welcome.
---------------------------------
Love cheap thrills? Enjoy PC-to-Phone calls to 30+ countries for just 2¢/min with Yahoo! Messenger with Voice. |
|
From: Ivan R. <iva...@gm...> - 2006-04-13 19:23:22
|
On 4/13/06, joe barbish <joe...@ya...> wrote: > > In the debug log I see this. > sec_check_access [path=3D(null)] > > Is this some default internal rule that gets executed? > I there some form of this rule I can code my self to set the real path? You should ignore that line. It just means transaction processing has entered a certain phase. > I have been using the apache httpd-access.log to see the raw request data= . > Is there some other method you would recommend? It depends on what you want/need. The ModSecurity audit log contains much more information. > Is there some place I can find the maping of words like REQUEST_URI to th= eir > location in the httpd_access.log logged records? In the Apache documentation: http://httpd.apache.org/docs/2.2/mod/mod_log_config.html > I am interested in using SecChrootDir /chroot/apache > But the manual is not clear on setting it up. So we've heard several times already :) > Is this how I should code the rule? > > SecChrootDir /usr/local/www/data You could. But in that case you'll have to change the directory root from "/usr/local/www/data" to "/" (because that's how Apache will see it in jail). BTW, you can only use the internal chroot feature if you don't intend to run CGIs, send email from your scripts, etc. You won't be able to restart Apache either (you'll have to "stop-start" it). You'll find all this explained in the free chapter of my book: http://www.apachesecurity.net/download/apachesecurity-ch02.pdf > And change the path of httpd-error.log & httpd-access.log from /var/log t= o > /usr/local/www/data/ in the httpd.conf? Logs can stay as they are. > Since the logs will be in the jail how do I access the logs from outside = the jail > with out turning off mod_security? The logs do not need to go in the jail. But even if they do you can access the inside of the jail from the outside no problem. -- Ivan Ristic, Technical Director Thinking Stone, http://www.thinkingstone.com ModSecurity: Open source Web Application Firewall |
|
From: joe b. <joe...@ya...> - 2006-04-13 18:23:03
|
I am interested in using SecChrootDir /chroot/apache But the manual is not clear on setting it up. My web application lives here /usr/local/www/data and that is what is in httpd.conf I am running apache13. Is this how I should code the rule? SecChrootDir /usr/local/www/data And change the path of httpd-error.log & httpd-access.log from /var/log to /usr/local/www/data/ in the httpd.conf? Since the logs will be in the jail how do I access the logs from outside the jail with out turning off mod_security? --------------------------------- How low will we go? Check out Yahoo! Messengers low PC-to-Phone call rates. |
|
From: joe b. <joe...@ya...> - 2006-04-13 18:19:19
|
I have been using the apache httpd-access.log to see the raw request data. Is there some other method you would recommend? Is there some place I can find the maping of words like REQUEST_URI to their location in the httpd_access.log logged records? --------------------------------- Talk is cheap. Use Yahoo! Messenger to make PC-to-Phone calls. Great rates starting at 1¢/min. |
|
From: joe b. <joe...@ya...> - 2006-04-13 18:07:23
|
In the debug log I see this. sec_check_access [path=(null)] Is this some default internal rule that gets executed? I there some form of this rule I can code my self to set the real path? --------------------------------- Yahoo! Messenger with Voice. PC-to-Phone calls for ridiculously low rates. |
|
From: <li...@32...> - 2006-04-13 15:40:49
|
What would be the best rule to use for this type of encoded spam injection?
M(Name): 石橋　圭太
=20
=E2=82=AC=C3=BC=C3=A1=C3=AB(Your email): kei...@ho...
=20
=C3=88=C3=94=C3=83=C2=AF(Subject)=1A
先生おひさしぶりで=
2
377;。
=20
=C3=A1=C2=BB=C2=B8(Message):
ご無沙汰しておりま=
2
377;。石橋　圭太です。=
;
覚えていただいてい=
2
414;すでしょうか？
ネット上で先生の学=
6
657;のホームページを
見つけたのでメール=
2
434;おくらさせていただ=
;
きます。
帰国後の私の状態は=
2
392;いいますと
大学卒業と同時にド=
2
452;ツに単身渡りました=
;
。
ドイツを拠点にヨー=
2
525;ッパとアフリカ大陸=
;
などを放浪していま=
2
375;た。むこうで嫁さん=
;
（日本人です）を見=
2
388;け帰国して今はネッ=
;
トプロバイダーの会=
1
038;で働いています。
同級生にはほとんど=
0
250;うことも無くなりま=
;
したが、逢うことが=
2
354;りましたらこのサイ=
;
トのことを伝えてお=
2
356;ます。
それではいつまでも=
2
362;元気でいてください=
;
。
=20
|
|
From: Alex V. <ale...@ss...> - 2006-04-13 14:58:53
|
On Jeu 13 avril 2006 16:35, joe barbish a =E9crit :
> Thanks Alex
>
> I didn't use this for the hash because this allows an empty field
>
> "^[0-9a-zA-Z]*"
>
> instead I used "^[0-9a-zA-Z=3D]+$" so the field can not be blank and =
the $
> so nothing can exist beyond it.
Ok, you didn't say if you wanted to allow blank field or not...
>
> For the cookie I would think it needs $ for same reason
> "^[0-9a-fA-F]{32}$"
>
> Am I correct in this line of thinking?
Yes you are
> Is 32 the standard normal default size of php session cookies?
Yes (and AFAIK it's a normal default size for all MD5 (like g=E9n=E9rated=
by
md5sum, SQL MD5() function, ...)
CU
Alex
|
|
From: joe b. <joe...@ya...> - 2006-04-13 14:35:44
|
Thanks Alex
I didn't use this for the hash because this allows an empty field
"^[0-9a-zA-Z]*"
instead I used "^[0-9a-zA-Z=]+$" so the field can not be blank and the $ so nothing can exist beyond it.
For the cookie I would think it needs $ for same reason
"^[0-9a-fA-F]{32}$"
Am I correct in this line of thinking?
Is 32 the standard normal default size of php session cookies?
"Alex V." <ale...@ss...> wrote:
Hi
in the documentation, you can read this :
COOKIE_name - search cookie with name name
So, just write a rule allowing this cookie if value length is 32B and only
hexa chars :
if (as I suppose) it's for the same apps as before :
SecFilterSelective REQUEST_URI "^/mls_verifyemail.php" chain
SecFilterSelective ARGS_hash "^[0-9a-zA-Z]*" chain
SecFilterSelective COOKIE_PHPSESSID "^[0-9a-fA-F]{32}" allow
else :
SecFilterSelective COOKIE_PHPSESSID "!^[0-9a-fA-F]{32}" deny
Alex
On Jeu 13 avril 2006 4:10, joe barbish a écrit :
> Hello list
> In my debug log I see this.
> I know this is being created by my php session control.
> This seems to pass right through my mod_security rules untouched.
>
> Raw cookie header "PHPSESSID=57afe9ec2e03d155efde2b7d53171a7e"
> Adding cookie "PHPSESSID"="57afe9ec2e03d155efde2b7d53171a7e"
>
> I want to have rules to check cookie name and that the argument
> PHPSESSID is there and that the content is (which looks like md5) valid
with nothing inserted.
> I do not have enough knowledge to even begin writing a rule or even to
> begin formulating how to ask intelligent question about processing cookies.
>
> I need your help please.
>
>
> ---------------------------------
> How low will we go? Check out Yahoo! Messengers low PC-to-Phone call
rates.
-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid0944&bid$1720&dat1642
_______________________________________________
mod-security-users mailing list
mod...@li...
https://lists.sourceforge.net/lists/listinfo/mod-security-users
---------------------------------
How low will we go? Check out Yahoo! Messengers low PC-to-Phone call rates. |
|
From: Alex V. <ale...@ss...> - 2006-04-13 14:12:37
|
Hi
in the documentation, you can read this :
COOKIE_name - search cookie with name name
So, just write a rule allowing this cookie if value length is 32B and onl=
y
hexa chars :
if (as I suppose) it's for the same apps as before :
SecFilterSelective REQUEST_URI "^/mls_verifyemail.php" chain
SecFilterSelective ARGS_hash "^[0-9a-zA-Z]*" chain
SecFilterSelective COOKIE_PHPSESSID "^[0-9a-fA-F]{32}" allow
else :
SecFilterSelective COOKIE_PHPSESSID "!^[0-9a-fA-F]{32}" deny
Alex
On Jeu 13 avril 2006 4:10, joe barbish a =E9crit :
> Hello list
> In my debug log I see this.
> I know this is being created by my php session control.
> This seems to pass right through my mod_security rules untouched.
>
> Raw cookie header "PHPSESSID=3D57afe9ec2e03d155efde2b7d53171a7e"
> Adding cookie "PHPSESSID"=3D"57afe9ec2e03d155efde2b7d53171a7e"
>
> I want to have rules to check cookie name and that the argument
> PHPSESSID is there and that the content is (which looks like md5) valid
with nothing inserted.
> I do not have enough knowledge to even begin writing a rule or even =
to
> begin formulating how to ask intelligent question about processing cook=
ies.
>
> I need your help please.
>
>
> ---------------------------------
> How low will we go? Check out Yahoo! Messenger=92s low PC-to-Phone cal=
l
rates.
|
|
From: Alex V. <ale...@ss...> - 2006-04-13 13:41:35
|
On Jeu 13 avril 2006 15:23, joe barbish a =E9crit : > Thank you Alex for the explanation; > > But then why did the =3D sign pass in the hash value if the rule is s= aying > only allow multiple 0-9 a-z A-Z characters? Sorry, I just forgot to had a $ at the end, so yet it was allowing everything that begin with 0-9 a-z A-Z... So the correct rule is : "^[0-9a-zA-Z]*$" if you don't want the "=3D" or "^[0-9a-zA-Z]*=3D$" if the "=3D" is always the last char or "^[0-9a-zA-Z=3D]*$" if you want to allow the =3D sign everywhere |
|
From: joe b. <joe...@ya...> - 2006-04-13 13:23:39
|
Thank you Alex for the explanation; But then why did the = sign pass in the hash value if the rule is saying only allow multiple 0-9 a-z A-Z characters? "Alex V." <ale...@ss...> wrote: On Jeu 13 avril 2006 14:31, joe barbish a écrit : > Thanks Alex > That worked as shown by these debug log messages > > Checking signature "^/mls_verifyemail.php" at REQUEST_URI > Checking against "/mls_verifyemail.php?hash=YmFyYmlzaDI=" > Signature check returned 403 > Chained rule with match, continue in the loop > Checking signature "^[0-9a-zA-Z]*" at ARG(hash) > Checking against "YmFyYmlzaDI=" > Signature check returned -1 > Access allowed based on pattern match "^[0-9a-zA-Z]*" at CUSTOM > Allow request to pass through > > But I am concerned by the asterisk at the end of "^[0-9a-zA-Z]*" > Is that a wildcard meaning anything else is accepted like the = in the > hash value? > > The hash value is created using this > $hash = base64_encode($logonid); > > Does base64_encode create any other special characters? > > Wouldn't "^[0-9a-zA-Z=]" be more secure? > No... It's not a security case, but it mean (as for all regexp), that you can have only [0-9a-zA-Z] chars, but more than one !! Here are examples : ^[0-9a-zA-Z] -> accept 1 char in this list (0-9a-zA-Z) ^[0-9a-zA-Z]? -> accept blank or 1 char in this list (0-9a-zA-Z) ^[0-9a-zA-Z]+ -> accept 1 or more char(s) in this list (0-9a-zA-Z) ^[0-9a-zA-Z]* -> accept 0 or more chars in this list (0-9a-zA-Z) ------------------------------------------------------- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnk&kid0944&bid$1720&dat1642 _______________________________________________ mod-security-users mailing list mod...@li... https://lists.sourceforge.net/lists/listinfo/mod-security-users --------------------------------- Love cheap thrills? Enjoy PC-to-Phone calls to 30+ countries for just 2¢/min with Yahoo! Messenger with Voice. |
|
From: Alex V. <ale...@ss...> - 2006-04-13 13:02:26
|
On Jeu 13 avril 2006 14:31, joe barbish a =E9crit : > Thanks Alex > That worked as shown by these debug log messages > > Checking signature "^/mls_verifyemail.php" at REQUEST_URI > Checking against "/mls_verifyemail.php?hash=3DYmFyYmlzaDI=3D" > Signature check returned 403 > Chained rule with match, continue in the loop > Checking signature "^[0-9a-zA-Z]*" at ARG(hash) > Checking against "YmFyYmlzaDI=3D" > Signature check returned -1 > Access allowed based on pattern match "^[0-9a-zA-Z]*" at CUSTOM > Allow request to pass through > > But I am concerned by the asterisk at the end of "^[0-9a-zA-Z]*" > Is that a wildcard meaning anything else is accepted like the =3D in = the > hash value? > > The hash value is created using this > $hash =3D base64_encode($logonid); > > Does base64_encode create any other special characters? > > Wouldn't "^[0-9a-zA-Z=3D]" be more secure? > No... It's not a security case, but it mean (as for all regexp), that you can have only [0-9a-zA-Z] chars, but more than one !! Here are examples : ^[0-9a-zA-Z] -> accept 1 char in this list (0-9a-zA-Z) ^[0-9a-zA-Z]? -> accept blank or 1 char in this list (0-9a-zA-Z) ^[0-9a-zA-Z]+ -> accept 1 or more char(s) in this list (0-9a-zA-Z) ^[0-9a-zA-Z]* -> accept 0 or more chars in this list (0-9a-zA-Z) |
|
From: joe b. <joe...@ya...> - 2006-04-13 12:31:57
|
Thanks Alex That worked as shown by these debug log messages Checking signature "^/mls_verifyemail.php" at REQUEST_URI Checking against "/mls_verifyemail.php?hash=YmFyYmlzaDI=" Signature check returned 403 Chained rule with match, continue in the loop Checking signature "^[0-9a-zA-Z]*" at ARG(hash) Checking against "YmFyYmlzaDI=" Signature check returned -1 Access allowed based on pattern match "^[0-9a-zA-Z]*" at CUSTOM Allow request to pass through But I am concerned by the asterisk at the end of "^[0-9a-zA-Z]*" Is that a wildcard meaning anything else is accepted like the = in the hash value? The hash value is created using this $hash = base64_encode($logonid); Does base64_encode create any other special characters? Wouldn't "^[0-9a-zA-Z=]" be more secure? "Alex V." <ale...@ss...> wrote: Sorry, I think this should work : SecFilterSelective REQUEST_URI "^/mls_verifyemail.php" chain SecFilterSelective ARG_hash "^[0-9a-zA-Z]*" allow (ARG_hash ans not ARGS_hash) Alex On Jeu 13 avril 2006 3:56, joe barbish a écrit : > Hello list; > In my debug log I see this: > > Normalised REQUEST_URI: /mls_verifyemail.php?hash=bGF5YmFja2ppbW15 > Parsing arguments... > Adding parameter: [hash][bGF5YmFja2ppbW15] > Checking signature "^/mls_verifyemail.php" at REQUEST_URI > Checking against "/mls_verifyemail.php?hash=bGF5YmFja2ppbW15" > Signature check returned -1 > Access allowed based on pattern match "^/mls_verifyemail.php" at REQUEST_URI > > This is the rule which allows the above to pass > SecFilterSelective REQUEST_URI "^/mls_verifyemail.php" allow > > I want to tighten this up by checking that there is only a single > parameter value and that its a md5 hash with no bogus stuff inserted > SecFilterSelective REQUEST_URI "^/mls_verifyemail.php" chain SecFilterSelective QUERY_STRING "^?hash=" chain > SecFilterSelective ARGS_VALUES "^hash=[0-9a-zA-Z]" allow > > This errors out. What am I doing wrong? > > > --------------------------------- > New Yahoo! Messenger with Voice. Call regular phones from your PC and save big. ------------------------------------------------------- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnk&kid0944&bid$1720&dat1642 _______________________________________________ mod-security-users mailing list mod...@li... https://lists.sourceforge.net/lists/listinfo/mod-security-users --------------------------------- Yahoo! Messenger with Voice. PC-to-Phone calls for ridiculously low rates. |
139 messages has been excluded from this view by a project administrator.
