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.public.inetserver.asp.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.

 

[Bob Barrows [MVP]]

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=Cross-site+Scripting&spell=1

For other ways:
http://www.google.com/search?hl=en&lr=&q=steal+cookies

 

[Bob Barrows [MVP]]

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:iexplore.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.

 

[Anthony Jones]

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 "implementing", 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.