Haha, no problem. I think the subject is difficult and widespread enough to 
make it hard to see it all at once.

I am indeed saying that no matter how many virtual applications I use, the 
same sessionID is used. Since I applied that patch, a new ID is handed out 
when you go from SSL to insecure, but the other way around is still not 
covered.
The link you provided is indeed the patch I was talking about.

To wrap up this thread, I'll try to summarize what I am going to propose 
for this project:

1. Make the insecure session completely session-stateless. That is, all 
shopping cart stuff should be saved in the database, and the only thing 
that identifies the surfer is an (encrypted) shopping cart ID.
2. When a user wants to check-out, he moves to the SSL section. At that 
moment, an IIS SessionID-cookie is handed out to identify the user in the 
session. The user logs in, and "hands over" his shopping cart ID. If the 
user is validated, a session variable will be set to be able to remember 
the user.
Even if a malicious user is able to hijack the session, all he would get is 
a shopping cart.
3. As Ken suggested, sensitive information should be saved in the correct 
order (address data before credit card info) and a user should not be able 
to retrieve or alter this info anymore.
That way, when you actually want to buy your stuff, you would have to 
provide your critical data again.

I want to thank everyone who contributed to this interesting thread for 
your valuable insights.

Imar


At 10:01 AM 3/9/2001 -0500, you wrote:
>okay I'm sorry I didn't understand fully.  If I was a better communicator I
>wouldn't be sitting here programming I'd be telling other what to do :)
>
>So, your saying that no matter how many virtual applications that are on a
>single IIS web server they all use the same session id number?
>
>-----Original Message-----
>From: Imar Spaanjaars [mailto:e_mar@y...]
>Sent: Friday, March 09, 2001 9:24 AM
>To: Security_asp
>Subject: RE: ASP Session ID and SSL - Again (Long)
>
>
>I am afraid I haven't made myself very clear yet, but
>the SSL app is already a VIRTUAL APPLICATION.
>
>And indeed, IIS SHOULD create another session ID
>because it thinks it is another application. This is
>the crux of the whole situation: it SHOULD do that,
>but it doesn't. I thought I had explained this already
>a couple of times, but apparently I cannot clarify the
>situation enough. (Or maybe your rephrase was too
>short, and my long story was really necessary ;-)).
>
>Out-of-process refers to the way IIS is setup. For
>each "out-of-process" site, IIS will launch a new
>process, therefore separating the various sites from
>each other. This means that if site1 goes down,
>because of overload, bugs, whatever, site2 and IIS can
>still survive. MS has written quite a lot about this
>subject, for example at:
>http://msdn.microsoft.com/library/periodic/period97/IIs40.htm
>(very old, but it discusses some important basics).
>However, running a website in a different process than
>IIS itself, will cause various problems related to
>security because not everything is done under the
>alias of IUSR_MachineName.
>A couple of the side-effects of running a website
>out-of-process are considered bugs (the fact that you
>can't send mail through CDO with the build in SMTP
>server is one of them) and may be solved with patches
>and hotfixes.
>
>But again, this is rather not where I am after. If I
>can force IIS to hand out a new SessionID for EACH
>APPLICATION my problems are solved, without having to
>rely on tons of patches and other unforeseen problems.
>
>Imar