misplaced trust in Host header

[Jamie Heilman]

Zope implicitly trusts the Host header from client requests, and uses its
value to construct the results from absolute_url(), and the URL*, BASE*,
and REQUESTPATH* HTTPRequest object variables. Unfortunately that behavior
allows malicious requests to poison server-side caches, tamper with log
files, and until recently posed a cross-site-scripting risk.

Ideally Zope would know which domains its responsible for and do something
sensible with requests for resources outside of its jurisdiction.

Several partial workarounds exist, but they tend to be problematic.
Using a VirtualHostMonster reduces the risk from malicious Host headers
provided the gateway server does host validation. Unfortunately VHMs
obtain their host data via the traversal stack, which can't be trusted
either, which leaves us somewhat screwed one way or the other.

References to bear in mind:
issue #813, where all this started
http://marc.theaimsgroup.com/?l=zope&m=104639584701163&w=2
http://marc.theaimsgroup.com/?l=zope&m=105433510519201&w=2 (important)

This bug is security related, but it should remain public (as should all bugs IMO.)

[Tres Seaver (tseaver)]

If it weren't for the allegation that this bug is security related, I would
WONTFIX it today.

I'm leaving it open in case somebody wants to propose some "tinfoil hat"
remediation, but there is effectively zero chance of any such patch landing
in Zope itself: it would likely break nearly every application deployed
today.

[Colin Watson (cjwatson)]

The zope2 project on Launchpad has been archived at the request of the Zope developers (see https://answers.launchpad.net/launchpad/+question/683589 and https://answers.launchpad.net/launchpad/+question/685285). If this bug is still relevant, please refile it at https://github.com/zopefoundation/zope2.