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
>
>
