>), but in the process
I noticed something that I don't like:
When IIS4 (and I presume previous versions, and probably IIS5 as well)
responds to a client trying to access an area protected by Basic
authentication, and the client specifies HTTP 1.0, and if no Realm has been
defined (as by the method above), it can return an internal address. This
information could potentionally be used by crackers to locate other local
hosts.
For example, in our situation, our IIS server resides behind a firewall, which
uses NAT. The internal address is 192.168.42.2 (not really, but for the
purpose of this example it is :), but external hosts see the NAT address of
209.192.88.2. Normally, nobody outside should know anything about the
192.168.42.x address space used internally. But, observe:
dougal:~> telnet 209.192.88.2 80
Trying 209.192.88.2...
Connected to 209.192.88.2.
Escape character is '^]'.
HEAD /secure/test/ HTTP/1.0[CRLF]
[CRLF]
HTTP/1.1 401 Access Denied
WWW-Authenticate: Basic realm="192.168.42.2"
Content-Length: 644
Content-Type: text/html
Connection closed by foreign host.
IIS has just given up a bit of internal information.
Setting a realm string for the root level of the server (then setting separate
realms for subdirs as needed) fixes things:
cd c:\winnt\system32\inetsrv\adminsamples
net stop w3svc
cscript adsutil.vbs set w3svc/realm "ACME Corp"
net start w3svc
FYI, when the client uses HTTP 1.1, they are forced to provide a Host header,
and IIS uses that value as the default realm, if one has not been set in the
MetaBase..
--
Ernest MacDougal Campbell III, MCP
Webmaster, AAA Cooper Transportation
<emc3@aaacooper.com> http://www.aaacooper.com/
<dougal@gunters.org> http://www.gunters.org/~dougal/
