Thanks.  The restored mod_jk behavior is the same as
Tomcat 3.3.x with <DecodeInterceptor ... safe="true"/>,
the default.  Unsafe escapes give 403's.  We can
add a similar option to mod_jk to turn off the checking.
Though, I can't image a situation where it would make
sense to accept the risks to gain access to these escapes.  


> -----Original Message-----
> From: Ignacio J. Ortega [mailto:[EMAIL PROTECTED]] 
> Sent: Wednesday, February 05, 2003 5:02 PM
> To: 'Tomcat Developers List'
> Subject: RE: cvs commit: 
> jakarta-tomcat-connectors/jk/native2/server/isapi jk_isapi_plugin.c
> Larry,
> > 
> > I wouldn't see it as a step forward where we increase
> > the vulnerability of the majority, and the effort needed
> > to deal with that, in favor of satisfying a small minority
> > that insist on using inherently unsafe escape sequences.
> > 
> > Maybe this new behavior should be an option like it is in
> > Tomcat 3.3.x.  The default is to err on the side of safety.
> > Operating in this less safe envrionment could be specifically
> > requested via an option, and the user is responsible for
> > dealing with the impact.  How does that sound?
> > 
> Ok, no problem, but there must be a middle ground.
> Perhaps the tests (jk_req_util.c/jk_requtil_unescapeUrl) now 
> overreact a
> bit, maybe we can tone down the code, just now it barfs on 
> any embedded
> '/' %2F, tomcat deals without problems with this issues, and 
> later there
> is an agressive uri filtering on ./ and combinations.. maybe is better
> to let this pass without problems to tc, and let tomcat deal with it..
> tested and it works very well..
> How about this way?
> In the mean time i'll revert the change.. 
> Saludos, 
> Ignacio J. Ortega 

To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to