Hi Chris, I suspect that if we were to take the time to set up a proxy, according to RFC7230, we would be able to get the absolute-form to reach the Tomcat code and in that case, based on reading the AbostractHttp11Processor class, I suspect the allowHostHeaderMismatch will kick in and will behave correctly. So I doubt that there is a bug to report at this stage, at least not from my observation.
However, I wonder what all of this means. Could it be that the Host header injection or Host header attack issue can only occur when absolute-form is used, i.e. mostly when proxies are set up? Both you and Mark stated that with origin-form there is nothing to compare the Host header to, which makes sense. Any thoughts on this assessment? Thanks, Ralph -----Original Message----- From: Christopher Schultz <ch...@christopherschultz.net> Sent: Friday, May 27, 2022 4:26 PM To: users@tomcat.apache.org Subject: Re: allowHostHeaderMismatch option only works if the Host Header has an http or https prefix WARNING: This email originated from outside of CallMiner. Do not click any links or open any attachments unless you recognize the sender and know that the content is safe. Please report suspicious emails to: reportsuspiciousema...@callminer.com <mailto:reportsuspiciousema...@callminer.com> 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 --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
