COMMAND

    Internet Explorer

SYSTEMS AFFECTED

    Win systems with IE5

PROBLEM

    J.Kent  Robinson  found  following.   He  was  running IIS4 on NT4
    (SP5) server.  Several web pages had permissions assigned with  NT
    ACL (both  NT Challege/Response  and Basic  Authentication).  Kent
    discovered  that  protected  pages  can  be viewed by unauthorized
    user  (presumably  from  cache)  if  authorized  user   previously
    accessed  pages  from  same  computer  client.   This happens even
    after the browser has been completely closed and then reopened.

    An unauthorized user accesses the  page by hitting the page  link.
    This brings up the pop-up logon window.  Hit cancel.  User gets  a
    401 screen.  Hit the back button.  Hit the forward button.  Viola.
    The user without credentials has access to the protected  content.
    This was tested on NT4 WS, Win98 and Win2000 clients with the same
    results.

    Speking  of  that,  Justin  King  added  following.   In  Internet
    Explorer (v5/nt,v4/nt,v5/win98),  when you  go to  a website (say,
    www.company.com),  and  it   requests  authorization  (via   basic
    authentication), and you enter it, you're able to browse the  rest
    of the site without reentering my password on each page.  This  is
    fine.  However, if you go to another website on the same  machine,
    but a different port (say, www.company.com:81), you authentication
    information is still sent.  This  seem to be a security flaw  with
    the browser.

    Quoting RFC2617, Page 3:

        "The realm  directive (case-insensitive)  is required  for all
        authentication schemes that issue a challenge. The realm value
        (case-sensitive), in combination  with the canonical  root URL
        (the absoluteURI for the  server whose abs_path is  empty; see
        section 5.1.2 of  [2]) of the  server being accessed,  defines
        the  protection  space.   These  realms  allow  the  protected
        resources  on  a  server  to  be  partitioned  into  a  set of
        protection  spaces,  each  with  its own authentication scheme
        and/or authorization database."

    Note that  the client  must use  the combination  of the canonical
    root URL and the real value to decided if the protection space  is
    the same.  The canonical  root URL  of a  server in  port 80 and a
    server in some other port will be different (http://www.foo.com:80
    vs  http://www.foo.com:81/),  so  they  indeed represent different
    protection spaces and IE is sending the authentication messages in
    error.

SOLUTION

    If you care  about this, clear  your cache.   A user could  simply
    open the page directly out of the cache.  Or a user could mail the
    contents of the cache out.   Bottom line, you cannot protect  data
    on your hard drive from people with physical access to it.   Don't
    walk away from a computer that has sensitive data on it if  anyone
    who shouldn't  be reading  that data  has physical  access to  the
    computer.

    The IE  cache in  Windows NT  is per-user,  and ACLd  so only that
    user has  access.   From description  above, it  appears that  the
    "unauthorized"  user  was  running  using  the same account in the
    same logon session as the "authorized" user. (Closing the  browser
    and  reopening  it  doesn't  count.)   So,  as  far  as  the OS is
    concerned, it's the  same user, and  both are equally  authorized.
    Logout and log back in as  a different user.  (There is  an option
    to tell  IE to  clear the  cache after  the browser  closes.   But
    nothing short of logout is spec'd to work completely.)