tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jean-Frederic <>
Subject Re: Improving mod_jk URI forwarding
Date Sat, 19 May 2007 16:50:53 GMT
On Sat, 2007-05-19 at 14:27 +0200, Rainer Jung wrote:
> Hi,
> now that we changed the default way how to forward URIs from mod_jk to 
> Tomcat (mod_jk 1.2.23) because of a directory traversal issue, I want to 
> propose a better long term solution.
> What's the problem?
> ===================

I think we still miss something... The mapping (map_uri_to_worker) uses
r->uri. Should we use s->req_uri or a carefully normalised uri to do the
mapping? Fixing s->req_uri doesn't help to fix the mapping (where the
problem comes from).



> - Access control is often defined in terms of URI prefixes, because they 
> are mapped to web applications
> - URIs can contain character sequences that change the URI prefix (like 
> "/../"
> - URIs can contain encoded characters
> The general rule to apply access control is to first decode encoded 
> characters, then normalize the path by resolving the special character 
> sequences and then apply access control.
> In a system with cascaded components we might check access control on a 
> frontend component but finally process the request on a backend 
> component. The backend component might not know about the frontend 
> component and thus again decode and normalize the request URI.
> Now it becomes important, that the result of this decode and normalize 
> on the backend does not differ from decode and normalize on the 
> frontend, which did the access control check. It is especially 
> important, that decoding is not done twice in a row, because then a 
> malicious user could use double encoded special character sequences.
> How do we handle it in mod_jk
> =============================
> By default, we now chose to forward the original undecoded and 
> unnormalized URL via mod_jk to Tomcat. Unfortunately this has serious 
> drawbacks, because all  internal Apache httpd processing is done on the 
> decoded normalized URL. One such example is mod_rewrite. Combinations of 
> mod_rewrite and mod_jk are typical for more complex sites. mod_rewrite 
> is only able to rewrite the decoded normalized URI, so any rewriting 
> gets obsolete if mod_jk forwards the original request URI.
> The other two existing options in mod_jk are forwarding the decoded 
> request (which results in the double encode issue) and forwarding an 
> encoded form of the decoded request.
> The last option sounds interesting, but has a massive drawback. It uses 
> Apache httpd encode function, which also encodes ';' as "%3B". But at 
> the moment the AJP connector on the Tomcat side looks for session IDs in 
> the request URI before decoding the URI. It only checks for 
> ";jsessionid=" and not for "%3bjsessionid=" or "%3Bjsessionid=".
> What do I propose
> =================
> My proposal is to use the encoded URI to forward to Tomcat. This should 
> be safe, because encoding before forwarding and afterwards decoding in 
> Tomcat should be the identity. To keep mod_jk compatible with the 
> existing AJP connector, I suggest to use a variant of ForwardURIEscaped, 
> where we escape all the characters we escape with ForwardURIEscaped, 
> except for the semicolon ';'. This should still be safe, because the 
> percent sign is the decoding indicator and we wil still encode '%' as 
> '%25' to prevent double decoding.
> Another option would be to only encode '%' when forwarding. For the same 
> reasons this should be save and will produce less overhead.
> I did a test implementation for the both approaches. Patches are under
> (for 1.2.23 and for trunk).
> The new options are "JkOption ForwardURIEscapedPartial" (do not escape 
> ';') and "JkOption ForwardURIEscapedMinimal" (only escape '%').
> I only tested the patch against trunk, but the 1.2.23 port I coded is 
> completely straightforward, so it should also work.
> Could you please think about the problem and test if you still find a 
> way to break the partial or minimal escaping solution? No directory 
> traversal should be possible and both should work well with mod_rewrite 
> and URL encoded session IDs. Maybe you can think of other ways breaking 
> the combination mod_jk/Tomcat, which are not related to double encoding.
> Since we have 1.2.23 out, there is no hurry. I would welcome comments on 
> the safety of this approach.
> Regards,
> Rainer
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message