Hi Justin,
On Mon, Dec 8, 2014 at 3:07 PM, Justin Kennedy
<jkenn...@pingidentity.com> wrote:
> The variable "r" is the request_rec that is passed into the module's
> handler hook. Based on my testing, r->unparsed_uri does indeed have a space
> (it's not encoded to %20).
As I said in my previous message, this is not something acceptable in
the request-line, eg. :
GET /some/path with space HTTP/1.1
is not valid, precisely because each part of the request line is
separated with a space.
If such a request is received by httpd, either a "400 Bad Request" is
returned to the client (strict policy), or "with space HTTP/1.1" is
considered an invalid protocol and considered HTTP/1.0.
Given a request-line like
"GET<space>/URL_without_space<space>HTTP/1.1", httpd sets
r->unparsed_uri to /URL_without_space at the very beginning, and won't
change it by its own.
So what in your configuration (RewriteRule, third party module, or own
module) changes unparsed_uri to contain a space?
>
> I need to compare against an unparsed URI because r->uri is vulnerable to a
> path traversal attack. For instance, this:
> http://abc.me/unprotected_path/../protected_path
> becomes:
> http://abc.me/protected_path
I don't see how http://abc.me/unprotected_path/../protected_path is
more a path traversal than accessing http://abc.me/protected_path
directly.
Either /protected_path is accessible, or it isn't. Am I missing something?
Regards,
Yann.
