COMMAND

    IE

SYSTEMS AFFECTED

    Systems running IE 4.x

PROBLEM

    Jim  Paris  posted  following.   IE4  still  has big problems with
    distinguishing between  sites that  belong in  the "Internet Zone"
    and sites that belong in the "Local Intranet Zone".  IE #26 in  NT
    section dealt with  addresses such as  http://031713501415/, which
    resolve to  Internet hosts  but are  categorized as  being in  the
    "Local Intranet  Zone".   Jim found  two cases  where the  problem
    still exists.  The first is  when the user has the "Domain  Suffix
    Search Order" in  the TCP/IP DNS  settings set to  include domains
    such as "com".  In  that case, the address http://microsoft/  will
    retrieve  the  page  at  http://microsoft.com/  but  it  will   be
    considered to be in the "Local Intranet Zone".

    The second case occurs  when a host has  an assigned alias in  the
    hosts table (C:\WINDOWS\HOSTS).  A host table entry such as:

        207.46.131.13   hello

    will cause the URL

        http://hello/

    to retrieve the page at http://207.45.131.13/, but (yep, you guess
    it)  Internet  Explorer  still  considers  it  to be in the "Local
    Intranet Zone".   This has  security implications,  since settings
    for the  Local Intranet  Zone may  be (and,  by default, ARE) less
    secure than those for the Internet Zone.

SOLUTION

    If you are concerned about  the problem, simply remove .com,  etc.
    from your  DNS suffix  search, and  don't put  nasty hosts in your
    hosts file.   Anyway, just because  you added a  DNS suffix search
    order and put hosts into your  hosts file does not (or, at  least,
    SHOULD not) mean that tou're choosing "specific settings to  allow
    the problem to occur".

    The rule for  Intranet zone is  simple -- if  the name has  no "."
    and is  less than  15 characters  long, then  it's Intranet  zone.
    This algorithm  works with  the default  configuration of Windows.
    If you  configure your  machine so  that the  above assumption  is
    violated, then  you'll get  a mis-classification.   When designing
    better ways  of doing  this, keep  in mind  that the  primary tool
    that the  browser has  to work  with is  "gethostbyname" -  which,
    doesn't  return  enough  information   about  how  the  name   was
    resolved  to  be  helpful  for  security  purposes (even though it
    garnered some  in the  process of  resolution).   For example,  it
    doesn't say whether /etc/hosts or LMHOSTS was used to resolve  the
    name, or which DNS search suffix was used.