Hi Christopher,
Thanks for the suggestion. But I don't have the luxury of using a Load
balancer or Proxy. I kind of agree that it would be best to handle outside
tomcat.
At this point, it is working as expected after all changes mentioned in the
thread. Again, I value your opinion and feedback.
Thanks,
Bhavesh
On Mon, Oct 10, 2022 at 7:59 PM Christopher Schultz <
ch...@christopherschultz.net> wrote:
> Bhavesh,
>
> On 10/10/22 22:05, Bhavesh Mistry wrote:
> > I figured out the issue by default *mapperContextRootRedirectEnabled is
> > true* hence it was redirecting it. By setting it false, I was able to
> get
> > controller to filter.
> >
> > <Context *mapperContextRootRedirectEnabled="false"*
> >
> > Mark and everyone thanks for your help!
>
> At the risk of complicating things, if I were you I would handle this
> completely outside of Tomcat. You may not already be using a
> load-balancer, reverse-proxy, or WAF, but IMHO that's the best place to
> do this kind of thing.
>
> In order to do this in Tomcat, you have had to change a few settings and
> one of them -- the one which enforces CONFIDENTIAL transport -- may be
> more easily bypassed within your application than when allowing Tomcat
> to do it for you.
>
> BTW, OPTIONS requests are used for pre-flight AJAX requests. You may
> break your application by disabling OPTIONS. (Also note that
> lb/rev-proxy/WAF can be configured to respond to OPTIONS requests rather
> trivially, and you can still refuse them from your application servers.)
>
> Hope that helps,
> -chris
>
> > On Mon, Oct 10, 2022 at 1:56 PM Bhavesh Mistry <
> mistry.p.bhav...@gmail.com>
> > wrote:
> >
> >> Hi Mark ,
> >>
> >> Thank you for your feedback. I have made all the changes needed and it
> is
> >> working as expected except for ONE use case where the servlet context
> path
> >> does not end with */*. When server context path is given without /
> >> ('/versa'), tomcat seems to do 302 redirect to automatically '/versa/'.
> >> How can I change this behavior so that the OPTIONS method returns 405
> from
> >> the filter instead of tomcat auto-redirecting to the context path?
> >>
> >> curl -i -k -X OPTIONS http://10.43.243.8*/versa*
> >> HTTP/1.1 302
> >> Location: /versa/
> >> Transfer-Encoding: chunked
> >>
> >> curl -i -k -X OPTIONS http://10.43.243.8*/versa/*
> >> HTTP/1.1 405
> >> Cache-Control: private
> >> Content-Length: 0
> >>
> >>
> >>
> >> Here is the updated web.xml security containers:
> >>
> >> <security-constraint>
> >> <web-resource-collection>
> >> <web-resource-name>HTTPSOnly</web-resource-name>
> >> <url-pattern>/*</url-pattern>
> >> </web-resource-collection>
> >> </security-constraint>
> >> <security-constraint>
> >> <auth-constraint>
> >> <!-- empty constraint: forbid all access -->
> >> </auth-constraint>
> >> </security-constraint>
> >>
> >> Thanks in advance for your help.
> >>
> >> Thanks,
> >>
> >> Bhavesh
> >>
> >>
> >>
> >>
> >> On Fri, Oct 7, 2022 at 12:06 PM Mark Thomas <ma...@apache.org> wrote:
> >>
> >>> On 07/10/2022 19:47, Bhavesh Mistry wrote:
> >>>> Hi Mark,
> >>>>
> >>>> Thank you for your quick response. Your proposed solution works by
> >>>> removing the transport-guarantee element. Another quick question, I
> >>> have
> >>>> Connection has a property called allowTrace method. Is it possible to
> >>>> configure TOMCAT Connector to disallow TRACE,OPTIONS,HEAD,CONNECT
> rather
> >>>> than having custom logic at the application level?
> >>>
> >>> No.
> >>>
> >>>> Do you think it good idea to have Connector Config which method to
> >>> allow and disallow?
> >>>
> >>> No.
> >>>
> >>> I don't think it is a good idea to have an option to disable TRACE at
> >>> the connector level. I'd be quite happy to remove that feature but I'm
> >>> fairly sure I would not be able to get consensus to do that.
> >>>
> >>> My understanding is that TRACE got its poor reputation due to a
> >>> misbehaving browser. Rather than pressure the browser vendor to fix
> >>> their broken browser, the security community decided to pressure the
> >>> server community to disable the functionality the browser didn't handle
> >>> properly. That just seems backwards to me no matter how big the
> >>> browser's market share might have been at the time and how reluctant to
> >>> change the vendor was.
> >>>
> >>> CONNECT returns 405 by default in a Servlet container and none of
> TRACE,
> >>> OPTIONS or HEAD are inherently unsafe.
> >>>
> >>> Mark
> >>>
> >>>
> >>>>
> >>>> Thanks,
> >>>>
> >>>> Bhavesh
> >>>>
> >>>> On Fri, Oct 7, 2022 at 10:59 AM Mark Thomas <ma...@apache.org> wrote:
> >>>>
> >>>>> On 07/10/2022 18:09, Bhavesh Mistry wrote:
> >>>>>> Hi Tomcat Team,
> >>>>>>
> >>>>>> We have a unique situation. We wanted to block ALL *OPTIONALS* HTTP
> >>>>> method
> >>>>>> on port 80 and 443.
> >>>>>>
> >>>>>> We have connector definitions as follows:
> >>>>>>
> >>>>>>
> >>>>>> <Connector executor="tomcatThreadPool"
> >>>>>> port="8080" protocol="HTTP/1.1"
> >>>>>> connectionTimeout="20000"
> >>>>>> redirectPort="8443" />
> >>>>>> -->
> >>>>>> -->
> >>>>>> <Connector port="${tomcat.secure.port}"
> >>>>>> protocol="org.apache.coyote.http11.Http11NioProtocol"
> >>>>>> relaxedPathChars="[\\]^`{|}"
> >>>>> relaxedQueryChars="[\\]^`{|}"
> >>>>>> address="${tomcat.address}" minSpareThreads="100"
> >>>>>> maxThreads="200" SSLEnabled="true"
> >>>>>> scheme="https" secure="true" maxSwallowSize="-1"
> >>>>>> maxPostSize="-1">
> >>>>>> <UpgradeProtocol
> >>>>> className="org.apache.coyote.http2.Http2Protocol"
> >>>>>> readTimeout="50000" streamReadTimeout ="-1" streamWriteTimeout="-1"
> >>>>>> overheadContinuationThreshold="0"
> overheadDataThreshold="0"
> >>>>>> overheadWindowUpdateThreshold="0"/>
> >>>>>>
> >>>>>> </Connector>
> >>>>>>
> >>>>>> and we have an application filter to block and return 405. This
> works
> >>>>> for
> >>>>>> HTTPS port 443. But request going to HTTP port 80 always get
> >>> redirected
> >>>>>> regardless of the method.
> >>>>>>
> >>>>>> curl -i -k -X OPTIONS http://10.43.243.8/versa/
> >>>>>> *HTTP/1.1 302*
> >>>>>> Cache-Control: private
> >>>>>> Location: https://10.43.243.8/versa/
> >>>>>> Content-Length: 0
> >>>>>> Date: Fri, 07 Oct 2022 16:58:27 GMT
> >>>>>> Server: Versa Director
> >>>>>>
> >>>>>> curl -i -k -X OPTIONS https://10.43.243.8/versa/
> >>>>>> *HTTP/2 405*
> >>>>>> cache-control: private
> >>>>>> content-length: 0
> >>>>>> date: Fri, 07 Oct 2022 16:58:51 GMT
> >>>>>>
> >>>>>> We wanted to block OPTIONS on port 80 as well, it seems to me that
> >>> tomcat
> >>>>>> internally (via connector) redirects requests without application
> >>> code.
> >>>>>> How can I achieve blocking OPTIONS, TRACE, and CONNECT HTTP methods
> >>> on
> >>>>>> port 80 while redirect is ON for the connector?
> >>>>>>
> >>>>>> Any pointers or help is greatly appreciated.
> >>>>>
> >>>>> Tomcat only redirects http to https as the result of an application
> >>>>> defined transport-guarantee element in web.xml.
> >>>>>
> >>>>> Security constraints get processed before Filters.
> >>>>>
> >>>>> You can't change the either of the above.
> >>>>>
> >>>>> What you could do, is remove the transport-guarantee from web.xml and
> >>>>> perform the http to https redirect in your Filter. Then you'd have
> the
> >>>>> option to return 405 instead of the redirect.
> >>>>>
> >>>>> Mark
> >>>>>
> >>>>> ---------------------------------------------------------------------
> >>>>> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> >>>>> For additional commands, e-mail: users-h...@tomcat.apache.org
> >>>>>
> >>>>>
> >>>>
> >>>
> >>> ---------------------------------------------------------------------
> >>> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> >>> For additional commands, e-mail: users-h...@tomcat.apache.org
> >>>
> >>>
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
>
