Trusted host settings handling - multiple issues

[indigoxela]

Description of the bug

In an attempt to prevent HTTP Host header spoofing, trusted_host_patterns handling has been added to Backdrop in #2568

The implementation has multiple issues, though.

Steps To Reproduce

The easiest way to reproduce is to remove the actual hostname from trusted_host_patterns setting (in settings.(local.)php and call any page with it. That's the easiest way, but not the only one.

Actual behavior

Exception: The HTTP Host "example.com" is not white-listed for this site. Check the trusted_host_patterns setting in settings.php. in _backdrop_bootstrap_configuration() (line 3128 of /var/www/testing/html/core/includes/bootstrap.inc). 

Issues with that:

1. This throws an Exception, that will show up as 500 Internal Server Error in webserver logs - as if it was a problem on the site, while it's a problem with the request
2. It uses the term "white-listed", which we removed anywhere else already
3. It points to the code line in bootstrap.inc, when error display is turned on - as if this were a problem to get fixed in code
4. It recommends action in settings.php, but the audience here is not primarily the site admin, it's public

Expected behavior

First of all, the error has to be 400 Bad Request.

The wording shouldn't use deprecated terms and the hint shouldn't point to action with settings.php.

Additional information

• Backdrop CMS version: latest dev

While this may seem to hardly ever occur, this occurs regularly, if Backdrop is the default host on an IP.

And it's super easy to flood the webserver logs with 500-s from outside just by using something like:

curl -I -H 'Host:foobar.com' http://ACTUAL_HOSTNAME_OR_IP

And I don't think, the bots crawling a site (primary audience for that message) will bother to fix it in settings.php 😜 They sure would like to have access to that file, but... nope.

[indigoxela]

And here's now the PR for local testing (no chance to test anything with the sandbox): backdrop/backdrop#5087

Additionally to the appropriate 400 status code, it returns a less verbose text (without call to action):

HTTP Host "example.com" is not included in "trusted_host_patterns" setting of this site.

That should still be sufficient information for site admins.

[yorkshire-pudding]

Looking at https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Status#client_error_responses I see there are many codes that offer more specific responses. I wonder whether 421 Misdirected Request may be a better fit ?

The request was directed at a server that is not able to produce a response. This can be sent by a server that is not configured to produce responses for the combination of scheme and authority that are included in the request URI.

Tangent: who uses 418? 😆

[yorkshire-pudding]

Tested and can confirm it works as expected

[indigoxela]

Tangent: who uses 418? 😆

Yay, time driven - on April 1st 🤣

Nah, focus... let's stay focused! 😉

@yorkshire-pudding wording suggestion committed.

I wonder whether 421 Misdirected Request may be a better fit ?

Some background: D7 and D10+ use 400 as well.
And Backdrop bootstrap already uses 400 for invalid HTTP_HOST values (backdrop_environment_initialize()).

Let's have a closer look at the specs : https://httpwg.org/specs/rfc9110.html#status.400

The 400 (Bad Request) status code indicates that the server cannot or will not process the request due to something that is perceived to be a client error (e.g., malformed request syntax, invalid request message framing, or deceptive request routing).

Note the "...deceptive request routing".

421 would indicate, that a request was erroneously directed to this IP / host, which is not what happens.