You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tomcat.apache.org by Mark Thomas <ma...@apache.org> on 2021/09/27 11:02:55 UTC
Refactoring handling of TRACE requests
Hi all,
I've been having some conversations at $work about Tomcat's handling of
TRACE requests and the allowTrace option on the Connector. Something
that was said in that discussion got me thinking. Why do we have special
handling for TRACE requests on the Connector? Why not use a security
constraint in the global web.xml?
I've done a quick test, setting allowTrace to true on the Connector and
adding the following to the global web.xml:
<security-constraint>
<web-resource-collection>
<url-pattern>/*</url-pattern>
<http-method>TRACE</http-method>
</web-resource-collection>
<auth-constraint />
</security-constraint>
This blocks TRACE requests as expected.
What do the folks here think about deprecating allowTrace on the
Connector for 10.0.x and removing it (and the special handling in
HttpServlet) in 10.1.x onwards - replacing it with the security
constraint above.
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: Refactoring handling of TRACE requests
Posted by Mark Thomas <ma...@apache.org>.
On 27/09/2021 14:02, Rémy Maucherat wrote:
> On Mon, Sep 27, 2021 at 1:03 PM Mark Thomas <ma...@apache.org> wrote:
>>
>> Hi all,
>>
>> I've been having some conversations at $work about Tomcat's handling of
>> TRACE requests and the allowTrace option on the Connector. Something
>> that was said in that discussion got me thinking. Why do we have special
>> handling for TRACE requests on the Connector? Why not use a security
>> constraint in the global web.xml?
>>
>> I've done a quick test, setting allowTrace to true on the Connector and
>> adding the following to the global web.xml:
>>
>> <security-constraint>
>> <web-resource-collection>
>> <url-pattern>/*</url-pattern>
>> <http-method>TRACE</http-method>
>> </web-resource-collection>
>> <auth-constraint />
>> </security-constraint>
>>
>> This blocks TRACE requests as expected.
>>
>> What do the folks here think about deprecating allowTrace on the
>> Connector for 10.0.x and removing it (and the special handling in
>> HttpServlet) in 10.1.x onwards - replacing it with the security
>> constraint above.
>
> It might not matter much these days, but this still looks like it
> would be considerably less efficient (for a flag that will actually
> never be set to false, right ?).
I can do some performance testing to see what the impact is. We can then
judge the impact vs the benefit.
I suspect most users will leave the option as is but there might be a
few that are happy enabling TRACE.
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: Refactoring handling of TRACE requests
Posted by Rémy Maucherat <re...@apache.org>.
On Mon, Sep 27, 2021 at 1:03 PM Mark Thomas <ma...@apache.org> wrote:
>
> Hi all,
>
> I've been having some conversations at $work about Tomcat's handling of
> TRACE requests and the allowTrace option on the Connector. Something
> that was said in that discussion got me thinking. Why do we have special
> handling for TRACE requests on the Connector? Why not use a security
> constraint in the global web.xml?
>
> I've done a quick test, setting allowTrace to true on the Connector and
> adding the following to the global web.xml:
>
> <security-constraint>
> <web-resource-collection>
> <url-pattern>/*</url-pattern>
> <http-method>TRACE</http-method>
> </web-resource-collection>
> <auth-constraint />
> </security-constraint>
>
> This blocks TRACE requests as expected.
>
> What do the folks here think about deprecating allowTrace on the
> Connector for 10.0.x and removing it (and the special handling in
> HttpServlet) in 10.1.x onwards - replacing it with the security
> constraint above.
It might not matter much these days, but this still looks like it
would be considerably less efficient (for a flag that will actually
never be set to false, right ?).
Rémy
>
> Mark
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: dev-help@tomcat.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: Refactoring handling of TRACE requests
Posted by Mark Thomas <ma...@apache.org>.
On 28/09/2021 00:33, Konstantin Kolinko wrote:
> пн, 27 сент. 2021 г. в 14:03, Mark Thomas <ma...@apache.org>:
>>
>> Hi all,
>>
>> I've been having some conversations at $work about Tomcat's handling of
>> TRACE requests and the allowTrace option on the Connector. Something
>> that was said in that discussion got me thinking. Why do we have special
>> handling for TRACE requests on the Connector? Why not use a security
>> constraint in the global web.xml?
>>
>> I've done a quick test, setting allowTrace to true on the Connector and
>> adding the following to the global web.xml:
>>
>> <security-constraint>
>> <web-resource-collection>
>> <url-pattern>/*</url-pattern>
>> <http-method>TRACE</http-method>
>> </web-resource-collection>
>> <auth-constraint />
>> </security-constraint>
>>
>> This blocks TRACE requests as expected.
>>
>> What do the folks here think about deprecating allowTrace on the
>> Connector for 10.0.x and removing it (and the special handling in
>> HttpServlet) in 10.1.x onwards - replacing it with the security
>> constraint above.
>
> In short, it does not work. See point 1.c) below and my test runs
> below an "~~~~~~~~~" bar.
> I am leaving my other points as I wrote them, for completeness.
Thanks for checking this. I hadn't fully thought through the
implications of the rules for combining security constraints.
I agree, my proposal isn't going to work.
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: Refactoring handling of TRACE requests
Posted by Konstantin Kolinko <kn...@gmail.com>.
пн, 27 сент. 2021 г. в 14:03, Mark Thomas <ma...@apache.org>:
>
> Hi all,
>
> I've been having some conversations at $work about Tomcat's handling of
> TRACE requests and the allowTrace option on the Connector. Something
> that was said in that discussion got me thinking. Why do we have special
> handling for TRACE requests on the Connector? Why not use a security
> constraint in the global web.xml?
>
> I've done a quick test, setting allowTrace to true on the Connector and
> adding the following to the global web.xml:
>
> <security-constraint>
> <web-resource-collection>
> <url-pattern>/*</url-pattern>
> <http-method>TRACE</http-method>
> </web-resource-collection>
> <auth-constraint />
> </security-constraint>
>
> This blocks TRACE requests as expected.
>
> What do the folks here think about deprecating allowTrace on the
> Connector for 10.0.x and removing it (and the special handling in
> HttpServlet) in 10.1.x onwards - replacing it with the security
> constraint above.
In short, it does not work. See point 1.c) below and my test runs
below an "~~~~~~~~~" bar.
I am leaving my other points as I wrote them, for completeness.
Looking at a copy of the Servlet Specification 4.0
1. How does that global constraint combine with one from webapp's
web.xml and webapp's annotations?
a) I am not sure: are they all combined according to the rules stated
in the Servlet specification, or webapp settings override the global
defaults?
I think it is the former, but I do not see explicit mention in the
docs (googling for "combine", "web.xml", "conf").
b) Spec ch.13.8.1 Combining Constraints
"The special case of an authorization
constraint that names no roles shall combine with any other
constraints to override
their affects and cause access to be precluded."
If the answer to a) was "they are combined", it means that a web
application cannot override the global "<auth-constraint />" that
precludes access.
c) Spec ch.13.8.3 Processing Requests
"When a Servlet container receives a request, it shall use the
algorithm described in
“Use of URL Paths” on page 125 to select the constraints (if any) defined on the
url-pattern that is the best match to the request URI."
It means that the global constraint with <url-pattern>/*</url-pattern>
is only applied when there is no better match for the URL. (It is
combined only with constraints that use the same "/*", but not with
any other better matches).
Compare it with how filters are applied: any matching Filter is
applied (ch.6.2.4), not just the best match.
There is an example in ch.13.8.2:
[[[
<security-constraint>
<web-resource-collection>
<web-resource-name>precluded methods</web-resource-name>
<url-pattern>/*</url-pattern>
<url-pattern>/acme/wholesale/*</url-pattern>
<url-pattern>/acme/retail/*</url-pattern>
<http-method-omission>GET</http-method-omission>
<http-method-omission>POST</http-method-omission>
</web-resource-collection>
<auth-constraint/>
</security-constraint>
]]]
The intent is to deny all methods except GET and POST. Note that
instead of using just a "/*" pattern, it has to list the other two
patterns used by other security constraints in the app. Otherwise it
is not combined with them.
Thus my conclusion is that not all TRACE requests are blocked with
that configuration.
2. Some users upgrade Tomcat between versions by swapping the binaries
(changing CATALINA_HOME). If they have to apply changes to their
configurations (the files in CATALINA_BASE/conf/) to stay protected,
there is a risk that the changes won't be applied.
~~~~~~~~~
Testing whether what I noted in 1.c) is true with Tomcat 10.1.0-M5:
1) default configuration
Request: TRACE / HTTP/1.0
Response: HTTP/1.1 405
Allow: GET, HEAD, POST, OPTIONS
Req: TRACE /tomcat.css HTTP/1.0
Resp: HTTP/1.1 405
Allow: HEAD, DELETE, POST, GET, OPTIONS, PUT
2) added allowTrace="true" on the Connector.
Request: TRACE / HTTP/1.0
Response: HTTP/1.1 405
Allow: GET, HEAD, POST, OPTIONS
No changes. The reason is that the above is processed by JspServlet
(for index.jsp), not by DefaultServlet.
Req: TRACE /tomcat.css HTTP/1.0
Resp: HTTP/1.1 200
OK. TRACE request is now allowed.
3) also added the proposed <security-constraint> to conf/web.xml
Req: TRACE / HTTP/1.0
Resp: HTTP/1.1 403
Note that it is 403 instead of 405.
Req: TRACE /tomcat.css HTTP/1.0
Resp: HTTP/1.1 403
OK, denied with 403.
Req: TRACE /manager/status HTTP/1.0
Resp: HTTP/1.1 401
Note that it is 401 instead of 403 or 405.
4) If I also change webapps/manager/WEB-INF/web.xml:
I remove auth-constraint element from security-constraint for /status/*,
i.e. to allow unauthenticated access to Status servlet
Req: TRACE /manager/status HTTP/1.0
Resp: HTTP/1.1 200
The TRACE request is not denied.
Best regards,
Konstantin Kolinko
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org