ASP and Session Variables

[Bill]

I've noticed that in my ASP application that session variables are not carried over from
one IE6 open browser window to another.

Can anyone tell me how IE can do this? It seems like it's a useful protection mechanism
that I can add to my application.

BTW, I'm looking for a way to determine if someone is moving cookies between computers.
How IE and/or ASP handles sessions might give me some insights (and I'm open to
suggestions as to how to prevent cookie stealing?)

Thanks,

Bill.

[Evertjan.]

<WARNING: THIS IS THE REAL THING, not an april fools day drill>

Bill wrote on 01 apr 2006 in microsoft.publi c.inetserver.as p.general:

I've noticed that in my ASP application that session variables are not
carried over from one IE6 open browser window to another.

Can anyone tell me how IE can do this? It seems like it's a useful
protection mechanism that I can add to my application.
Session variables [in the ASP sense] are strictly serverside values, and
are only accessable thue asp. To get them into the html steam by value,
do:

<br>my height is : <%=myHeight %> cm<br>

The browser knows nothing about those session variables.

The only thing that the browser does is store the session-id as a "ram-
cookie" [= a cookie without a set expiration date+time] to identify the
session to the server.
BTW, I'm looking for a way to determine if someone is moving cookies
between computers.
Never met one. This seems another subject, so preferably you would start
a new thread.
How IE and/or ASP handles sessions might give me
some insights
See above. The session in this sense only has meaning on the server.
(and I'm open to suggestions as to how to prevent cookie
stealing?)

ask: <http://tinyurl.com/s5l2s>

=============== =====

BTW: client side there is also a session in a sense, meaning the time
during which the browser is "on" and retains it's ram-cookies, that
therefore rather confusingly are called session-cookies. There is no
connection between these two things called session, except that the end
of this "client-session" unmistakenly ends the session-id of the asp
server session.

--
Evertjan.
The Netherlands.
(Please change the x'es to dots in my emailaddress)

[Bob Barrows [MVP]]

Bill wrote:

I've noticed that in my ASP application that session variables are
not carried over from one IE6 open browser window to another.

I have not noticed that. In fact, I've noticed that I have to close all
browser windows in order to force a new session to be started on my machine.
Can anyone tell me how IE can do this? It seems like it's a useful
protection mechanism that I can add to my application.

BTW, I'm looking for a way to determine if someone is moving cookies
between computers. How IE and/or ASP handles sessions might give me
some insights (and I'm open to suggestions as to how to prevent
cookie stealing?)

You may be thinking of cross-site scriipting (XSS). There was a XSS
vulnerability in HotMail that allowed a users .Net Passport session cookies
to be stolen (that vulnerability has since been plugged). There are a few
good links about that via Google:
http://www.google.com/search?hl=en&q...ipting&spell=1

For other ways:
http://www.google.com/search?hl=en&lr=&q=steal+cookies
--
Microsoft MVP - ASP/ASP.NET
Please reply to the newsgroup. This email account is my spam trap so I
don't check it very often. If you must reply off-line, then remove the
"NO SPAM"

[Dave Anderson]

"Bob Barrows [MVP]" wrote:

I have not noticed that. In fact, I've noticed that I have to
close all browser windows in order to force a new session to
be started on my machine.

Then I suggest you have not looked very hard, Bob. This is hinted at here...
http://aspfaq.com/show.asp?id=2157

....and easy to confirm for yourself. Create a script that does nothing more
than display the session ID. Browse to it with IE. Open another instance of
IE FROM WINDOWS (Start:Run:iexp lore.exe) and see your new session ID. Open a
new window FROM IE (CTRL+N) and see the shared session ID.

--
Dave Anderson

Unsolicited commercial email will be read at a cost of $500 per message. Use
of this email address implies consent to these terms. Please do not contact
me directly or ask me to contact you directly for assistance. If your
question is worth asking, it's worth posting.

[Bob Barrows [MVP]]

Dave Anderson wrote:

"Bob Barrows [MVP]" wrote:

I have not noticed that. In fact, I've noticed that I have to
close all browser windows in order to force a new session to
be started on my machine.

Then I suggest you have not looked very hard, Bob. This is hinted at
here... http://aspfaq.com/show.asp?id=2157

...and easy to confirm for yourself. Create a script that does
nothing more than display the session ID. Browse to it with IE. Open
another instance of IE FROM WINDOWS (Start:Run:iexp lore.exe) and see
your new session ID. Open a new window FROM IE (CTRL+N) and see the
shared session ID.

Exactly. That's what I'm talking about. All pages have to be closed before a
new session id is created. The OP was saying that he noticed the opposite
occurring ,,, I think ... let me check ... right, he said " ... session
variables are not carried over from one IE6 open browser window to another
.... ". I have never seen this behavior.

--
Microsoft MVP - ASP/ASP.NET
Please reply to the newsgroup. This email account is my spam trap so I
don't check it very often. If you must reply off-line, then remove the
"NO SPAM"

[Dave Anderson]

"Bob Barrows [MVP]" wrote:

Create a script that does nothing more than display the
session ID. Browse to it with IE. Open another instance
of IE FROM WINDOWS (Start:Run:iexp lore.exe) and see your
new session ID. Open a new window FROM IE (CTRL+N) and
see the shared session ID.
Exactly. That's what I'm talking about. All pages have to
be closed before a new session id is created.

Uh - you seem to have read what I wrote to mean the opposite of what I
intended. Read it again, but pretend I did not forget to mention that you
should leave all windows open as you proceed. Two of the windows will share
a session ID, while the third will have its own.

" ... session variables are not carried over from one IE6
open browser window to another ... ". I have never seen
this behavior.

Looking back at the link I posted, note:

3. Check that you aren't expecting to maintain session
variables across:

* Browser windows (see Article #2172)
* Framesets (see KB #178037 and KB #323752)
* etc.

This is a well-known and long-standing problem with IE. I have observed
instances where users could affect the session behavior (between popup
windows and their openers) by changing the number of applications running on
the client machine[1].

What's especially troubling about this setting is that it affects *all*
transient cookies, not just ASP session ones. This is a real pain in the
posterior, IMO. The least Microsoft could have done when implementing[2]
this is give the developer a means (like a switch in the window.open
parameters) to explicitly choose one way or the other.
-
[1] No kidding. My best guess for the reason is that IE chooses when to use
the "browse new windows in a separate process" setting based on local
resources. KB 240928 says this is a function of physical RAM, but I have
observed differently.

[2] I prefer "thrusting upon us" to "implementi ng", in this case.
--
Dave Anderson

Unsolicited commercial email will be read at a cost of $500 per message. Use
of this email address implies consent to these terms. Please do not contact
me directly or ask me to contact you directly for assistance. If your
question is worth asking, it's worth posting.

[Anthony Jones]

"Dave Anderson" <GT**********@s pammotel.com> wrote in message
news:12******** *****@corp.supe rnews.com...

"Bob Barrows [MVP]" wrote:

Create a script that does nothing more than display the
session ID. Browse to it with IE. Open another instance
of IE FROM WINDOWS (Start:Run:iexp lore.exe) and see your
new session ID. Open a new window FROM IE (CTRL+N) and
see the shared session ID.
Exactly. That's what I'm talking about. All pages have to
be closed before a new session id is created.

Uh - you seem to have read what I wrote to mean the opposite of what I
intended. Read it again, but pretend I did not forget to mention that you
should leave all windows open as you proceed. Two of the windows will

share a session ID, while the third will have its own.

" ... session variables are not carried over from one IE6
open browser window to another ... ". I have never seen
this behavior.
Looking back at the link I posted, note:

3. Check that you aren't expecting to maintain session
variables across:

* Browser windows (see Article #2172)
* Framesets (see KB #178037 and KB #323752)
* etc.

This is a well-known and long-standing problem with IE. I have observed
instances where users could affect the session behavior (between popup
windows and their openers) by changing the number of applications running

on the client machine[1].

What's especially troubling about this setting is that it affects *all*
transient cookies, not just ASP session ones. This is a real pain in the
posterior, IMO. The least Microsoft could have done when implementing[2]
this is give the developer a means (like a switch in the window.open
parameters) to explicitly choose one way or the other.
-
[1] No kidding. My best guess for the reason is that IE chooses when to use the "browse new windows in a separate process" setting based on local
resources. KB 240928 says this is a function of physical RAM, but I have
observed differently.

[2] I prefer "thrusting upon us" to "implementi ng", in this case.
--
Dave Anderson

Unsolicited commercial email will be read at a cost of $500 per message. Use of this email address implies consent to these terms. Please do not contact me directly or ask me to contact you directly for assistance. If your
question is worth asking, it's worth posting.

Dave,

I have to admit I believe I have observed this problem myself. However all
attempts at a reproduction have failed. The scenario most commonly reported
to me by clients is this. IE browser window opened on an intranet site
which requires a login. An email with a link to a page on the same intranet
site is clicked but the user is asked to login. User posts a support call
to effect they have already logged in why to they need to do it again?

I then attempt to reproduce and am unable to repeatable produce it, although
I have occasionally seen it myself.

Most of the articles you refer to a pretty out of date, refering to IE 4 and
5. The bugs mentioned have been fixed since 5.5. For example the 'open in
new process' setting is now set when 'there is more than 32MB of RAM' which
today means it's always set. But it's referring to launching from shell not
when opening a new window from a link in an existing browser window or from
script running in IE.

The only current article (by that I mean one affecting IE6) refers to
framesets using different host paths which quite rightly will not forward
the sessionID cookie.

Ultimately I suspect the problems I have seen are a result of using
different names to access the same server (that the intranet is access using
host name only but the email contains FQDNs)

Anthony.

[Dave Anderson]

Anthony Jones wrote:

I have to admit I believe I have observed this problem myself.
However all attempts at a reproduction have failed. The scenario
most commonly reported to me by clients is this. IE browser window
opened on an intranet site which requires a login. An email with a
link to a page on the same intranet site is clicked but the user is
asked to login. User posts a support call to effect they have
already logged in why to they need to do it again?

I then attempt to reproduce and am unable to repeatable produce it,
although I have occasionally seen it myself.

Most of the articles you refer to a pretty out of date, refering to
IE 4 and 5. The bugs mentioned have been fixed since 5.5. For example
the 'open in new process' setting is now set when 'there is more than
32MB of RAM' which today means it's always set. But it's referring to
launching from shell not when opening a new window from a link in an
existing browser window or from script running in IE.
I am aware of all of these points. It occurred to me that the KB is not
fessing up completely, however. Witness the fact that I have observed
behavioral changes based on the number of running apps and windows opened by
the browser (not the shell). This suggests (1) that the "browse in a new
process" setting looks at available memory rather than physical memory, and
(2) that the issue is broader than suggested in the article.
The only current article (by that I mean one affecting IE6) refers
to framesets using different host paths which quite rightly will not
forward the sessionID cookie.

Ultimately I suspect the problems I have seen are a result of using
different names to access the same server (that the intranet is
access using host name only but the email contains FQDNs)

If this is a problem on your intranet, you may improve things by making sure
the clients have you in their [Trusted Sites] zones. On your public site,
P3P headers may help.

I say "may" in both cases because it helped us, but I can find no MSDN
explanation for it. MSDN has a lot to say about cookies and P3P, but nothing
about sharing cookies between browser windows.

--
Dave Anderson

Unsolicited commercial email will be read at a cost of $500 per message. Use
of this email address implies consent to these terms. Please do not contact
me directly or ask me to contact you directly for assistance. If your
question is worth asking, it's worth posting.