Mladen Turk wrote:
Rainer Jung wrote:
OK Mladen, I understand that, but I think it's not correct.
Might be.
But: none of the existing options does the right thing. That's why I
suggested another way of handling the forward. I think my sugeggested
variant "forward r->uri with encoded '%'" is the right way of handling
it.
So, what is the actual problem. If there is something that is
potentially malicious we should deal with that without any specific
additional config.
Can you write a simple example of the uris that make the problem
and why we would need to encode the %.
How it is passed now, and how it would be passed with your
proposal.
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.
How does it forward it? That depends on the chosen forwarding option.
Old default: forwarding as /myapp/%2e%2e/otherapp/danger
Tomcat's AJP connector now does an automatic decoding of the request,
which ends up as /myapp/../otherapp/danger. Then Tomcat normalizes this
as /otherapp/danger and we serve content from a context we didn't want to.
The other options we have at the moment:
New default: forwarding the original request URI
"/myapp/%252e%252e/otherapp/danger". Tomcat does decoding to
"/myapp/%2e%2e/otherapp/danger" and there is no normalization possible.
So Tomcat checks for something called %2e%2e/otherapp/danger in the
context /myapp and will most likely find nothing, so throw an error.
3rd option (escaped forwarding): will forward
"/myapp/%252e%252e/otherapp/danger", so the same result as with our new
default (OK).
The problem is: the new default ignores rewrites done by mod_rewrite and
a lot of people use mod_rewrite together with mod_jk.
The third option, that also fixes the problem will break any normal
request with a jsessionid:
"/myapp/valid;jsessionid=12345" gets forwarded as
"/myapp/valid%3Bjsessionid=12345" and Tomcat's AJP connector does not
detect the jsessionid and Tomcat actually looks for a ressource
valid%3Bjsessionid=12345 in /myapp.
My proposal: forward the httpd internal URI with only encoded '%':
So we would forward "/myapp/%252e%252e/otherapp/danger" but keep
compatibility with mod_rewrite and with jsessionid.
Of course one could als improve the situation by changing the AJP
connector implementation on the Tomcat side and in the long run this
might be interesting, but I find my suggestion better, because:
- it will be compatible with existing Tomcat AJP connector
- it should solve al three problems (security, mod_rewrite, jsessionid)
- it is not heavy on performance, we only need to do something if the
request after httpd decoding still has a '%' in it.
What I would like very much, if anybody would think about URIs maybe
breaking this %' encoding construction. I personally think it's safe,
because encoding '%' in a decoded URI and afterwards decoding again
should behave as the identity on the URI. So Tomcat at the end should
work on the same URI, that we have used for our matching.
Regards,
Rainer
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
