On 29/08/2023 21:51, Bhavesh Mistry wrote:
Hi Mark,
curl -vvvv -k "https://www.mydomain.com/login"; -H 'Host:
attackerHostHeaderInjection.com'
*Why? What problem are you trying to solve?*
Host Header injection is a vulnerability that needs to be addressed., I am
trying to solve if the host is a mismatch between the HOST ( or Authority)
header because links are generated based on the host headers.
For now only way to prevent it is to have a set of allowed hosts and check
against this list.
I'd argue that links shouldn't be being generated based on the Host
header. You should be able to use relative links. That said...
Given the wide variety of deployment architectures (CDN, reverse procy
etc) if you do need to use the Host header, validation against a known
trusted list is probably the most robust option. TLS information may not
always be available.
Should I update the bug to provide SNI information for the request or
should I file another request ?
See also https://bz.apache.org/bugzilla/show_bug.cgi?id=64353
I'd say add it to that issue as the two are closely related.
3) I tried following but again curl -vvvv shows it never sent
www.mydomain.com <https://www.mydomain.com/login> since it only used to
reach the IP. (This is what Thomas Hoffmann mentioned).
https://serverfault.com/questions/850955/tomcat-virtual-host-to-prevent-improper-input-handling-attack
Thanks for your help so far.
There is another option.
The Host header is used for virtual host selection. If you create a
valid virtual host for each valid host name (you can have aliases so
they could all go to the same host) then the default virtual host could
just have a ROOT webapp that returned you 4xx response of choice.
It is just a different way of implementing an allow list for the Host
header. The advantage is that it is transparent to the application(s).
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
