How is an invalid host header getting set on the incoming request?
This header is set by the browser to confirm the host name and port combination it is using to communicate with the server (which often the server is not even aware of) - I see two scenarios that could lead to a spoofed header: -
- A hacked web browser.
- An intermediary in the call modifying the headers.
The integrity of the client is very important, there are some places such as in relation to cross original resource sharing that both the client side and the server side of the connection need to work together to handle the required checks safely. But also in that scenario it would be saying the client is deliberately asking to be redirected to evil.com.
The second scenario was an intermediary, if an intermediary was able to modify the request message then it is likely they would also be able to modify the response message and so the client could still be redirected to evil.com.
so you basicly don't want "webapp" part of the request uri in your url?
you could just bind your application to / context.
you can do that by renaming the war to ROOT.war
or by adding jboss-web.xml with <context-root>/</context-root> to WEB-INF folder
I understand what you are stating, but we are more concerned with what the application does with the host header value. We recommend to our teams that they don't trust that value and to get it from the environment, but when this issue comes up in a report it must be resolved due to the policies we have in place. This was found in whitebox testing using a curl command similar to the one I posted.
Sorry I wasn't clear. I want the uri part. I just don't want localhost:8443 changed to evil.com in the response. I was trying to be general in the result of any request.
I checked the HTTP 1.1 spec and it does look like the current behaviour that you are noticing is probably not right. The Host header usage/expecations is spread across multiple sections   of the RFC. In context of what you are noting here, the important section from that spec appears to be this which states:
If Request-URI is an absoluteURI, the host is part of the Request-URI. Any Host header field value in the request MUST be ignored.
So it looks like Undertow isn't ignoring the header field in this case. swd847 might know whether this is expected or is a bug.
If you want to do this then just setup two virtual hosts, a default one that is empty (i.e. will return 404), and a virtual host for 'localhost' that has your applications deployed. Any request with a bogus host header will end up being handled by the empty virtual host.
There is nothing we can do about this without explicit configuration (i.e. we can't guard against this in the default config, as we don't know which hosts are allowed). We could remove the default virtual host from standalone.xml and just have a host for localhost by default, but that means to use Wildfly in production you need to make configuration changes, and is very user unfriendly.