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). Cheers Jean-Frederic > > - 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 > > http://people.apache.org/~rjung/mod_jk-dev/URIForwarding/ > > (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: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
