tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rainer Jung <rainer.j...@kippdata.de>
Subject Re: RewriteRule rewrites, but mod_jk persists with old URI
Date Tue, 15 Jun 2010 18:25:15 GMT


On 15.06.2010 20:08, André Warnier wrote:
> Rainer Jung wrote:
>> On 15.06.2010 16:13, Tobias Crefeld wrote:
>>> Am Tue, 15 Jun 2010 15:04:01 +0200
>>> schrieb André Warnier<aw@ice-sa.com>:
>>>
>>>> In other words, it appears to receive the URI "/mir/search.jsp", try
>>>> to map it to a worker, succeed, but then forwarding the request to
>>>> Tomcat as "/jsp/search.jsp" anyway (which was the original URL, not
>>>> the rewritten one). This "/jsp/search.jsp" is indeed not found by
>>>> Tomcat (because in Tomcat it is "/mir/search.jsp"), and I receive in
>>>> return a 404 error page from Tomcat.
>>>
>>> I'm not quite sure whether I have understood your problem but maybe
>>> this additional setting (after JkMount) helps:
>>>
>>> JkOptions +ForwardURIProxy
>>
>> Right, the Forward* JkOptions are the key here. There have been
>> various attempts during the lifetime of mod_jk to try getting this
>> right, so there are various possible options. Finally because of
>> security problems, ForwardURIProxy was introduced in 1.2.24 and made
>> the new default.
>>
>> http://tomcat.apache.org/connectors-doc/reference/apache.html#Forwarding
>>
>> explains the options and also the limitations with respect to
>> mod_rewrite. There's also a short note at
>>
>> http://tomcat.apache.org/connectors-doc/generic_howto/proxy.html#URL%20Encoding
>>
>>
>> It is possible, that you have explicitely configure
>> ForwardURICompatUnparsed, i.e. please forward the original URI without
>> any interpretation, decoding etc. Since decoding cannot be undone,
>> this means any rewriting by mod_rewrite is not respected. This option
>> was only default at the exact version 1.2.23 but it existed as an
>> option in 1.2.18.
>>
> Hi.
> Thanks to both for your suggestions and explanations.
> The version of mod_jk on that system is 1.2.18, and
> I have not any of the JKOptions Forward* configured in my setup, which
> is just this :
>
> JkWorkersFile /etc/apache2/workers.properties
> JkLogFile /var/log/apache2/mod_jk.log
> JkLogLevel debug
> JkLogStampFormat "[%a %b %d %H:%M:%S %Y] "
>
> Anyway, adding
> JkOptions +ForwardURICompat
> works !
>
> (which is strange, because the docs says it should be the default before
> 1.2.22)
>
> Now I'll see if I can get a more recent mod_jk as a Debian package, and
> else I'll see if I can make one myself, so that I can use the latest
> default ForwardURIProxy.
>
> I also did not understand the reason why in the docs it says "This is ..
> not safe if you are using prefix JkMount."
> Anyone care to elaborate ?
>
> I am not using "prefix JkMount" specifically, but I am using
> <Location "/mir">
> SetHandler jakarta-servlet
> </Location>
> Does this un-safeness apply in that case also ?

The problem is, that ForwardURICompat forwards the URL as decoded by 
Apache, e.g. usual percent encoding gets resolved. Tomcat decodes again.

So lets construct a URL like

/publicapp/../privateapp/privatedata

and so some encoding:

/publicapp/%2E%2E/privateapp/privatedata

Now if Apache gets this URK, it first decodes it

/publicapp/../privateapp/privatedata

and then normalizes it,

/privateapp/privatedata

Likely you don't have a JkMount /privateapp or a SetHandler in a 
Location /privateapp. OK, works.


*Now*: Let's double encode:

/publicapp/%252E%252E/privateapp/privatedata

Apache will decode (once) to

/publicapp/%2E%2E/privateapp/privatedata

As a decoded URL. Now there's no ".." in it, so normalization doesn't 
change anything and the URL will match JkMount /publicapp/* or Location 
/publicapp.

Since ForwardURICompat is in use, mod_jk will forward this URL, so 
Tomcat gets the URL

/publicapp/%2E%2E/privateapp/privatedata

and decodes *again* resulting in

/publicapp/../privateapp/privatedata

normalizes to

/privateapp/privatedata

and serves your private data although you didn't map it in mod_jk.

So double decoding is desaster. That's why we now reencode every 
problematic character before forwarding to Tomcat.

So: depending on your Location URL the warning *does* apply.

Regards,

Rainer

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org


Mime
View raw message