Bug 39746 - mod_rewrite & mod_proxy & %2F in URL
Summary: mod_rewrite & mod_proxy & %2F in URL
Status: RESOLVED DUPLICATE of bug 34602
Alias: None
Product: Apache httpd-2
Classification: Unclassified
Component: mod_proxy (show other bugs)
Version: 2.2.0
Hardware: Other Linux
: P2 normal with 6 votes (vote)
Target Milestone: ---
Assignee: Apache HTTPD Bugs Mailing List
URL:
Keywords:
: 41614 (view as bug list)
Depends on:
Blocks:
 
Reported: 2006-06-07 11:39 UTC by Markus Stockhausen
Modified: 2014-02-17 13:59 UTC (History)
2 users (show)



Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Markus Stockhausen 2006-06-07 11:39:04 UTC
Hello.

We used Apache 2.0.54 as a reverse proxy for an internet webmail access with the
following rewrite rule:

AllowEncodedSlashes On
RewriteEngine on
RewriteRule 
  /(.*)/MessagePart/(.*)/(.*)/(.*)-H.txt               
  http://127.0.0.1:8100/$1/MessagePart/$2\%2F$3/$4-H.txt [P]

It is essential for the mailserver to get the %2F character instead of an /.
Otherwise the request results in an "404 not found error". The ruleset worked
well until we upgraded to 2.0.58. Suddenly the rewrite produced another URL
string. What before was an %2F now results in an %252F. 

We could track down that problem to the following patch that came with version
2.0.55: http://svn.apache.org/viewvc?view=rev&revision=227435

Obviously the old (but for us correct) url translation worked in three steps:
step 1: mod_rewrite: .../... -> ...%2F...
step 2: mod_proxy: ...%2F... -> ...%252F...
step 3: mod_proxy: ...%252F... -> ...%2F...

With the patch step 3 is now obsolete and we have no possibility to encode an /
character into an %2F because mod_proxy will always replace any % charachter
with the %25 chars. 

Is this patch meant to be this way. If yes what other way will there be to
transform a single / in the calling URL to an proxied %2F.

Best regards.

Markus Stockhausen
Comment 1 Pieter Vanmeerbeek 2006-07-10 22:29:03 UTC
Hi,

I've seen similar behavior when upgrading from 2.0.53 to 2.2.2.
I'm using mod_rewrite, i.e. first apply the unescape map, followed by an 
escape map ( in other words reescape incorrect escaped urls).

Since the upgrade an % gets escaped to %25.
So I suppose a bug is introduced between 2.0.53 and 2.2.2.

kind regards,
Pieter

Comment 2 Alessandro Polverini 2007-09-07 01:58:40 UTC
We hit the same bug, is there any workaround?
Comment 3 William A. Rowe Jr. 2007-09-07 02:00:53 UTC
Does AllowEncodedSlashes solve your issues?
Comment 4 Alessandro Polverini 2007-09-07 03:09:42 UTC
No, because I've a problem with the encoding of the % character, using
mod_rewrite (not mod_proxy), but I'll try to better understand if I'm doing
something wrong
Comment 5 Markus Stockhausen 2007-09-07 10:22:19 UTC
Nice to see that there comes a little bit of movement into this issue. 

We tried several things to get araound this bug but AllowEncodedSlashes will 
not solve the problem. As I wrote in my first post the failure occurs in 
mod_proxy. The mod_rewrite rule works perfectly - it translates the / 
characters into a %2F. If mod_proxy forwards this request afterwards it must 
definitly preserve the input url. As far as I understood the behaviour of 
mod_proxy it translates a % char into a %25 because it does not know that the 
original sequence is a %2F that should never be separated. So at last we have a 
%252F. This was never a problem at all as long as we had the third step that 
fixed the sequence back to %2F. 

But the apache fix 227435 will always eleminate step 3 if we have a reverse 
proxy. I guess there was a wise intention to build this fix but exactly for our 
szenario it will not work at all. So my colleagues are alwas forced to turn 
back the patch whenever they need a new apache version.

Best regards.

Markus
Comment 6 Ruediger Pluem 2007-09-07 14:10:13 UTC
From my point of view reverting the patch would open a security hole similar to
CVE-2007-1860 (see http://tomcat.apache.org/security-jk.html and
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-1860). So it is needed
that  the proxy code encodes the URL again before passing it to the backend to
avoid unexpected double decodings.
Comment 7 Markus Stockhausen 2007-09-08 02:42:16 UTC
If you expect to get a security hole when reverting the patch then you have to 
redesign the encoding/decondig process of mod_proxy. When you define a double 
decoding as an error, I can only define an encoding from %2F to %252F as an 
error. So it will be better when you investigate the encoding behaviour of 
mod_proxy so that an apache switch (maybe AllowEncodedSlashes) will allow the 
module to read over %2F or just any special sequences. 

Another solution may be a mod_rewrite rule that will fill in escape characters 
before any char that you don't want mod_proxy to change. mod_proxy could 
afterwards eleminate the escape chars leaving the char behind untouched. 

Best regards.

Markus
Comment 8 Nick Kew 2007-09-08 04:37:10 UTC
I just tested: the patch in Comment #27 of PR#34602 fixes this problem.  I'm now
reviewing that patch, with a view to whether it's suitable for committing to
/trunk/ as a permanent fix.

Anyone else watching either of these bugs: you could help by trying the patch
yourselves and reporting back.

*** This bug has been marked as a duplicate of 34602 ***
Comment 9 Nick Kew 2007-09-08 17:57:08 UTC
*** Bug 41614 has been marked as a duplicate of this bug. ***