Before I answer, let me first ask a question: What's wrong withg my
suggestion? Or even better: use the encoding done with mod_proxy_ajp?
Original URI:
/myapp/%252e%252e/otherapp/danger
JkMount /myapp/*
Apache httpd will correctly decode the URI to
/myapp/%2e%2e/otherapp/danger
mod_jk does map it *correctly* to /myapp and forwards it to Tomcat.
It does not IMO, and that's what I'm talking.
Inside mod_jk we should decode
/myapp/%2e%2e/otherapp/danger to
/myapp/../otherapp/danger
No, If the original URI was /myapp/%252e%252e/otherapp/danger, then it
is not correct to end up with /otherapp/danger as a decoded URL. A
percent sign is a valid character in a ressource path. If one wants to
use it in ressource paths, one needs to encode it ('%25'), and it is not
allowed to decode '%25XX' again after decoding to '%XX' once.
So %252e -> %2e and that's it, no further decoding. It is not a '.',
because it is decoded already.
Why do you think, that
/myapp/%252e%252e/otherapp/danger
is equivalent to
/myapp/../otherapp/danger ?
Do a normalization of the uri that will end up as
/otherapp/danger before hitting map_uri_to_worker
If there is no JkMount for /otherapp/ it will be
denied, if it is, the rewritten uri /otherapp/danger
will be send instead /myapp/%2e%2e/otherapp/danger.
Of course we can simply send /myapp/%2e%2e/otherapp/danger
to tomcat if the match is OK for /otherapp/,
and let the tomcat do a normalization once again.
As I said, double decoding ("again") is not allowed and is the source of
all evil.
In that case we won't need to encode the normalized
uri inside mod_jk once more.
I'm sure we need to, because double encoding is not allowed, but Tomcat
unfortunately does a second decoding.
Some evidence:
0) RFC 2396, RFC 3986
=====================
http://www.ietf.org/rfc/rfc2396.txt
Section 2.4.2. When to Escape and Unescape:
"Implementers should be careful not to
escape or unescape the same string more than once, since unescaping
an already unescaped string might lead to misinterpreting a percent
data character as another escaped character, or vice versa in the
case of escaping an already escaped string."
and even stricter the younger
http://tools.ietf.org/html/rfc3986
2.4. When to Encode or Decode
"Implementations must not
percent-encode or decode the same string more than once, as decoding
an already decoded string might lead to misinterpreting a percent
data octet as the beginning of a percent-encoding, or vice versa in
the case of percent-encoding an already percent-encoded string."
1) IIS Bug
==========
http://www.cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2001-0333
which leads to
http://www.microsoft.com/technet/security/Bulletin/MS01-026.mspx
"What's wrong with the decoding operation?
There's nothing wrong with the decoding operation per se. The
vulnerability results because, through an implementation flaw, the
decoding operation is performed a second time, after the security checks
on the request have been completed."
2) mod_security Bug
===================
http://www.modsecurity.org/download/CHANGES
"BUG Fixed a double URL-decoding bug (Apache first, then us), which
could sometimes lead to a false positive."
3) DAV Bugs
===========
http://dav.sourceforge.net/
"The following bugs should have gone:
* [ 1519718 ] davfs2 fails to properly decode complex escape sequences
* [ 1522903 ] chokes on directory names containing ' _ % characters
* [ 1539444 ] mounting of webdav drive fails
* [ 1539445 ] unable to access files in mounted webdav drive
* [ 1558525 ] davfs2-1.0.2_p20060820 mount fails
These bugs were related to ... and incorrect double url-decoding of urls."
Regards,
Rainer
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
