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
