I think you're missing the virtual server angle. There is NOT a 1-1 mapping
from ip address to DNS name. It's N-M. Even from the standpoint of a single
machine which received the request, there are many possible names for the IP
address.
So, given a request like:
GET /pub/WWW/TheProject.html HTTP/1.1
Host: www.w3.org
The only way to know which host the client intended is the Host header.
So, yes, this is spoofable, and should not be used as a security mechanism.
It was never designed to be one.
> -----Original Message-----
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
> Sent: Friday, August 30, 2002 2:50 PM
> To: Tomcat Developers List
> Subject: RE: Spec question: RE BUG 12052
>
>
> 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]>
>
>
>
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
