«

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

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.

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

>> 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]" <> wrote in message
news:OXT3nVw%...
> 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.
>
>

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

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"

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

"YYZ" <> wrote in message
news: 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

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

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

Anthony, thanks so much for all of what you posted. That really helps
me understand what a session really is and how it is managed. It also
helps me confirm that any session variables that I create are held
only on the server.

As I see it, there are 2 obvious ways of attacking my site. The man
in the middle approach like you said, which would allow a 3rd party to
view all the data sent between the server and an authorized user and
back. This is mitigated, I believer, by using SSL. No, nothing I
have written so far requires me to use SSL, but I have some clients
asking about online ordering and credit card processing, and SSL would
be required at that point. And someone else confirmed my belief that
in order to make my application SSL compatible, nothing really needs
to be done in my code. The server and the certificate handle all of
the encryption stuff so I do'nt have to worry about it.

However, another line of attack would be for someone to login as
themselves, then try to elevate their privileges in the application by
finding someone way of changing the server's idea of who the session
is really for and some other elevated user. If I store a session
variable with the name of the user who has logged in, then that user
can NOT change my server variable. Which means that I'm protected
from that sort of attack.

I know there must be hundreds of other things to worry about when
talking about security, but if I make some assumptions about the
physical security of my server, but none about the client, then I
think these 2 things will combine to make a relatively secure site.

At least I hope so.

Matt