httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alexei Kosut <ako...@nueva.pvt.k12.ca.us>
Subject Re: security holes and other fun stuff
Date Sun, 14 Jul 1996 05:17:58 GMT
On Sat, 13 Jul 1996, Brian Behlendorf wrote:

[...]

> Hmm, I'm not so sure I buy that.  You can't expect the application to know
> about security policies that sit at a layer below it - when your mapping
> between those two layers dissolves, then you need to find another mapping.
> 
> The only thing I can think of is to be a little more conservative with the
> vhost stuff and say, "If vhost Y maps to the primary IP address which I've
> bound myself to, then it's a Host:-based host - if it maps to a secondary
> IP address, then it's not Host:-based", but that would disallow certain
> other expected functionalities, like letting two web sites share the same
> secondary IP address. 

The current code doesn't do this *quite* right, but that's the theory,
at any rate... pretend you had ten servers, all Host-header based. And
your server sits on two networks, competely isolated, but they both
know about the same names. You want to give each of them differnet
documents. So you set up twenty virtual hosts, ten using one IP
address, ten using the other, and for each of the ten hostnames, you
give that ServerName one to each IP address. Should work...

At any rate, if you want, there's an undocumented "feature" that will
deactive host-header based resolving for a virtual host: make the
ServerName end with a dot, e.g. "ServerName some.server.name." - it
should still be a valid name, but the Apache code that checks Host:
headers will never find a match for it, because it strips off trailing
dots.

[...]

> I'd prefer the name the vhost responds to should be a union of the
> ServerName and ServerAlias settings, not just ServerAlias.  Ugh, but then
> you get things like

It is. For each virtual host, it checks first to see if the Host:
header matches ServerName, then the entries in ServerAlias. What it
*doesn't* look at (unless you don't have a ServerName) is what you put
in the <VirtualHost> entry. You can put anything, it doesn't care, or
check.

[...]

> > P.S. People doing SSL for apache 1.1 should watch out for the "http://"
> > comparisons in check_hostalias().
> 
> Eeek!

I don't see an eeek. Apache supports plain, simple, HTTP. If people
hack it to support SSL, they need to change all this stuff. I suppose
it could go and look for a "://", but then you run into real problems
if you're operating as a proxy server and people request things like
"ftp://your.server.name.here/" - you'd need to have a list of what
protocols your server supports anyway.

> > P.P.S.  Hostnames such as "123.hotwired.com" are valid, yet find_allowdeny
> > does not properly handle them.  This should be put on Known Bugs.  Be
> > careful when fixing this because just removing the isalpha() check creates
> > a security hole, consider the DNS map "1.1.1.1.in-addr.arpa IN PTR 2.2.2."
> > if the user has a config line "allow from 2.2.2" it will allow 1.1.1.1 in
> > (unless -DMAXIMUM_DNS).  -- which is bad because it breaks people who
> > understand double reverse lookup and are trying to avoid it by using
> > only ip addresses on allow/deny statements.
> 
> Good one.  I've added it to the known_bugs page.

Correct me if I'm wrong, but I thought I'd read somewhere that
starting domain names with a number was in the "technically allowed,
but we don't reccomend it, and we think it's a really bad idea, and if
you do it, be warned that we're likely to make it illegal sometime
soon" category.

-- 
________________________________________________________________________
Alexei Kosut <akosut@nueva.pvt.k12.ca.us>      The Apache HTTP Server
URL: http://www.nueva.pvt.k12.ca.us/~akosut/   http://www.apache.org/


Mime
View raw message