A few issues with the request filter and a possible bug

Discussion in 'Bug Reports' started by embed, Feb 19, 2008.

  1. embed

    embed New Member

    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
    Last edited: Feb 19, 2008
  2. mistwang

    mistwang LiteSpeed Staff

    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.
    Last edited: Feb 19, 2008
  3. mistwang

    mistwang LiteSpeed Staff

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

    mistwang LiteSpeed Staff

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


  5. mistwang

    mistwang LiteSpeed Staff

    4) has been identified and fixed.
  6. embed

    embed New Member

    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:

    Code:
    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:

    Code:
    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:
    Code:
    GET /myscript.php?p=bar HTTP/1.1
    I hope this will help you in identifying the issues.

    Regards,
    -Mark
  7. mistwang

    mistwang LiteSpeed Staff

    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.
  8. embed

    embed New Member

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

    Regards,
    -Mark
  9. embed

    embed New Member

    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
  10. mistwang

    mistwang LiteSpeed Staff

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

    embed New Member

    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
  12. mistwang

    mistwang LiteSpeed Staff

    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".
  13. embed

    embed New Member

    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!

Share This Page