Change ASPSessionID

[Roland Hall]

in message
: alert (document.cookie);
:
: works if I remember correctly. The cookie can be set in similar
: fashion (eg) using a js bookmarklet. Since you would then have the
: "correct" SessionId why couldn't you access the other session?

You remember correctly but it gives you access to YOUR session ID, not
someone else's Is it possible that you could be compromised and an attacker
could get this info? Sure, it's possible but if that is the case, they
don't need your session ID, they'll just install a keylogger and call it a
day.

Could a man in the middle attack exploit this? Sure but critical
information is generally transmitted encrypted using SSL so the man in the
middle doesn't get anything. Even if you had an encrypted connection, if
your system is compromised it doesn't matter what you security measures are
between you and the web site. At that point the game's over.

--
Roland Hall
/* This information is distributed in the hope that it will be useful, but
without any warranty; without even the implied warranty of merchantability
or fitness for a particular purpose. */
Technet Script Center - http://www.microsoft.com/technet/scriptcenter/
WSH 5.6 Documentation - http://msdn.microsoft.com/downloads/list/webdev.asp
MSDN Library - http://msdn.microsoft.com/library/default.asp

 

[tom_shoelace]

I am not sure I understand how you expect a user on PC2 to be able to
install some javascript bookmarklet thing on PC1 or on your server in order
to find out his sessionID. If the user of PC2 has access to PC1, couldn't
he just use that access to find out the user's password (which he probably
has in a file somewhere, or on a sticky note on his monitor) or just take
over his session from there? There is nothing you can do in ASP to make a
user's workstation more secure. Of course it's easy to emulate this when
you're in control of both PC1 and PC2, as well as the web server. I don't
think it's even remotely likely in the real world. But I can't tell you
what to focus your energy on.

I agree with Aaron.

If a third party can get the ASPSessionid, then they can get a second
one later, or a third, and so on. Also if a third party can get the
ASPSessionid, then they can also get a cookie or any other saved item
on the client. All data passes through the browser and is visible
there.

Your question can be paraphrased as

"How do I transfer data to the user without
passing it through a client browser where
my mysterious secrets will be compromised."

This makes no sense: you're chasing your own ignorance but it has
outsmarted you. You are like the man who tries to catch a fart in a
butterfly net.

 

[Tim Williams]

I'm "mostly correct" ? I think just "correct" would do fine. PC2
does not "get to the protected page of PC1" - it can access any
protected page *on the server*, but has no access to PC1 at all.

Maybe my original summary was unclear....

Tim.

 

[Roland Hall]

This makes no sense: you're chasing your own ignorance but it has
: outsmarted you. You are like the man who tries to catch a fart in a
: butterfly net.

(O:=

--
Roland Hall
/* This information is distributed in the hope that it will be useful, but
without any warranty; without even the implied warranty of merchantability
or fitness for a particular purpose. */
Technet Script Center - http://www.microsoft.com/technet/scriptcenter/
WSH 5.6 Documentation - http://msdn.microsoft.com/downloads/list/webdev.asp
MSDN Library - http://msdn.microsoft.com/library/default.asp

 

[Roland Hall]

in message
: I'm "mostly correct" ? I think just "correct" would do fine. PC2
: does not "get to the protected page of PC1" - it can access any
: protected page *on the server*, but has no access to PC1 at all.
:
: Maybe my original summary was unclear....

Nah, everything you've said is. This is where the term script kiddie comes
from.

--
Roland Hall
/* This information is distributed in the hope that it will be useful, but
without any warranty; without even the implied warranty of merchantability
or fitness for a particular purpose. */
Technet Script Center - http://www.microsoft.com/technet/scriptcenter/
WSH 5.6 Documentation - http://msdn.microsoft.com/downloads/list/webdev.asp
MSDN Library - http://msdn.microsoft.com/library/default.asp

 

[Michael D. Kersey]

Tim Williams wrote:

Easy to prevent just by adding another session cookie on login and
checking for both that *and* the session variable, rather than relying
only on the session variable.
Tim.

But it can't be just _any_ cookie! We must test the _contents_ of the
cookie and not merely its presence.

The cookie's contents should not be predictable by the attacker. Storing
the username or SSN in a cookie would be ineffective because an attacker
(who already has my ASPSessionID) might then easily mimic my cookie too.

And the serverside code must check the cookie's contents on each page.
So the cookie value must also be stored somewhere on the server (Session
variable, database, file, or Application variable(s), etc.).

So it seems a relatively easy method to thwart the "session fixation
attack" would be, immediately after the user is authenticated, to
- set a cookie to some random value XXXXX,
- set a Session variable to the same value XXXXX,
[From a security standpoint, the cookie is a "client key" and the
Session variable is a "server key"]. Then, on every page, check that the
cookie and Session variable match.

Kudos
- to Joseph Shoe (Joe Hsu) for bringing this problem to the table and
- to Tim for presenting tools and ways to manifest the problem
and to both of you for showing how to solve the problem:
I found no mention of session fixation attacks on the Microsoft
newsgroups prior to Joseph's. Nor could a quick search find anything on
Microsoft's site.

Here's a discussion, with diagrams, of the "session fixation attack":
http://shiflett.org/articles/security-corner-feb2004

I am curious whether ASP.NET is vulnerable to this attack.

Google search shows that knowledge about such attacks has been present
since at least 2001. http://www.tisc2001.com/newsletters/53.html
shows how a session fixation attack is set up [hint: the scenario we've
been discussing isn't the important one]. I don't believe that this
older paper explicitly considers the case of a legitimate user who
wishes to mimic another legitimate user and thereby gain illegitimate
access. And here's an update and PDF paper by the same authors:
http://www.acrossecurity.com/papers.htm

Here's another article:
http://archives.neohapsis.com/archives/ntbugtraq/2002-q4/0117.html

IMO this "session fixation attack" is both interesting and a serious
problem for ASP applications. It seems especially pertinent to intranets
where secure information is maintained internally and where security
must not be breached. That is the most common scenario for stealing
information.

We need to talk about this more.

 

[Tim Williams]

Michael,

Thanks for the links. This was not something I was aware of until
this thread, so it's been a useful exercise all round.

Off to read your references....

Cheers,
Tim

Tim Williams wrote:

Easy to prevent just by adding another session cookie on login and
checking for both that *and* the session variable, rather than
relying only on the session variable.
Tim.

But it can't be just _any_ cookie! We must test the _contents_ of
the cookie and not merely its presence.

The cookie's contents should not be predictable by the attacker.
Storing the username or SSN in a cookie would be ineffective because
an attacker (who already has my ASPSessionID) might then easily
mimic my cookie too.

And the serverside code must check the cookie's contents on each
page. So the cookie value must also be stored somewhere on the
server (Session variable, database, file, or Application
variable(s), etc.).

So it seems a relatively easy method to thwart the "session fixation
attack" would be, immediately after the user is authenticated, to
- set a cookie to some random value XXXXX,
- set a Session variable to the same value XXXXX,
[From a security standpoint, the cookie is a "client key" and the
Session variable is a "server key"]. Then, on every page, check that
the cookie and Session variable match.

Kudos
- to Joseph Shoe (Joe Hsu) for bringing this problem to the table
and
- to Tim for presenting tools and ways to manifest the problem
and to both of you for showing how to solve the problem:
I found no mention of session fixation attacks on the Microsoft
newsgroups prior to Joseph's. Nor could a quick search find anything
on Microsoft's site.

Here's a discussion, with diagrams, of the "session fixation
attack":
http://shiflett.org/articles/security-corner-feb2004

I am curious whether ASP.NET is vulnerable to this attack.

Google search shows that knowledge about such attacks has been
present since at least 2001.
http://www.tisc2001.com/newsletters/53.html
shows how a session fixation attack is set up [hint: the scenario
we've been discussing isn't the important one]. I don't believe that
this older paper explicitly considers the case of a legitimate user
who wishes to mimic another legitimate user and thereby gain
illegitimate access. And here's an update and PDF paper by the same
authors:
http://www.acrossecurity.com/papers.htm

Here's another article:
http://archives.neohapsis.com/archives/ntbugtraq/2002-q4/0117.html

IMO this "session fixation attack" is both interesting and a serious
problem for ASP applications. It seems especially pertinent to
intranets where secure information is maintained internally and
where security must not be breached. That is the most common
scenario for stealing information.

We need to talk about this more.