The only available option in the server configuration is to limit the hostnames that are mapped to the default_host virtual host or deploy your app to a virtual host that is similarly restricted.
A recipe can be seen here: https://publib.boulder.ibm.com/httpserv/ihsdiag/vulnerabilities.html#configure-was-to-only-execute-your-web-modules-application-only-on-specific-hostnames
On the topic of the vulnerability itself, in my personal opinion it seems like a scare tactic from the pen-test industrial complex:
> Risk: It is possible to deface the site content through web-cache poisoning
HTTP caches uses the Host: header as part of the cache key. To the extent your real servers configuration matters at all, it can only result in a cached response for a hostname no victim will use. If the attacker also has to get the victim to click on a link to a malicious hostname (that they encourage you to configure your application to not accept), they can already show them anything they want there without the use of any cache or your application server.
------------------------------
Eric Covener
------------------------------
Original Message:
Sent: Tue September 05, 2023 12:54 PM
From: Rod Allen
Subject: configuring WebSphere Liberty to prevent host header injection?
Hello,
We have run a penetration test using HCL AppScan against an application running on WebSphere Liberty 23.0.0.5 which identified a risk of Host Header Injection with wording such as
Risk: It is possible to deface the site content through web-cache poisoning
It is possible to persuade a naive user to supply sensitive information such as username, password, credit card number, social
security number etc.Cause: Lack of input validation and sanitization
Fix: Construct HTTP headers very carefully, avoiding the use of non-validated/unsanitized input data
I am told by some colleagues that this was resolved in Wildfly via the use of filters such as
<filter-ref name="host-checker"/>
<filters> <expression-filter name="host-checker" expression="not(equals(%{i,HOST}, validhost)) -> response-code(403)"/> </filters>
is there any equivalent setting that can be applied to the server.xml of WebSphere Liberty? I found this article https://openliberty.io/docs/latest/forwarded-header.html but I could not find any clear examples with example urls or regexp - just this generic example :-
<remoteIp proxies="<regular_expression>" useRemoteIpInAccessLog="<true/false>"/>
Is this the right setting and if so can anybody please suggest how this can be used to achieve the desired result or if there are other ways to satisfy this penetration test (and prevent genuine threats of this type)
Thanks
Rod
------------------------------
Rod Allen
------------------------------