You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by fr...@friedo.com on 2003/09/09 09:00:18 UTC

[PATCH] Query string parsing for mod_include.c

Attached is a patch that impliments a new directive in mod_include.c,
#parseqs, which parses the name=value pairs on the query string and places
the results in the subprocess environment table, allowing you to do highly
neat things with SSI scripts. I found this feature to be quite useful.

Caveats:
1. A potential security problem is that a malicious person may be able to
use it to override important environment variables on a page where he
knows #parseqs is in use. We might want to disallow all-CAPS variables
from being modified in this fashion.

2. There is no support for query string variables with multiple values.


Please go easy on me. :) I haven't submitted anything to Apache before,
but I found this hack to be quite useful. I look forward to your comments.






Re: [PATCH] Query string parsing for mod_include.c

Posted by Brian Akins <ba...@web.turner.com>.
On Tue, 2003-09-09 at 03:00, friedo@friedo.com wrote:
> Attached is a patch that impliments a new directive in mod_include.c,
> #parseqs, 

Couldn't this be better implemented using
"APR_OPTIONAL_FN_TYPE(ap_register_include_handler)" type things in a
separate module.  This seems to be a much better way to extend SSI
without mucking with mod_include.  I have done some custom directives
doing this and it just seems "cleaner."

-- 
Brian Akins <ba...@web.turner.com>
CNN Internet Technologies


Re: [PATCH] Query string parsing for mod_include.c

Posted by fr...@friedo.com.
Hi, Andre. Thanks for your feedback. I will definately port this to the
2.1 branch and submit a new patch.

> - one should recognize ; as delimiter as well (ok, trivial)

Easy enough.

> - to circumvent the security flaw, I'd suggest to extend the #set
> handler
>   instead, for example:
>     <!--#set var="foo" query="param_name" -->, which would be really
> safe.
>   I'm not sure, whether the query parameter should be expanded.
> Opinions?

Another idea I thought of was to put the query string vars in a seperate
table, and have a special prefix for accessing that table, (something like
@var instead of $var.) That would prevent overwriting important stuff in
subprocess_env. I also like your idea, though it is a bit more cumbersome
for the person writing the SSI.

> - The second one could be solved with things like
>   <!#--set var="foo" query="param_name[i]" -->, where i starts with 0 or
> 1 (?).

It should start with zero of course. :P




Re: [PATCH] Query string parsing for mod_include.c

Posted by André Malo <nd...@perlig.de>.
friedo@friedo.com wrote:

>Attached is a patch that impliments a new directive in mod_include.c,
>#parseqs, which parses the name=value pairs on the query string and places
>the results in the subprocess environment table, allowing you to do highly
>neat things with SSI scripts. I found this feature to be quite useful.
>
>Caveats:
>1. A potential security problem is that a malicious person may be able to
>use it to override important environment variables on a page where he
>knows #parseqs is in use. We might want to disallow all-CAPS variables
>from being modified in this fashion.
>
>2. There is no support for query string variables with multiple values.
>
>
In general this is really a desired feature. Thanks!
There are some issues, anyway ;-)

- one should recognize ; as delimiter as well (ok, trivial)

- to circumvent the security flaw, I'd suggest to extend the #set handler
  instead, for example:
    <!--#set var="foo" query="param_name" -->, which would be really safe.
  I'm not sure, whether the query parameter should be expanded. Opinions?

- The second one could be solved with things like
  <!#--set var="foo" query="param_name[i]" -->, where i starts with 0 or 
1 (?).

- what about unescaping the values?

There's still another point. I'd add this to the 2.1 branch only, 
because (a) we're going forward *there*, (b) mod_include was redesigned 
to give a way better interface and (c) we should not play with our (not 
really, but ...) stable branch.

>Please go easy on me. :) I haven't submitted anything to Apache before,
>but I found this hack to be quite useful. I look forward to your comments.
>
Please attach patches as text/plain.

Thanks, nd