Session variable, security, SSL, I'm confused

Discussion in 'ASP General' started by YYZ, Sep 19, 2007.

  1. YYZ

    YYZ Guest

    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, Sep 19, 2007
    #1
    1. Advertising

  2. 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?source...ls=GGLD,GGLD:2003-36,GGLD:en&q=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.
     
    Bob Barrows [MVP], Sep 19, 2007
    #2
    1. Advertising

  3. YYZ

    jp2code Guest

    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
     
    jp2code, Sep 19, 2007
    #3
  4. YYZ

    Bob Lehmann Guest

    >> 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?source...ls=GGLD,GGLD:2003-36,GGLD:en&q=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.
    >
    >
     
    Bob Lehmann, Sep 20, 2007
    #4
  5. YYZ

    YYZ Guest

    > 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.
     
    YYZ, Sep 20, 2007
    #5
  6. 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/library/ms972338.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/2007Feb/asp-session-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"
     
    Bob Barrows [MVP], Sep 20, 2007
    #6
  7. YYZ

    YYZ Guest

    On Sep 19, 6:31 pm, "Bob Barrows [MVP]" <>
    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/library/ms972338.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, Sep 20, 2007
    #7
  8. "YYZ" <> wrote in message
    news:...
    > 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
     
    Anthony Jones, Sep 20, 2007
    #8
  9. "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.
     
    Dave Anderson, Sep 20, 2007
    #9
  10. YYZ

    YYZ Guest

    > 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
     
    YYZ, Sep 20, 2007
    #10
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. 620
    Replies:
    2
    Views:
    1,008
    Murat Tunaboylu
    Jan 6, 2004
  2. John
    Replies:
    0
    Views:
    416
  3. Kbalz
    Replies:
    1
    Views:
    552
    Kbalz
    Aug 28, 2006
  4. John Smith
    Replies:
    0
    Views:
    389
    John Smith
    Oct 5, 2006
  5. chowchho
    Replies:
    7
    Views:
    634
    Patrice
    Mar 28, 2008
Loading...

Share This Page