httpd-modules-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Yann Ylavic <ylavic....@gmail.com>
Subject Re: Preventing Path Traversal Attack
Date Mon, 08 Dec 2014 15:30:03 GMT
Hi Justin,

On Mon, Dec 8, 2014 at 3:07 PM, Justin Kennedy
<jkennedy@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.

Mime
View raw message