By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
432,403 Members | 880 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 432,403 IT Pros & Developers. It's quick & easy.

Session variable, security, SSL, I'm confused

P: n/a
YYZ
I'm using asp, not asp.net. I've got some open ended questions that I
was really hoping someone in here could answer, or direct me to some
resources that will help me answer them on my own.

First, the session object. When a new user comes to my site, asp
creates a session object, and a session id on that object. That
session id is sent back to the client and stored as a cookie(?) that
can be used to identify a single user across multiple browser
requests. Is that right?

Second, can that sessionid be sniffed? I'm assuming it can be. But
if Bob comes to my site, gets assigned a session id of 1234, and then
logs in (via username and password that I validate on the server, all
behind an SSL certificate, I guess), I could store the correct
username "bobsmith" in a session variable. Is that session variable
also sent to the client? Does Bob, even though he can easily lookup
the session id of 1234 in his cookies, know that I stored another
session variable that identifies him? So Bob can't ever log in as
Bob, but then try to impersonate Jane after he is validated? Does
this even make sense?

In another scenario, Bob gets sessionid 1234. I store his username
bobsmith in a session variable. Should I also store his referring IP
and some other things (user agent, etc) and compare those with every
page request? If something changes in those things, does that mean
that it is possible I'm being felt out/attacked? Is it conceivable
that Bob's IP address might change but that the session is still the
same session id?

As far as SSL goes, when developing a site I don't have a
certificate. When I am ready to go live with this, do I just find a
webhost that will get a certificate for me, and the webserver handles
whether or not all traffic goes over https? I mean, do I have to do
anything special with my code, or is that all web server configuration
stuff?

What is a good way to secure a site? I'm really talking academically
here, but I may develop a real world site in the future that needs
this kind of security.

If anyone has read this far and understands my incoherent and confused
brain, I would be very appreciative of some pointers!

Matt

Sep 19 '07 #1
Share this Question
Share on Google+
8 Replies


P: n/a
YYZ wrote:
I'm using asp, not asp.net. I've got some open ended questions that I
was really hoping someone in here could answer, or direct me to some
resources that will help me answer them on my own.

First, the session object. When a new user comes to my site, asp
creates a session object, and a session id on that object. That
session id is sent back to the client and stored as a cookie(?)
Yes, it's called a session cookie and is different from normal cookies.
that
can be used to identify a single user across multiple browser
requests. Is that right?
Sort of. A session cookie persists only as long as the browser windows
that were open when the cookie was created
>
Second, can that sessionid be sniffed? I'm assuming it can be. But
if Bob comes to my site, gets assigned a session id of 1234, and then
logs in (via username and password that I validate on the server, all
behind an SSL certificate, I guess), I could store the correct
username "bobsmith" in a session variable. Is that session variable
also sent to the client? Does Bob, even though he can easily lookup
the session id of 1234 in his cookies, know that I stored another
session variable that identifies him? So Bob can't ever log in as
Bob, but then try to impersonate Jane after he is validated? Does
this even make sense?

In another scenario, Bob gets sessionid 1234. I store his username
bobsmith in a session variable. Should I also store his referring IP
and some other things (user agent, etc) and compare those with every
page request? If something changes in those things, does that mean
that it is possible I'm being felt out/attacked? Is it conceivable
that Bob's IP address might change but that the session is still the
same session id?

As far as SSL goes, when developing a site I don't have a
certificate. When I am ready to go live with this, do I just find a
webhost that will get a certificate for me, and the webserver handles
whether or not all traffic goes over https? I mean, do I have to do
anything special with my code, or is that all web server configuration
stuff?

What is a good way to secure a site? I'm really talking academically
here, but I may develop a real world site in the future that needs
this kind of security.

If anyone has read this far and understands my incoherent and confused
brain, I would be very appreciative of some pointers!
There are plenty of resources here:
http://www.google.com/search?sourcei...session+hijack

--
Microsoft MVP -- ASP/ASP.NET
Please reply to the newsgroup. The email account listed in my From
header is my spam trap, so I don't check it very often. You will get a
quicker response by posting to the newsgroup.
Sep 19 '07 #2

P: n/a
Hey Matt,

Here is my understanding of it: When someone comes to your site, you create
a session variable with (for example) id of 1234, then set the cookie with
value 1234. If you discover the person's name is Bob, you write that to your
database under record id 1234.

Naturally, if someone tries to access something of a sensitive nature
(passwords, credit cards, email addresses, etc.), you would challenge that
person by asking them to supply a password.

I worked once in the past with SSL. The company purchased a certificate
through the ISP, and they applied the certificate to the company's website.
For me, all I had to do to access the SSL was to direct my pages to https
instead of http. The rest was transparent to me.

I know this is a very simple answer to your elaborate question, but
sometimes simple helps you see through the trees.

~Joe
Sep 19 '07 #3

P: n/a
>A session cookie persists only as long as the browser windows that were
open when the cookie was created

Is that right? I thought session cookies were kept in memory on the server,
and timed out in the amount of time set for sessions.

Bob Lehmann

"Bob Barrows [MVP]" <re******@NOyahoo.SPAMcomwrote in message
news:OX****************@TK2MSFTNGP06.phx.gbl...
YYZ wrote:
I'm using asp, not asp.net. I've got some open ended questions that I
was really hoping someone in here could answer, or direct me to some
resources that will help me answer them on my own.

First, the session object. When a new user comes to my site, asp
creates a session object, and a session id on that object. That
session id is sent back to the client and stored as a cookie(?)

Yes, it's called a session cookie and is different from normal cookies.
that
can be used to identify a single user across multiple browser
requests. Is that right?

Sort of. A session cookie persists only as long as the browser windows
that were open when the cookie was created

Second, can that sessionid be sniffed? I'm assuming it can be. But
if Bob comes to my site, gets assigned a session id of 1234, and then
logs in (via username and password that I validate on the server, all
behind an SSL certificate, I guess), I could store the correct
username "bobsmith" in a session variable. Is that session variable
also sent to the client? Does Bob, even though he can easily lookup
the session id of 1234 in his cookies, know that I stored another
session variable that identifies him? So Bob can't ever log in as
Bob, but then try to impersonate Jane after he is validated? Does
this even make sense?

In another scenario, Bob gets sessionid 1234. I store his username
bobsmith in a session variable. Should I also store his referring IP
and some other things (user agent, etc) and compare those with every
page request? If something changes in those things, does that mean
that it is possible I'm being felt out/attacked? Is it conceivable
that Bob's IP address might change but that the session is still the
same session id?

As far as SSL goes, when developing a site I don't have a
certificate. When I am ready to go live with this, do I just find a
webhost that will get a certificate for me, and the webserver handles
whether or not all traffic goes over https? I mean, do I have to do
anything special with my code, or is that all web server configuration
stuff?

What is a good way to secure a site? I'm really talking academically
here, but I may develop a real world site in the future that needs
this kind of security.

If anyone has read this far and understands my incoherent and confused
brain, I would be very appreciative of some pointers!
There are plenty of resources here:
http://www.google.com/search?sourcei...session+hijack
>
--
Microsoft MVP -- ASP/ASP.NET
Please reply to the newsgroup. The email account listed in my From
header is my spam trap, so I don't check it very often. You will get a
quicker response by posting to the newsgroup.


Sep 19 '07 #4

P: n/a
YYZ
I worked once in the past with SSL. The company purchased a certificate
through the ISP, and they applied the certificate to the company's website.
For me, all I had to do to access the SSL was to direct my pages to https
instead of http. The rest was transparent to me.
Excellent! I thought it was that easy from a programming standpoint,
but it was hard to find definite information on that.
I know this is a very simple answer to your elaborate question, but
sometimes simple helps you see through the trees.
The helped, Joe. Thanks.

Sep 19 '07 #5

P: n/a

Bob Lehmann wrote:
>>A session cookie persists only as long as the browser windows that
were
open when the cookie was created

Is that right?
Sort of.
According to this:
http://msdn2.microsoft.com/en-us/lib...aspx#ac_topic5
session cookies are sent in the HTTP headers for every browser request.

This page makes it a little clearer:
http://palisade.plynt.com/issues/200...ssion-cookies/
To the OP's question about SSL, from the msdn page:
SSL Encryption
Encrypting all communications between the browser and the server will
prevent hackers from capturing the session cookie. Using SSL, all
traffic—including the session cookies—are encrypted. A hacker sniffing or
monitoring the network will not be able to see the private cookies in use.
When using SSL encryption, remember that all browser requests to the Web
application directory will include the session ID cookie. Even requests for
static HTML content in the same directory tree as the ASP pages will include
the session ID cookie. All requests to the virtual directory, not just for
ASP files, must be encrypted.

--
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"
Sep 19 '07 #6

P: n/a
YYZ
On Sep 19, 6:31 pm, "Bob Barrows [MVP]" <reb01...@NOyahoo.SPAMcom>
wrote:
Bob Lehmann wrote:
>A session cookie persists only as long as the browser windows that
were
open when the cookie was created
Is that right?

Sort of.
According to this:http://msdn2.microsoft.com/en-us/lib...aspx#ac_topic5
session cookies are sent in the HTTP headers for every browser request.
Thanks Bob(s). I checked out a bunch of those links on that search,
and thanks for that. The helped me understand a little more of the
process that takes place with the session object.

I'll keep reading up on it, but thanks.

Matt

Sep 20 '07 #7

P: n/a
"YYZ" <ma********@gmail.comwrote in message
news:11**********************@k79g2000hse.googlegr oups.com...
I'm using asp, not asp.net. I've got some open ended questions that I
was really hoping someone in here could answer, or direct me to some
resources that will help me answer them on my own.

First, the session object. When a new user comes to my site, asp
creates a session object, and a session id on that object. That
session id is sent back to the client and stored as a cookie(?) that
can be used to identify a single user across multiple browser
requests. Is that right?

Second, can that sessionid be sniffed? I'm assuming it can be. But
if Bob comes to my site, gets assigned a session id of 1234, and then
logs in (via username and password that I validate on the server, all
behind an SSL certificate, I guess), I could store the correct
username "bobsmith" in a session variable. Is that session variable
also sent to the client? Does Bob, even though he can easily lookup
the session id of 1234 in his cookies, know that I stored another
session variable that identifies him? So Bob can't ever log in as
Bob, but then try to impersonate Jane after he is validated? Does
this even make sense?

In another scenario, Bob gets sessionid 1234. I store his username
bobsmith in a session variable. Should I also store his referring IP
and some other things (user agent, etc) and compare those with every
page request? If something changes in those things, does that mean
that it is possible I'm being felt out/attacked? Is it conceivable
that Bob's IP address might change but that the session is still the
same session id?

As far as SSL goes, when developing a site I don't have a
certificate. When I am ready to go live with this, do I just find a
webhost that will get a certificate for me, and the webserver handles
whether or not all traffic goes over https? I mean, do I have to do
anything special with my code, or is that all web server configuration
stuff?

What is a good way to secure a site? I'm really talking academically
here, but I may develop a real world site in the future that needs
this kind of security.

If anyone has read this far and understands my incoherent and confused
brain, I would be very appreciative of some pointers!

Matt
Whilst the following probably duplicates what has been said in other
responses or is present it the links provided I'll just summarise the how
session operates and the risks.

As soon as client visits an ASP page in your application for the first time
a session object is created. This object has an ID which is returned to the
client in the ASPSESSIONxxxx cookie. The cookie is temporary in that the
client is not expected to record it to disk but just to keep in the browser
process memory. When the browser process ends so will the cookie.

Subsequent requests to the site will carry this session cookie. When a
request is made for an ASP page the cookie is used to find the appropriate
Session object and this object is added the script context. If a session
object is not found matching the ID then a new Session object is created and
a Set-Cookie header is added to the Response.

If an ASP request releated to a session is not made for a period of time
then the session object on the server is destroyed.

Note therefore that the only data send to the client in this case is the ID
of the session the contents of the session object remain on the server.

What are the risks?

It is possible for a man-in-the-middle attack to harvest the session ID from
a request and then be able to use the ID to masquerade as that session.

To cut a long examination of the various scenarios short the only way to
'properly' secure a site is run the whole lot over SSL. The questions is
would you really want to? SSL is somewhat heavy from both a CPU and a
bandwith point of view.

How likely is it that a Man-in-the-middle attack will target your site?
Does all the content need to be secure or just some sensitive parts?
--
Anthony Jones - MVP ASP/ASP.NET
Sep 20 '07 #8

P: n/a
"Bob Lehmann" wrote:
>A session cookie persists only as long as the browser windows
that were open when the cookie was created

Is that right? I thought session cookies were kept in memory on
the server, and timed out in the amount of time set for sessions.
That would be session variables. The cookie is stored in memory by the
browser (it has no expiration date and is thus transient), and is sent to
the server with every subsequent request.

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

Sep 20 '07 #9

This discussion thread is closed

Replies have been disabled for this discussion.