Hi Ken / All,

I have been looking into this bulletin and the fix, and I still have a
question about it.

It seems that this fix solves a problem when you go from an unsecure to a
secure site and then back again. During the unsecure section, one could be

able to catch the cookie, and use that to enter the secure session again
(under some extreme circumstances, but still, it IS possible)

However, in our situation, it is the other way around. A user visits a non

secure section and then logs in through SSL. In the SSL section, he gets
the same cookie as in the non secure section. Only when I have my SSL site

run in its own memory space, a new cookie is handed out. This is what MSFT

states the following:

<snip>
Does this mean that all secure web sites that use .ASP are at risk?
No. Best practices recommend that web sites use different Session IDs for
secure and non-secure pages. Sites that follow this guidance would not be
at risk from the vulnerability, because there would be two different
Session ID cookies =96 one used by the secure web pages, and one used by the

non-secure ones. The Session ID cookie for non-secure pages would travel in

plain text and could be intercepted, but could only be used to =93hijack=94
 a
non-secure web page, which is always possible.
</snip>

Does this mean that just before I enter a SSL section, I should call a
Session.Abandon to destroy my old session, and get a new Session ID for the

secure part? I have tried that, but found that every now and then I still
end up with the same cookie. I tried to look for some "Best practices" but

couldn't find much on this subject. I am a bit confused now how to handle
 this.

Any ideas??


Thanks in advance,


Imar




At 10:49 AM 2/23/2001 +1100, you wrote:

> > Thank you for your reply. I had read about the patch in a KB article,
 but
> > misunderstood the problem it solved. Therefore, I didn't investigate it
>any
> > further.
> > But this looks very promising. I think I need to subscribe myself to the
> > Security Bulletin ;-)
>
>The problem with the security bulletin is:
>a) It's hard keeping track of everything, because they just have numbers to
>separate them
>b) Microsoft never really explains how the vulnerability can be exploited,
>and what the effect of such an exploit is...
>
>I've found NTBugtraq (www.NTBugTraq.com) to be a more useful list for
>getting the low down on the actual vulnerability and keeping the MS
 Security
>bulletins just for the URLs for fixes.
>
>Cheers
>Ken