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?
===================
- 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]
