they are only insecure because the sessionid can be hijacked.

if the "hacker" was to highjack a session he would still have only the
access that you expose.

that is, if you have an "edit" screen, say for your credit card info, a user
can hijack the session, then go to this edit screen...first compromise the
session, and then the information which has been exposed.

there is no real way for anyone to get access to the actual session store in
the server's memory.





-----Original Message-----
From: Andrew Smith 
Sent: Wednesday, August 23, 2000 5:27 AM
To: How To
Subject: [proasp_howto] RE: Some questions


Robert

I am concerned after your comments re session variables are not secure.
Surely you can't just request a variable that is stored on an IIS server
without having permission to run the asp script to rewuest it.
We tend to store our UserIds and passwords at session level. Is this wrong ?


Andy


""unfortunately a session CAN be hijacked...meaning
that I can make a request for your site with a specific session that i
programatically set on my machine""---




----- Original Message -----
From: Robert Chartier 
To: How To <proasp_howto@p...>
Sent: Tuesday, August 22, 2000 7:17 PM
Subject: [proasp_howto] RE: Some questions


> response.buffer=true
>
> will inhibit page content from being sent to the browser, and aviod the
> pesky header error in netscape when using response.redirect.  you can also
> look into server.transfer
>
> http://www.aspfree.com/devlinks/search.asp?file404=server;transfer
>
>
> -sessions are not very secure because they are stored on the server, in
the
> server memory and the only way a session can be access is by the session
id
> (the cookie on the client) unfortunately a session CAN be
hijacked...meaning
> that I can make a request for your site with a specific session that i
> programatically set on my machine---which makes sessions insecure.  using
> sessions also imposes scalability problems, and server performance
> degradation.
>
> cookies are just as insecure.  they are transmitted over the internet,
thus
> any ole packet sniffer looking for the right stuff could easily pick it
up.
> you could consider encrypting the cookie...?
>
> what i usually will do is simulate the session, with a unique sessionid
> (UUID -unique user id), and have it relate back to their personal
> information.  for example, if i take their user id and user name, encrypt
> them and use that for the UUID, there is an exteremly low change of anyone
> ever being able to just guess a different UUID to hack accounts.  store
this
> in the querystring or form variables, or even in a cookie if you want the
> dependancy on the client.  this UUID will relate back to my data store
where
> i hold all information, --encrypted if the information is sensitive--
>
>
> -Rob
> http://www.aspfree.com/devlinks
>
>
>
>
>
>
> -----Original Message-----
> From: Alan Wynmclean
> Sent: Tuesday, August 22, 2000 5:51 PM
> To: How To
> Subject: [proasp_howto] Some questions
>
>
> 1. When redirecting a user with Response.Redirect(someurl) you can put a
> very long loop after the redirect statement to prevent other page content
> from being displayed while the redirect is in progress.  Is there any
> reason not to use an infinite loop (e.g. while(true) { /* do nothing */
> })?
>
> 2. Can anybody give me an idea of how secure Session variables and cookies
> are?  Are there kinds of information which shouldn't be stored in Sessions
> for reasons of security?
>
> Thanks in advance,
> Alan
>