RE: Possible IE 6 Bug - Differences Between Windows Explorer And IE

From: Jim Cheshire [MSFT] (jamesche_at_online.microsoft.com)
Date: 04/16/04 

Date: Fri, 16 Apr 2004 19:46:00 GMT

Hi Kevin,

This is not a bug in any version of the browser. This is by-design. One
process cannot access the memory for another process. As you have seen,
when you browse a URL via a Windows Explorer window, it will browse that
URL via the explorer.exe process. If you then open a new window, it will
launch a new iexplore.exe process, and that iexplore.exe process cannot
access the memory space for the explorer.exe process.

There is a way that you can force the process to not cache credentials in
this scenario. Open an Explorer window and click on Tools, Folder Options.
 Click the View tab and select the option to "Launch folder windows in a
separate process." After you check that, restart the computer. Now
credentials will no longer be cached after the Windows Explorer window is
closed and a new one opened.

Jim Cheshire, MCSE, MCSD [MSFT]
ASP.NET
Developer Support
jamesche@online.microsoft.com

This post is provided "AS-IS" with no warranties and confers no rights.

--------------------
>From: mrkwatkins@hotmail.com (Kevin Watkins)
>Newsgroups:
microsoft.public.internet.explorer.ieak,microsoft.public.dotnet.framework.as
pnet.security,microsoft.public.dotnet.security
>Subject: Possible IE 6 Bug - Differences Between Windows Explorer And IE
>Date: 16 Apr 2004 10:43:23 -0700
>Organization: http://groups.google.com
>Lines: 75
>Message-ID: <2ec204be.0404160943.7858f2ca@posting.google.com>
>NNTP-Posting-Host: 81.133.246.107
>Content-Type: text/plain; charset=ISO-8859-1
>Content-Transfer-Encoding: 8bit
>X-Trace: posting.google.com 1082137403 2791 127.0.0.1 (16 Apr 2004
17:43:23 GMT)
>X-Complaints-To: groups-abuse@google.com
>NNTP-Posting-Date: Fri, 16 Apr 2004 17:43:23 +0000 (UTC)
>Path:
cpmsftngxa06.phx.gbl!TK2MSFTNGP08.phx.gbl!newsfeed00.sul.t-online.de!t-onlin
e.de!news.glorb.com!postnews1.google.com!not-for-mail
>Xref: cpmsftngxa06.phx.gbl
microsoft.public.dotnet.framework.aspnet.security:9663
microsoft.public.dotnet.security:5748
microsoft.public.internet.explorer.ieak:13152
>X-Tomcat-NG: microsoft.public.dotnet.framework.aspnet.security
>
>Hi,
>
>Apologies for cross posting like this, but I wasn't sure on the best
>group to post to and I didn't receive much of a response to my
>original email in microsoft.public.dotnet.framework.aspnet.security.
>My application currently has a rather large security hole in it which
>I need help with as soon as possible.
>
>My original post can be found at
>http://groups.google.co.uk/groups?hl=en&lr=&ie=UTF-8&selm=2ec204be.04040510
28.1275a59b%40posting.google.com
>
>Basically the problem is a difference in behaviour between going to a
>URL by loading up IE via its icon, and by going to a URL by typing it
>into the Windows Explorer address bar.
>
>My application uses ASP.NET. It records information in the Session
>variable and uses forms authentication to log in. The code for a
>simple test application to demonstrate all this is included in my
>original post.
>
>Firstly I go to my app by loading up IE by clicking its icon then
>entering the URL in the address bar. I log in, then close the browser
>window. If I then open a new instance of IE in the same way and go
>back to the site I am logged out as you'd expect, because my session
>has ended. Everything works correctly and I'm a happy bunny.
>
>However, if I enter the URL into the address bar of a Windows Explorer
>window (E.g. double click on 'My Computer' and use the window that
>comes up) my site displays in the window. I log in, then close the
>window. If I then enter the URL into another Windows Explorer address
>bar, I haven't been logged out. My session remains and my forms
>authentication still holds.
>
>Looking into this further, I believe this is due to session cookies
>being held in memory. When I load up IE I get an iexplore.exe process
>showing in task manager. Presumably the session cookies are held in
>the memory space of this process, so when I close my IE window, the
>process ends, the cookies are destroyed and my session/authentication
>is therefore lost.
>
>However, when I enter the URL into Windows Explorer, it does not
>launch an iexplore.exe process. I'm therefore guessing that the
>session cookies are held in the memory space of explorer.exe. As this
>process never ends, the session cookies never die and my
>session/authentication information is never lost.
>
>In a related issue, if I open a popup using JavaScript from my site
>when it has been accessed via Windows Explorer, an iexplore.exe
>process is launched for the new window. The session/authentication
>information is not carried through to this new window, I'm guessing
>because the in memory cookies aren't copied to the new process.
>
>Now I hope I'm being a muppet and have not set up something correctly
>in ASP.NET or IIS. I tried setting the cookieless property in the
>sessionState node in Web.Config to true, but still had the problem. I
>have tested the website locally and on three different remote servers.
>I have tested this on XP and 2000 running IE6, and on 2000 running
>IE5.5. The bug only seems to happen under IE5.5, which makes me think
>it might be a bug in IE 6.
>
>Has anyone experienced anything similar? I would be grateful for any
>help in solving this problem, as currently I have a big security hole.
>If a user enters my site via Windows Explorer and then doesn't log
>out, then another user could come along, use their PC, go to my site
>via Windows Explorer and obtain the previous user's access rights.
>
>I currently have a JavaScript onunload to log the user out if the
>window closes, but this is not 100% perfect and is certainly not
>ideal! So any help would be really appreciated!!!
>
>Thanks,
>
>Kev
>
>mrkwatkins@hotmail.com
>

Relevant Pages

  • Possible IE 6 Bug - Differences Between Windows Explorer And IE
    ... It records information in the Session ... if I enter the URL into the address bar of a Windows Explorer ... window (E.g. double click on 'My Computer' and use the window that ... I believe this is due to session cookies ...
    (microsoft.public.internet.explorer.ieak)
  • Possible IE 6 Bug - Differences Between Windows Explorer And IE
    ... It records information in the Session ... if I enter the URL into the address bar of a Windows Explorer ... window (E.g. double click on 'My Computer' and use the window that ... I believe this is due to session cookies ...
    (microsoft.public.dotnet.security)
  • Possible IE 6 Bug - Differences Between Windows Explorer And IE
    ... It records information in the Session ... if I enter the URL into the address bar of a Windows Explorer ... window (E.g. double click on 'My Computer' and use the window that ... I believe this is due to session cookies ...
    (microsoft.public.dotnet.framework.aspnet.security)
  • Re: [kde] I just noticed: no more crashes! Thanks, KDE team!
    ... ensuring that minimize memory either never, or for file browsing only, ... is selected, and always use a separate window for online banking, so ... a vuln in from a different site open in another window, ... root session as long as it's running in the same X session, ...
    (KDE)
  • RE: How to create a local server (i.e., localhost)
    ... logon user session and hard to automate in a non-interactive service ... Since the webserver.exe is a winform application which has a main window, ... already running on a given port? ...
    (microsoft.public.dotnet.languages.vb)