Mark,
On 5/27/22 3:13 AM, Mark Thomas wrote:
On 27/05/2022 02:00, Ralph Atallah wrote:
Hi Mark,
Thanks again for the prompt response.
You wrote below: "If the original request only has a Host header,
then allowHostHeaderMismatch="false" isn't going to do anything
because there is no mismatch.". I am not clear on what this means.
What should the match be between? I thought the comparison for the
match was between the URL's hostname, i.e. "example.com" in the
http://example.com/myapp URL, and the Host header value which is
"attacker.com". If that understanding is incorrect, please point me
in the right direction of what it should be.
The check is that the host in the request URI (if present) is consistent
with the Host header. Nothing more, nothing less.
HTTP requests may or may not include the host in the request URI.
The host named in the the headers of an HTTP request is completely
independent of the host name used to establish the connection to the web
server.
The AbstractHttp11Processor class does not get to the
allowHostHeaderMismatch detection code because the uriBC (URI
ByteChunk) that it reads is expecting an absolute URL
(http://example.com/myapp), but instead, it is getting a relative one
/myapp. The reason I say the code expects an absolute URL is because
it checks for and "http" string at the beginning. This makes me
wonder whether there is a setting that controls that URI format,
absolute or relative.
Your understanding of the HTTP protocol is flawed. You may wish to read
RFC 7230. Specifically:
https://datatracker.ietf.org/doc/html/rfc7230#section-3.1.1
and
https://datatracker.ietf.org/doc/html/rfc7230#section-5.3
Requests with the URI in origin-form do not include a host in the URI.
The purpose of allowHostHeaderMismatch is to ensure that when the
request URI is in absolute-form that the request URI is consistent with
the Host header.
Regarding the addition of a filter that you propose, we have an
existing one in our application, but by the time it is reached, the
URL that we see is already http://attacker.com/myapp, i.e. already
"redirected".
There has been no redirect. The URI reported is a combination of the
Host header and request URI received.
Technically we could check there against a whitelist, but this would
make the solution less out-of-the box, and more needy of user
configuration in our app. We prefer an out-of-the-box secure solution.
Any thoughts on the above?
What you want isn't possible.
Actually, I think what Ralph is requesting is exactly what Tomcat is
providing in the form of allowHostHeaderMismatch (when set to false).
The only problem is that Ralph is saying it's not working because the
URI in the request doesn't contain a hostname *at all* (because it's
optional). So there is nothing to check. Browsers don't bother to send
the optional protocol/hostname/port/etc and instead send the relative
URI -- relative to the Host header (no coincidentally).
If you (Ralph) can reproduce this with wc or telnet where you can force
the URI to be absolute *and* provide a conflicting Host header, then I
think you have grounds for a bug report.
If you want requests to be rejected unless the Host header is on a
user defined allow list (presumably the set of DNS names defined for
the host), then you are going to have to provide a means for the user
to provide that configuration.
I don't think it being requested, here. It may be an aim of their
application to do such things, but that wasn't a part of the initial
request ("prevent host header injection" -- which is very strangely worded).
-chris
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org