On Fri, 30 Aug 2002, Ignacio J. Ortega wrote: > > It may very well be a security issue ( and quite a big one ! > > ). There are > > sites using all kinds of firewalls and settings in httpd.conf to > > restrict access to some hosts or ports ( say from internal network ). > > If Host: info is used for security checkings - it would be trivial to > > bypass some of this security. > > > > In particular - people may have servlets that check getServerName() to > > find if 'localhost' was used - the spec change will leave them with > > a huge hole ( any request with forged Host: localhost will pass ). > > > > > > Good Comment.. > > In the particular case you have pointed, it's a user problem, a request > with Host: Localhost can be only be issued by someone with Remote > Ip=localhost..
'localhost' is just an example. The server may have 2 ip addresses, one visible from outside and one restricted by firewalls to only internal users ( and used for example for content updates ). In servlet 2.2 and 2.3, it is perfectly valid to use getServerName() and get the address that received the request. Since the servlet spec doesn't provide any 'declarative' support for this kind of access control - I think this is a valid solution. A firewall or routing can protect the internal address ( say 10.0.0.1 - on a network card connected only to the internal net, and a firewall restricting outside access to this IP ). In 2.4 this will fail ( opening potential holes ) and in addition this kind of check will be impossible to implement - since the address where the request was received will no longer be available. > So one can take some security measures to check the correctness of the > request.. For example ? > All other use case i can imagine fall within the users problems, if the > correct VS has received the request, it's the Remote IP appropiate for > that VS? matchs port where the request has been received the port where > is suppoussed that the VS is? If by 'user' you mean the servlet author - I disagree. Such checks are prefectly reasonable and correct IMO. > But By far in the Journey we have learned something, never trust a Host > Header without first trust the Remote IP, at least for ultra-secure > apps.. Well, the remoteIP is much more difficult to test - if you're a big organization you may have dozens of internal IPs. And most people do trust their firewalls to restrict access to a particular IP, I've seen this kind of setup in several cases ( where you use a special interface for internal users ). > And another thing, i wonder if it would be appropiate to check if a > request came from the (at least) correct port before dispatching it to > the VS.. at least within TC, and check if Apache2 is taking any measures > to be certain of this fact.. The comment in apache sugest that Host shouldn't be trusted. If they started to trust it sudenly - they should at least modify the comment and explain how is this trust justified. Host is sent by the user - it is trivial to forge. The port and host that actually receives the request are pretty safe and difficult to trick, especially if a firewall is used in front. Costin -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
