We have been running Tomcat 9.0.71 with HSTS configured for many months without any configuration changes. This month our PCI scan suddenly started failing due to "Redirection via Arbitrary Host Header Manipulation."
I can recreate the vulnerability using an API client tool: GET: http://example.com And set header Host = google.com
That GET reaches the Tomcat server and NOT the application, as expected; the result in the client is redirection to google.com, which is the apparent vulnerability.
I can still recreate the vulnerability if the GET protocol is HTTPS and the specified host is missing a protocol: GET: https://example.com And set header Host = google.com
That GET reaches the Tomcat server AND the application (where I could hypothetically add code to validate the host).
I have reviewed our implementation of HSTS and believe it is correct, including a security-constraint in web.xml specifying the url-pattern /* and in Server.xml a Connector redirecting port 80 to port 443. Incidentally the HSTS configuration seems to implement redirection even if the port 80 Connector is missing the redirectPort attribute.
I have investigated the Connector attribute allowHostHeaderMismatch, which per documentation is hard-coded to false. In the example GET call, if the protocol is added so that Host = http://google.com, the result becomes "400 Bad Request error," as expected. To me this suggests that allowHostHeaderMismatch doesn't work (well enough), but other posts suggest that allowHostHeaderMismatch works correctly per the specification.
How can I get Tomcat to disallow the host header manipulation? Or otherwise solve this vulnerability?