tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From André Warnier ...@ice-sa.com>
Subject Re: RewriteRule rewrites, but mod_jk persists with old URI
Date Tue, 15 Jun 2010 18:39:45 GMT
Rainer Jung wrote:
> 
> 
> 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
> 
Got it, thanks for your time.

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


Mime
View raw message