I've haven't looked at the full source in a while, so I'm somewhat guessing at the exact impact. I'm working on a Tomcat 3.3.2 release plan which will need to integrate use of the J-T-C connectors. I should be able to take a more in depth look at this as part of that.
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? Cheers, Larry > -----Original Message----- > From: Ignacio J. Ortega [mailto:[EMAIL PROTECTED]] > Sent: Wednesday, February 05, 2003 4:04 AM > To: 'Tomcat Developers List' > Subject: RE: cvs commit: > jakarta-tomcat-connectors/jk/native2/server/isapi jk_isapi_plugin.c > > > Larry, > > > > > Sorry, Clicked the wrong button. :) > > > > No problem, :), i undertands the concerns, and the change > seems a little > daring i know.. anyway, reviewing by peers works, thanks god.. :) > > > To finish the thought, with the change below, does > > > > http://localhost/test%2F/test.jsp > > > > still go to Tomcat? Or is it blocked from going > > to Tomcat because it is a "bad" URL. If it doesn't > > go to Tomcat, how do we know some other filter in the > > chain isn't going to serve it statically? > > > > take into account that to be able to map we first need to unescape the > url. it's the unescaping function the one that gives this > errors, so we > can only block these url prior to do the mapping, so we > really dont know > if the url should go to tomcat or not at this point.. > > And It's almost the same case that in apache you need to explicitely > block WEB-INF, if you want block people from look at there > when using a > configuration where tomcat context it's directly configured > as an apache > served directory.. something that needs to be tweaked to be secure.. > > I think this is the same case, it's an advanced > configuration, there are > posible source disclosures, but it's a risk you can sort out.. like in > the apache WEB-INF case.. > > And the casual and default configuration, doesnt have this "advance" > features.. > > Do you see other way to fix 16759? > > Saludos, > Ignacio J. Ortega > > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
