You are viewing a plain text version of this content. The canonical link for it is here.
Posted to bugs@httpd.apache.org by bu...@apache.org on 2013/07/29 10:08:29 UTC
[Bug 55323] New: Double unescaped uri in sub request handler
https://issues.apache.org/bugzilla/show_bug.cgi?id=55323
Bug ID: 55323
Summary: Double unescaped uri in sub request handler
Product: Apache httpd-2
Version: 2.2.20
Hardware: PC
OS: All
Status: NEW
Severity: normal
Priority: P2
Component: Core
Assignee: bugs@httpd.apache.org
Reporter: simon.klinkert@gmail.com
Created attachment 30643
--> https://issues.apache.org/bugzilla/attachment.cgi?id=30643&action=edit
re-escaping patch for ap_sub_req_method_uri
I'm observing a httpd/mod_webdav problem. When I try to upload or download a
file and the file name contains the special character '%' (for example
'file%#12file'), then I get 400 and 403 errors every time.
After some debugging with dtrace and gdb, I assume the httpd unescapes the uri
in ap_process_request_internal() more than once.
Take a look at this stack trace:
httpd`ap_unescape_url
httpd`ap_process_request_internal+0x107
httpd`ap_sub_req_method_uri+0xdd
httpd`ap_sub_req_lookup_uri+0x27
mod_rewrite.so`lookup_variable+0x984
mod_rewrite.so`do_expand+0xd2e
splitout_queryargs
mod_rewrite.so`apply_rewrite_list+0x354
mod_rewrite.so`hook_uri2file+0x4f1
httpd`ap_run_translate_name+0x2e
httpd`ap_process_request_internal+0x2f5
httpd`ap_process_request+0x165
httpd`ap_process_http_connection+0x123
httpd`ap_run_process_connection+0x2e
httpd`child_main+0x493
httpd`make_child+0x115
httpd`startup_children+0x3d
httpd`ap_mpm_run+0x90a
httpd`main+0x9af
httpd`_start+0x83
There are two calls of ap_process_request_internal() and thus two uri unescapes
(ap_unescape_url()).
I'm not really familiar with the httpd code, but I guess a possible fix could
re-escape the already unescaped uri in ap_sub_req_method_uri() before calling
the internal request handler.
A little patch seems to be working for me. WebDav uploads and downloads for the
file 'file%#12file' are now possible. I tested the version 2.2.20 but the 2.5
code looks broken as well.
--
You are receiving this mail because:
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: bugs-unsubscribe@httpd.apache.org
For additional commands, e-mail: bugs-help@httpd.apache.org
[Bug 55323] Double unescaped uri in sub request handler
Posted by bu...@apache.org.
https://issues.apache.org/bugzilla/show_bug.cgi?id=55323
--- Comment #1 from Eric Covener <co...@gmail.com> ---
That looks too general, your symptom is that you pass file%#12file into a
rewriterule (-U check?) and it needs to be encoded at that point, but the patch
would re-escape anyone who sent in a properly escaped URL.
--
You are receiving this mail because:
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: bugs-unsubscribe@httpd.apache.org
For additional commands, e-mail: bugs-help@httpd.apache.org
[Bug 55323] Double unescaped uri in sub request handler
Posted by bu...@apache.org.
https://issues.apache.org/bugzilla/show_bug.cgi?id=55323
--- Comment #3 from Eric Covener <co...@gmail.com> ---
(In reply to Simon Klinkert from comment #2)
> (In reply to Eric Covener from comment #1)
> > That looks too general, your symptom is that you pass file%#12file into a
> > rewriterule (-U check?) and it needs to be encoded at that point, but the
> > patch would re-escape anyone who sent in a properly escaped URL.
>
> First of all, thanks for your feedback!
>
> How do I encode the uri at "that point"?
>
> There is no -U involved. My rewrite rule looks like this:
>
> RewriteRule ^(/.*)? %{LA-U:ENV:storage_path}$1 [L]
$1 has captured a URL-escaped string. I think you can re-escabe it with the [B]
flag, or pull the unescaped version out of %{THE_REQUEST} in a rewritecond.
> In addition, I do not really see why this should be too general. The
> function ap_sub_req_method_uri does already a re-escaping if new_uri does
> not start with '/'. Why is that bad for the other case?
Sorry, did not look to closely and not too familiar with it. Was just concerned
generally about the scope of the change.
--
You are receiving this mail because:
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: bugs-unsubscribe@httpd.apache.org
For additional commands, e-mail: bugs-help@httpd.apache.org
[Bug 55323] Double unescaped uri in sub request handler
Posted by bu...@apache.org.
https://issues.apache.org/bugzilla/show_bug.cgi?id=55323
--- Comment #4 from Eric Covener <co...@gmail.com> ---
> $1 has captured a URL-escaped string. I think you can re-escabe it with the
> [B] flag, or pull the unescaped version out of %{THE_REQUEST} in a
> rewritecond.
Duh, I mean: $1 has captured an un-escaped
--
You are receiving this mail because:
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: bugs-unsubscribe@httpd.apache.org
For additional commands, e-mail: bugs-help@httpd.apache.org
[Bug 55323] Double unescaped uri in sub request handler
Posted by bu...@apache.org.
https://issues.apache.org/bugzilla/show_bug.cgi?id=55323
--- Comment #5 from Simon Klinkert <si...@gmail.com> ---
(In reply to Eric Covener from comment #4)
> > $1 has captured a URL-escaped string. I think you can re-escabe it with the
> > [B] flag, or pull the unescaped version out of %{THE_REQUEST} in a
> > rewritecond.
>
> Duh, I mean: $1 has captured an un-escaped
The [B] flag didn't work for me (it has no effect), but I've no idea why. I
will give it some further investigation later on.
%{THE_REQUEST} might work, but that's rather a workaround than a real fix.
--
You are receiving this mail because:
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: bugs-unsubscribe@httpd.apache.org
For additional commands, e-mail: bugs-help@httpd.apache.org
[Bug 55323] Double unescaped uri in sub request handler
Posted by bu...@apache.org.
https://issues.apache.org/bugzilla/show_bug.cgi?id=55323
--- Comment #2 from Simon Klinkert <si...@gmail.com> ---
(In reply to Eric Covener from comment #1)
> That looks too general, your symptom is that you pass file%#12file into a
> rewriterule (-U check?) and it needs to be encoded at that point, but the
> patch would re-escape anyone who sent in a properly escaped URL.
First of all, thanks for your feedback!
How do I encode the uri at "that point"?
There is no -U involved. My rewrite rule looks like this:
RewriteRule ^(/.*)? %{LA-U:ENV:storage_path}$1 [L]
In addition, I do not really see why this should be too general. The function
ap_sub_req_method_uri does already a re-escaping if new_uri does not start with
'/'. Why is that bad for the other case?
--
You are receiving this mail because:
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: bugs-unsubscribe@httpd.apache.org
For additional commands, e-mail: bugs-help@httpd.apache.org
[Bug 55323] Double unescaped uri in sub request handler
Posted by bu...@apache.org.
https://issues.apache.org/bugzilla/show_bug.cgi?id=55323
--- Comment #6 from Simon Klinkert <si...@gmail.com> ---
Ok, I think the [B] flag doesn't work because there is no way to reach the
backreference code path in function do_expand in my case. From the log files I
can see that the double unescaping happens while we do a variable lookup for
LA-U:ENV:storage_path. The variable lookup/subrequest is triggered by function
do_expand as well. Maybe it's easier to understand if you take a look at my
initially posted stack trace.
I think it's still ok to change the unescaping behavior in the sub request
handler.
--
You are receiving this mail because:
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: bugs-unsubscribe@httpd.apache.org
For additional commands, e-mail: bugs-help@httpd.apache.org