A few issues with the request filter and a possible bug

[embed]

Hello, I'm trying out Litespeed web server and noticed a couple of strange things.

Some preliminary info:
- I am getting the same results with the standard and enterprise editions, v3.3.4. Running on Debian Etch i386.
- All the settings are entered through the web interface. No httpd.conf or .htaccess
- I have logging set on INFO
- The request filter has been activated for POST payload scanning too, logging is on at level 9, my default action is deny,log,status:403

Here are my issues:

1) Let's say I want to deny access when a POST request is made and the parameter foo contains the value bar.

To test if the rules are working I am sending a POST request with something like:
foo=ABCbarABC

I could only obtain the desired behaviour with a rule like this:
SecFilterSelective ARGS "foo=.*bar.*"

Is this the only way to achieve the desired result?

I tried to use something like:
SecFilterSelective ARG_foo "bar"
but it doesn't work.
Is it to be expected?

2) Strangely enough if I use some nonsense like this:

SecFilterSelective ARG_foo "bar"
SecFilterSelective HTTP_foo "bar"

or

SecFilterSelective ENV_foo "bar"
SecFilterSelective HTTP_foo "bar"

it works fine. And if I change the order, putting the HTTP_foo line at the top, it works no more.

May this be a bug?

3) When the request filter blocks access I can't see anything in the vhost or server error.log, what am I doing wrong? This issue happens also with "SecFilterSelective REQUEST_URI" rules. Setting status:404 doesn't help.

4) The POST_PAYLOAD location doesn't seem to be implemented, am I right?


Edit: 5) Moreover, no matter what I try I can't get the request filter to process cookies. If anybody has any suggestions that would really help, thanks.

I hope you can shed some light on the above issues, thanks!

-Mark

 

[mistwang]

Thank you for the detail bug report. I am checking it.
What kind of rule do you use for checking cookies?

If you think anything does not work as expected, just give an example rule and request for us to reproduce it.

 

[mistwang]

1) and 2) are related, and the bug has been identified and fixed.

 

[mistwang]

3) when a request was blocked, something like following should be in error.log

2008-02-19 14:55:46.901 [INFO] [127.0.0.1:53894-0#Example] [SECURITY] match [HTTP_foo] against pattern [bar], result: 1
2008-02-19 14:55:46.901 [NOTICE] [127.0.0.1:53894-0#Example] [SECURITY] Access Denied [PATTERN: 'bar']

 

[mistwang]

4) has been identified and fixed.

 

[embed]

Hello, thanks for your attention.
I typed this message before your replies, maybe it still can be useful.
If for the time 3.3.5 is out you could make the two directives:
SecFilterSelective ARG_foo "bar"
SecFilterSelective COOKIE_foo "bar"
work as they should that would be great, thanks.

1)

As for cookies the rule that should work is :

SecFilterSelective COOKIE_foo "bar"

This should match a cookie named foo that contains the string bar.
Using this with litespeed results in the following error, visible from the main page:

[config:vhost:myVhost:security:secfilter:filterRules] rewrite: unknown server variable while parsing: foo

I don't think that this error message should be related to such a rule, either.
In fact it's the same error message that you can get using this nonsense rule:

SecFilterSelective ENV_foo "bar"

If you want a sample request you can use this:

GET /test/ HTTP/1.1
User-Agent: Opera
Host: www.mydomain.com
Accept: text/html, application/xml;q=0.9, application/xhtml+xml, image/png, image/jpeg, image/gif, image/x-xbitmap, */*;q=0.1
Accept-Language: en-GB,en;q=0.9
Accept-Charset: iso-8859-1, utf-8, utf-16, *;q=0.1
If-Modified-Since: Tue, 19 Feb 2008 19:59:49 GMT
Cookie: foo=bar
Cookie2: $Version=1
Connection: keep-alive

2)

The other big issue that I have is the impossibility to easily check for POST parameters.

This rule:

SecFilterSelective ARG_foo "bar"

fails with a request like this:

POST /test2/ HTTP/1.1
User-Agent: Opera
Host: www.mydomain.com
Accept: text/html, application/xml;q=0.9, application/xhtml+xml, image/png, image/jpeg, image/gif, image/x-xbitmap, */*;q=0.1
Accept-Language: en-GB,en;q=0.9
Accept-Charset: iso-8859-1, utf-8, utf-16, *;q=0.1
Referer: http://www.mydomain.com/test1/
Cookie: foo=bar
Cookie2: $Version=1
TE: deflate, gzip, chunked, identity, trailers
Content-Length: 77
Content-Type: application/x-www-form-urlencoded
Connection: keep-alive
Posting 8 bytes...
foo=bar

I also tried to use something like:

SecFilterSelective POST_PAYLOAD "bar"

but it doesn't work.
The only way I managed to block unwanted POST parameters is using a rule like this:

SecFilterSelective ARG "bar"

However this approach isn't useful for two reasons:
a) When you have to check many POST parameters it's practically impossible to create decent rules.
b) The above directive scans also the query string, causing unwanted results.
That means that the above rule would also deny a request like:

GET /myscript.php?p=bar HTTP/1.1

I hope this will help you in identifying the issues.

Regards,
-Mark

 

[mistwang]

I typed this message before your replies, maybe it still can be useful.
If for the time 3.3.5 is out you could make the two directives:
SecFilterSelective ARG_foo "bar"
SecFilterSelective COOKIE_foo "bar"
work as they should that would be great, thanks.

Thanks! Updated 3.3.5 release package has been uploaded. everything should be working as expected. you can download and give it try. Just change the version number in the download link.

 

[embed]

Thanks for the quick turnaround, tomorrow I'll test the new release and update the thread.

Regards,
-Mark

 

[embed]

Hello, I tried the new version and found something strange. The last point mentioned below is stopping me from testing more.
Here's what I found:

1)
According to mod_security 1.9 docs the rule for checking POST parameters should be:

SecFilterSelective ARG_foo "bar"

but this rule isn't recognized by Litespeed. Instead, this one works:

SecFilterSelective ARGS_foo "bar"

Once you know it this is no big deal, so no problems here.

2)
Let's say that I have a form that triggers a POST request at this URL:

http://www.mydomain.com/form.php?parameter=anything

If I browse to the above URL without any request filter rules, then enable only this rule:

SecFilterSelective ARGS_foo "bar"

and then submit the form, everything works as it should.
The request with a POST parameter of foo with bar anywhere in the value is properly blocked.

This is what I expected, but here's what isn't working.

3)
If I try to go to:

http://www.mydomain.com/form.php?parameter=anything

while the following rule is enabled:
SecFilterSelective ARGS_foo "bar"

The page simply won't load, Opera sends five identical GET request then stops trying to retrieve the page and Firefox sends only one GET request.
I don't get any built-in error message from the browsers, only a blank page. My http logger doesn't show any http response from the server.

This strange behaviour disappears when I remove the mentioned rule.
I also tried with only this rule in the request filter and disabling the rewrite engine, still the problem persists and is obviously related to the filter rule.


Bottom line is that the rule I'm using works only if I browse to the form page, and then enable the request filter. This obviously isn't how things should work.

If your tests were working fine I suppose that this might be related to the fact that I'm using a request with a query string, still the two things shouldn't be related.

I hope this helps, let me know if I can be more useful.

Regards,
-Mark

 

[mistwang]

OK, the latest 3.3.5 package should have fixed those issues.

 

[embed]

Thanks, the ARG and COOKIE rules are now working.
I didn't have the time to run extensive tests but everything that was previously broken is now fixed, if I find something more later I'll let you know.

On a side note I noticed a little glitch with version 3.3.4, I don't know if it's fixed in 3.3.5 so I'll just write about it here.

If I set a custom 404 page for a vhost in the web interface and then choose an action like deny,log,status:404 in the request filter the rule will display the hardcoded 404 page and not the custom one.
However, if I use also an .htaccess file to define ErrorDocument, the custom 404 page shows properly.

You may want to fix this for a couple of reasons:
a) It will save some time to other people
b) Completely disabling .htaccess files should improve performance, even if only by a little margin. Currently I need them on just for this.

Thank you for your hard work!

-Mark

 

[mistwang]

We failed to reproduce the 404 page problem.
The server will send the hard coded 404 page when there is problem to serve the custom one.
You can turn on the detail debug logging by changing "Debug Level" to "HIGH".

 

[embed]

I'll look into the 404 issue, as it seems that it's a problem on my side.

BTW, I posted a couple of features request in the relative forum section.
I would love to know what you think about them, thanks!