How do you change the ASPSessionID during a web session? I have an ASP
application in SSL. The first screen is a login screen, which requests user
id and password. An ASPSessionID is assigned for this page. Once the user
is authenticated by valid id/pwd, the second page starts the real
applicaiton. I want to change the ASPSessionID to be different from the
first login page, which was issued to an unauthenticated user. How do I do
that in ASP?
Thanks.
Joseph
27  12223 
The sessionID is like a surrogate key, its value has no real meaning and I
have no idea why you need them to be different.
"Joseph Shoe" <Joseph Sh**@discussions.microsoft.com> wrote in message
news:AC**********************************@microsof t.com... How do you change the ASPSessionID during a web session? I have an ASP
application in SSL. The first screen is a login screen, which requests
user
id and password. An ASPSessionID is assigned for this page. Once the
user
is authenticated by valid id/pwd, the second page starts the real
applicaiton. I want to change the ASPSessionID to be different from the
first login page, which was issued to an unauthenticated user. How do I
do
that in ASP?
Thanks.
Joseph
ASP maintains the same sessionID for the duration of a session, whether the
user has passed the authentication. The sessionID can be used by someone to
gain access to the part of a sessoin that is considered authenticated, i.e.,
session fixation attachs.
It is a good practice that the server changes the session ID after a user is
sucessfully authenticated.
"Aaron Bertrand [SQL Server MVP]" wrote: The sessionID is like a surrogate key, its value has no real meaning and I
have no idea why you need them to be different.
"Joseph Shoe" <Joseph Sh**@discussions.microsoft.com> wrote in message
news:AC**********************************@microsof t.com... How do you change the ASPSessionID during a web session? I have an ASP
application in SSL. The first screen is a login screen, which requests
user
id and password. An ASPSessionID is assigned for this page. Once the
user
is authenticated by valid id/pwd, the second page starts the real
applicaiton. I want to change the ASPSessionID to be different from the
first login page, which was issued to an unauthenticated user. How do I
do
that in ASP?
Thanks.
Joseph
> session fixation attachs.
I have no idea what this is. But have you ever tried to fake out or
impersonate a session? It is a good practice that the server changes the session ID after a user
is
sucessfully authenticated.
So the user changes to some other SessionID. Whoopty-doo. If a malicious
user has the ability to impersonate a specific sessionID then certainly they
would be able to impersonate an "authenticated" one.
How and why are you relying on sessionID to allow access to certain parts of
the application? Why not a variable like Session("authenticated")?
It is session fixation attacKs. Sorry for the typo.
"If a malicious user has the ability to impersonate a specific sessionID
then certainly they would be able to impersonate an "authenticated" one."
Not necessary, if the sessionID is changed for the authenticated part of the
session.
"How and why are you relying on sessionID to allow access to certain parts
of the application?" I don't, ASP does. I'm hoping to find an ASP
function call that allows me to change the value of ASPSessionID.
"Aaron Bertrand [SQL Server MVP]" <te*****@dnartreb.noraa> wrote in message
news:O3*************@TK2MSFTNGP09.phx.gbl... session fixation attachs.
I have no idea what this is. But have you ever tried to fake out or
impersonate a session?
It is a good practice that the server changes the session ID after a user
is
sucessfully authenticated.
So the user changes to some other SessionID. Whoopty-doo. If a malicious
user has the ability to impersonate a specific sessionID then certainly
they would be able to impersonate an "authenticated" one.
How and why are you relying on sessionID to allow access to certain parts
of the application? Why not a variable like Session("authenticated")?
> Not necessary, if the sessionID is changed for the authenticated part of the session.
Sorry, but I have been working with ASP for 10 years, and this still does
not make any sense to me.
"How and why are you relying on sessionID to allow access to certain parts
of the application?" I don't, ASP does.
How does ASP in and of itself know absolutely anything about different parts
of your application?
I'm hoping to find an ASP function call that allows me to change the value
of ASPSessionID.
Sorry, this is read only. Even if you could change it, I am still 100%
unclear as to what you would have hoped to accomplish.
I think what Aaron was saying is that if a hacker can grab the
"unauthenticated" session id and impersonate a session then they would be
able to grab the "authenticated" one as well. What are you doing to protect
the "authenticated" id that you cannot do for the "unauthenticated" one?
As far as I know, the only way that a session id changes is if the client's
browser is closed and restarted (or if session cookies are disabled, in
which case you have to do something else anyway).
--
--Mark Schupp
"Joe Hsu" <Jo*****@earthlink.net> wrote in message
news:vw*****************@newsread1.news.pas.earthl ink.net... It is session fixation attacKs. Sorry for the typo.
"If a malicious user has the ability to impersonate a specific sessionID
then certainly they would be able to impersonate an "authenticated" one."
Not necessary, if the sessionID is changed for the authenticated part of
the session.
"How and why are you relying on sessionID to allow access to certain parts
of the application?" I don't, ASP does. I'm hoping to find an ASP
function call that allows me to change the value of ASPSessionID.
"Aaron Bertrand [SQL Server MVP]" <te*****@dnartreb.noraa> wrote in
message news:O3*************@TK2MSFTNGP09.phx.gbl... session fixation attachs.
I have no idea what this is. But have you ever tried to fake out or
impersonate a session?
It is a good practice that the server changes the session ID after a
user is
sucessfully authenticated.
So the user changes to some other SessionID. Whoopty-doo. If a
malicious user has the ability to impersonate a specific sessionID then
certainly they would be able to impersonate an "authenticated" one.
How and why are you relying on sessionID to allow access to certain parts
of the application? Why not a variable like Session("authenticated")?
As I understand it, the ASPSessionID is used as a reference to all session
variables maintained by ASP for each session. If anybody gains the sessionID
from the unauthenticated screen, they will be able to use it to gain access
to the sesion data I maintain during the subsequent authenticated session.
BTW, it is not difficult to see the pattern of the ASPSessionID of any given
site.
The whitepaper in SANS on "Secure Session Mangement" has the following
advice on page 16:
"9. Force Server-side Session ID Creation
The server should never assume the value of a session ID that is given
before login. Instead the server mush create a unique session ID after the
user successfully authenticates (a strict web application). This will foil
session fixatin attacks."
Again, I'm looking for any ASP API to change the SessionID. If it is not
available, then I'll need to find other means.
Thanks!
"Mark Schupp" wrote: I think what Aaron was saying is that if a hacker can grab the
"unauthenticated" session id and impersonate a session then they would be
able to grab the "authenticated" one as well. What are you doing to protect
the "authenticated" id that you cannot do for the "unauthenticated" one?
As far as I know, the only way that a session id changes is if the client's
browser is closed and restarted (or if session cookies are disabled, in
which case you have to do something else anyway).
--
--Mark Schupp
"Joe Hsu" <Jo*****@earthlink.net> wrote in message
news:vw*****************@newsread1.news.pas.earthl ink.net... It is session fixation attacKs. Sorry for the typo.
"If a malicious user has the ability to impersonate a specific sessionID
then certainly they would be able to impersonate an "authenticated" one."
Not necessary, if the sessionID is changed for the authenticated part of
the session.
"How and why are you relying on sessionID to allow access to certain parts
of the application?" I don't, ASP does. I'm hoping to find an ASP
function call that allows me to change the value of ASPSessionID.
"Aaron Bertrand [SQL Server MVP]" <te*****@dnartreb.noraa> wrote in
message news:O3*************@TK2MSFTNGP09.phx.gbl... session fixation attachs.
I have no idea what this is. But have you ever tried to fake out or
impersonate a session?
It is a good practice that the server changes the session ID after a
user is
sucessfully authenticated.
So the user changes to some other SessionID. Whoopty-doo. If a
malicious user has the ability to impersonate a specific sessionID then
certainly they would be able to impersonate an "authenticated" one.
How and why are you relying on sessionID to allow access to certain parts
of the application? Why not a variable like Session("authenticated")?
> As I understand it, the ASPSessionID is used as a reference to all session variables maintained by ASP for each session. If anybody gains the
sessionID
from the unauthenticated screen, they will be able to use it to gain
access
to the sesion data I maintain during the subsequent authenticated session.
Can you please demonstrate either of these two parts.
I have never seen a demonstration of guessing or sniffing a currently active
sessionID, much less impersonating it.
"9. Force Server-side Session ID Creation
The server should never assume the value of a session ID that is given
before login. Instead the server mush create a unique session ID after
the
user successfully authenticates (a strict web application). This will
foil
session fixatin attacks."
I think you're chasing the wrong squirrel up the wrong tree. I think they
are talking about authenticating here via e.g. Windows Authentication, not
some silly login form in your own app. Your own web application is only as
strong as you make it.
Do you understand the statement that changing the SessionID is not going to
make your application any more secure?
Thank you for replies. For confidentiality, I could not reveal more than
what I've stated so far. I'll need to look elsewhere. BTW, there is no
"silly login form" in the application.
"Aaron Bertrand [SQL Server MVP]" wrote: As I understand it, the ASPSessionID is used as a reference to all session
variables maintained by ASP for each session. If anybody gains the
sessionID
from the unauthenticated screen, they will be able to use it to gain
access
to the sesion data I maintain during the subsequent authenticated session.
Can you please demonstrate either of these two parts.
I have never seen a demonstration of guessing or sniffing a currently active
sessionID, much less impersonating it.
"9. Force Server-side Session ID Creation
The server should never assume the value of a session ID that is given
before login. Instead the server mush create a unique session ID after
the
user successfully authenticates (a strict web application). This will
foil
session fixatin attacks."
I think you're chasing the wrong squirrel up the wrong tree. I think they
are talking about authenticating here via e.g. Windows Authentication, not
some silly login form in your own app. Your own web application is only as
strong as you make it.
Do you understand the statement that changing the SessionID is not going to
make your application any more secure?
How about this scenario (multi-user PC) ?
1. User A attempts to log in, has no valid UN/PW but is able to grab the
value of the SessionId using (eg.) a js bookmarklet
2. User B logs in (on the same PC, before the session has timed out) and
begins using the application.
Can user A now access user B's session from another PC by setting a session
cookie to the same value they captured in Step 1 ? Seems to me that they
they might be able to...
--
Tim Williams
Palo Alto, CA
"Aaron Bertrand [SQL Server MVP]" <te*****@dnartreb.noraa> wrote in message
news:uG**************@TK2MSFTNGP15.phx.gbl... As I understand it, the ASPSessionID is used as a reference to all
session variables maintained by ASP for each session. If anybody gains the
sessionID
from the unauthenticated screen, they will be able to use it to gain
access
to the sesion data I maintain during the subsequent authenticated
session.
Can you please demonstrate either of these two parts.
I have never seen a demonstration of guessing or sniffing a currently
active sessionID, much less impersonating it.
"9. Force Server-side Session ID Creation
The server should never assume the value of a session ID that is given
before login. Instead the server mush create a unique session ID after
the
user successfully authenticates (a strict web application). This will
foil
session fixatin attacks."
I think you're chasing the wrong squirrel up the wrong tree. I think they
are talking about authenticating here via e.g. Windows Authentication, not
some silly login form in your own app. Your own web application is only
as strong as you make it.
Do you understand the statement that changing the SessionID is not going
to make your application any more secure?
Gazing into my crystal ball I observed "Tim Williams" <saxifrax at
pacbell dot net> writing in news:eE**************@TK2MSFTNGP10.phx.gbl: How about this scenario (multi-user PC) ?
1. User A attempts to log in, has no valid UN/PW but is able to grab
the value of the SessionId using (eg.) a js bookmarklet
2. User B logs in (on the same PC, before the session has timed out)
and begins using the application.
Can user A now access user B's session from another PC by setting a
session cookie to the same value they captured in Step 1 ? Seems to me
that they they might be able to...
The problem is that if someone really wants to break in, they will. And
sometimes, things just happen. For example, there's a PC at the bank so
you can look up your account information online. Sometimes (a lot of
times), people forget to logout when they're done, and the bank doesn't
automatically log you out for inactivity for 5 minutes. Someone can get
a lot of information in 5 minutes.
--
Adrienne Boswell http://www.cavalcade-of-coding.info
Please respond to the group so others can share
If someone really wants to break into your car they will.
Doesn't mean it's not worth locking your doors.
Tim.
--
Tim Williams
Palo Alto, CA
"Adrienne" <ar********@sbcglobal.net> wrote in message
news:Xn****************************@207.115.63.158 ... Gazing into my crystal ball I observed "Tim Williams" <saxifrax at
pacbell dot net> writing in news:eE**************@TK2MSFTNGP10.phx.gbl:
How about this scenario (multi-user PC) ?
1. User A attempts to log in, has no valid UN/PW but is able to grab
the value of the SessionId using (eg.) a js bookmarklet
2. User B logs in (on the same PC, before the session has timed out)
and begins using the application.
Can user A now access user B's session from another PC by setting a
session cookie to the same value they captured in Step 1 ? Seems to me
that they they might be able to...
The problem is that if someone really wants to break in, they will. And
sometimes, things just happen. For example, there's a PC at the bank so
you can look up your account information online. Sometimes (a lot of
times), people forget to logout when they're done, and the bank doesn't
automatically log you out for inactivity for 5 minutes. Someone can get
a lot of information in 5 minutes.
--
Adrienne Boswell
http://www.cavalcade-of-coding.info
Please respond to the group so others can share
> Can user A now access user B's session from another PC by setting a session
cookie to the same value they captured in Step 1 ?
No, because (a) I don't think JS has the ability to read a server-side
sessionID, even if the author of the web page would put it there, and (b)
you can't access user B's session just by changing your cookie.
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?
Tim.
"Aaron Bertrand [SQL Server MVP]" <te*****@dnartreb.noraa> wrote in
message news:u1**************@TK2MSFTNGP10.phx.gbl... Can user A now access user B's session from another PC by setting a
session
cookie to the same value they captured in Step 1 ?
No, because (a) I don't think JS has the ability to read a
server-side sessionID, even if the author of the web page would put
it there, and (b) you can't access user B's session just by changing
your 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
Well, let me know exactly how you plan to do it. See if you can set a
session variable for a browser on one machine, get the cookie without having
access to the ASP file(s) directly, then use another machine and fiddle with
the cookie however you see fit, and see if you can retrieve the session
variable on machine B that was set for the user on machine A.
My experiments in the past have proved to me that it will not work.
In any case, even if the above were to work, a malicious user would have to
have access to the first user's session to get their sessionID at all, and
if they can do that, why not just continue their session?
So said so done. Exactly as described.
Opened login page on PC1, copied sessionid cookie name/value to text
file. Then logged in on PC1 using a known UN/PW.
Few minutes later on PC2, used an "edit cookie" bookmarklet to create
the session cookie from PC1, and was able to bypass the login page and
go directly to a "protected" page. This page would normally (on
seeing there is no "logged in=yes" session variable) redirect me to
the login page but in this case the session from PC1 is referenced due
to the copied cookie.
Bookmarklet for editing the session cookie was from here: http://visitjesper.homeip.net/bookmarklets.html
However unlikely the scenario, it has to be admitted to be possible
(and not that difficult either). That is the only point I'm trying to
make here.
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.
"Aaron Bertrand [SQL Server MVP]" <te*****@dnartreb.noraa> wrote in
message news:uU**************@TK2MSFTNGP14.phx.gbl... 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
Well, let me know exactly how you plan to do it. See if you can set
a session variable for a browser on one machine, get the cookie
without having access to the ASP file(s) directly, then use another
machine and fiddle with the cookie however you see fit, and see if
you can retrieve the session variable on machine B that was set for
the user on machine A.
My experiments in the past have proved to me that it will not work.
In any case, even if the above were to work, a malicious user would
have to have access to the first user's session to get their
sessionID at all, and if they can do that, why not just continue
their session?
Joseph Shoe wrote: How do you change the ASPSessionID during a web session? I have an ASP
application in SSL. The first screen is a login screen, which requests user
id and password. An ASPSessionID is assigned for this page. Once the user
is authenticated by valid id/pwd, the second page starts the real
applicaiton. I want to change the ASPSessionID to be different from the
first login page, which was issued to an unauthenticated user. How do I do
that in ASP?
Don't use ASP sessions. Instead create and maintain your own "session
ID" passed in the querystring or in hidden field(s). Then you can change
it wherever and whenever you wish, even with each page submission.
> However unlikely the scenario, it has to be admitted to be possible (and not that difficult either). That is the only point I'm trying to
make here.
I wasn't able to reproduce, but I'll take your word for it for now.
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.
Which is what I suggested further up in the thread (I also still didn't get
a decent answer to my question, what would be accomplished by changing the
sessionID).
Thanks, Tim. Your description is mostly correct. One clarificaiton: when
PC2 is able to get to the protected page of PC1 using the same SessionID, the
session variable "logged in" would be yes for PC2, as seen by PC1. PC2 will
not be redirected to the login page.
Your suggestion of using a second session cookie is a sound one. I was
merely looking for a shortcut. Afterall, it shouldn't be much difficult for
ASP to provide an API to change the SessionID.
"Tim Williams" wrote: So said so done. Exactly as described.
Opened login page on PC1, copied sessionid cookie name/value to text
file. Then logged in on PC1 using a known UN/PW.
Few minutes later on PC2, used an "edit cookie" bookmarklet to create
the session cookie from PC1, and was able to bypass the login page and
go directly to a "protected" page. This page would normally (on
seeing there is no "logged in=yes" session variable) redirect me to
the login page but in this case the session from PC1 is referenced due
to the copied cookie.
Bookmarklet for editing the session cookie was from here:
http://visitjesper.homeip.net/bookmarklets.html
However unlikely the scenario, it has to be admitted to be possible
(and not that difficult either). That is the only point I'm trying to
make here.
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.
"Aaron Bertrand [SQL Server MVP]" <te*****@dnartreb.noraa> wrote in
message news:uU**************@TK2MSFTNGP14.phx.gbl... 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
Well, let me know exactly how you plan to do it. See if you can set
a session variable for a browser on one machine, get the cookie
without having access to the ASP file(s) directly, then use another
machine and fiddle with the cookie however you see fit, and see if
you can retrieve the session variable on machine B that was set for
the user on machine A.
My experiments in the past have proved to me that it will not work.
In any case, even if the above were to work, a malicious user would
have to have access to the first user's session to get their
sessionID at all, and if they can do that, why not just continue
their session?
> Thanks, Tim. Your description is mostly correct. One clarificaiton: when PC2 is able to get to the protected page of PC1 using the same SessionID,
the
session variable "logged in" would be yes for PC2, as seen by PC1.
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.
"Tim Williams" wrote in message
news:u%****************@TK2MSFTNGP09.phx.gbl...
: 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
Aaron Bertrand [SQL Server MVP] wrote: Thanks, Tim. Your description is mostly correct. One clarificaiton: when
PC2 is able to get to the protected page of PC1 using the same SessionID,
the
session variable "logged in" would be yes for PC2, as seen by PC1.
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.
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.
"Joseph Shoe" <Jo********@discussions.microsoft.com> wrote in message
news:C0**********************************@microsof t.com... Thanks, Tim. Your description is mostly correct. One
clarificaiton: when
PC2 is able to get to the protected page of PC1 using the same
SessionID, the
session variable "logged in" would be yes for PC2, as seen by PC1.
PC2 will
not be redirected to the login page.
Your suggestion of using a second session cookie is a sound one. I
was
merely looking for a shortcut. Afterall, it shouldn't be much
difficult for
ASP to provide an API to change the SessionID.
"Tim Williams" wrote:
So said so done. Exactly as described.
Opened login page on PC1, copied sessionid cookie name/value to
text
file. Then logged in on PC1 using a known UN/PW.
Few minutes later on PC2, used an "edit cookie" bookmarklet to
create
the session cookie from PC1, and was able to bypass the login page
and
go directly to a "protected" page. This page would normally (on
seeing there is no "logged in=yes" session variable) redirect me to
the login page but in this case the session from PC1 is referenced
due
to the copied cookie.
Bookmarklet for editing the session cookie was from here:
http://visitjesper.homeip.net/bookmarklets.html
However unlikely the scenario, it has to be admitted to be possible
(and not that difficult either). That is the only point I'm trying
to
make here.
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.
"Aaron Bertrand [SQL Server MVP]" <te*****@dnartreb.noraa> wrote in
message news:uU**************@TK2MSFTNGP14.phx.gbl... >> 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
>
> Well, let me know exactly how you plan to do it. See if you can
> set
> a session variable for a browser on one machine, get the cookie
> without having access to the ASP file(s) directly, then use
> another
> machine and fiddle with the cookie however you see fit, and see
> if
> you can retrieve the session variable on machine B that was set
> for
> the user on machine A.
>
> My experiments in the past have proved to me that it will not
> work.
>
> In any case, even if the above were to work, a malicious user
> would
> have to have access to the first user's session to get their
> sessionID at all, and if they can do that, why not just continue
> their session?
>
"Tim Williams" wrote in message
news:eG**************@TK2MSFTNGP09.phx.gbl...
: 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
Tim Williams wrote:
<snipped> 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/archiv...2-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.
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
"Michael D. Kersey" <md******@hal-pc.org> wrote in message
news:uT**************@tk2msftngp13.phx.gbl... Tim Williams wrote:
<snipped> 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/archiv...2-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. This thread has been closed and replies have been disabled. Please start a new discussion. Similar topics
by: J.C. Flores |
last post by:
Hello all,
First of all, I must state that I'm new to SQL Server, but have been a
long-time software guy for quite some time. Please excuse the potential
simplicity of the solution to my...
|
by: Spike |
last post by:
Hello!
Im going to make a javascript for changing alot of images. But im not
sure how to do it., where to start..
Ok, first.. this is the isue.
I have 3 images(I call them 1a-3a).
when u...
|
by: beanweed |
last post by:
BACKGROUND
----------
I have an ASP.NET application having two panels. In one panel, an XML
document, transformed using xsl, is displayed. In the other panel are some
controls that allow a user...
|
by: Hank |
last post by:
My Access 2000 code has been running for several years in our main
plant. Now we need to install it, as a stand-along application, at
remote sites, some of which are out of state.
My problem is...
|
by: Fabrizio |
last post by:
(Sorry for the crosspost, but I really don't know which is the right
newsgroup!)
Hi all,
I try to change the password to a user that as to change the password at
first logon:
try
{
|
by: active |
last post by:
It appears to me that if I change the Control's client size the controls
size does not change to agree with the new size.
Does it work like the VB6 ScaleWidth and ScaleHeight?
That is after I...
|
by: mike.biang |
last post by:
I am using the XMLHTTP object to request a page from within another ASP
page. For my scenario, the two pages should operate in the same
session. However, when I request the second page, a new...
|
by: Simon |
last post by:
Dear reader,
The syntax for the VBA code to change the RowSource of a Master Report is:
Me.RowSource = "TableOrQueryName"
|
by: monkey1001 |
last post by:
my program is suppose to show my due change and i got it working but my change and coins are wrong how can i improve it thank you..(its supposed to be in java)
|
by: Charles Arthur |
last post by:
How do i turn on java script on a villaon, callus and itel keypad mobile phone
|
by: BarryA |
last post by:
What are the essential steps and strategies outlined in the Data Structures and Algorithms (DSA) roadmap for aspiring data scientists? How can individuals effectively utilize this roadmap to progress...
|
by: nemocccc |
last post by:
hello, everyone, I want to develop a software for my android phone for daily needs, any suggestions?
|
by: Sonnysonu |
last post by:
This is the data of csv file
1 2 3
1 2 3
1 2 3
1 2 3
2 3
2 3
3
the lengths should be different i have to store the data by column-wise with in the specific length.
suppose the i have to...
|
by: Hystou |
last post by:
There are some requirements for setting up RAID:
1. The motherboard and BIOS support RAID configuration.
2. The motherboard has 2 or more available SATA protocol SSD/HDD slots (including MSATA, M.2...
|
by: Oralloy |
last post by:
Hello folks,
I am unable to find appropriate documentation on the type promotion of bit-fields when using the generalised comparison operator "<=>".
The problem is that using the GNU compilers,...
|
by: jinu1996 |
last post by:
In today's digital age, having a compelling online presence is paramount for businesses aiming to thrive in a competitive landscape. At the heart of this digital strategy lies an intricately woven...
|
by: Hystou |
last post by:
Overview:
Windows 11 and 10 have less user interface control over operating system update behaviour than previous versions of Windows. In Windows 11 and 10, there is no way to turn off the Windows...
|
by: tracyyun |
last post by:
Dear forum friends,
With the development of smart home technology, a variety of wireless communication protocols have appeared on the market, such as Zigbee, Z-Wave, Wi-Fi, Bluetooth, etc. Each...
| |
