Ram based Cookies

Discussion in 'ASP .Net' started by Mark, Apr 28, 2004.

  1. Mark

    Mark Guest

    We use cookies to maintain some state information about a users session.
    They are not file based due to the fact that we don't specify a expiration
    date. They go away when the session ends. I know it's possible to modify a
    file based cookie. However, what would it take for a hacker that did not
    have access to our web server to modify the value of a ram based client
    cookie that we're creating below? I'm not concerned about someone reading
    what is in the cookie - I'm nervous about them being able to modify the
    cookie value.

    Thanks in advance.
    Mark

    HttpCookie ckCookie = Request.Cookies[strCookieName];
    if (ckCookie == null)
    {
    ckCookie = new HttpCookie(strCookieName, strCookieValue);
    Response.Cookies.Add(ckCookie);
    }
    else
    {
    Response.Cookies[strCookieName].Value = strCookieValue;
    }
     
    Mark, Apr 28, 2004
    #1
    1. Advertising

  2. Mark

    Steve Drake Guest

    I would never assume it cannot be edit, cookie are sent in the HTTP headers
    so you could intercept this and change the values.

    You could HASH the cookie.

    Steve

    Steve
    "Mark" <> wrote in message
    news:...
    > We use cookies to maintain some state information about a users session.
    > They are not file based due to the fact that we don't specify a expiration
    > date. They go away when the session ends. I know it's possible to modify

    a
    > file based cookie. However, what would it take for a hacker that did not
    > have access to our web server to modify the value of a ram based client
    > cookie that we're creating below? I'm not concerned about someone reading
    > what is in the cookie - I'm nervous about them being able to modify the
    > cookie value.
    >
    > Thanks in advance.
    > Mark
    >
    > HttpCookie ckCookie = Request.Cookies[strCookieName];
    > if (ckCookie == null)
    > {
    > ckCookie = new HttpCookie(strCookieName, strCookieValue);
    > Response.Cookies.Add(ckCookie);
    > }
    > else
    > {
    > Response.Cookies[strCookieName].Value = strCookieValue;
    > }
    >
    >
     
    Steve Drake, Apr 28, 2004
    #2
    1. Advertising

  3. Mark

    Patrice Guest

    Safe enough AFAIK. Of course you could always take an hexadecimal memory
    editor, locate the cookie somewhere in memory and change its value but it's
    probably beyond most people even hackers skills.

    You could also just avoid storing things that you seems to consider as
    "secret" client side (for example you could store a "handle" to this info,
    if the "handle" is changed, there is no info anyway on the other side - this
    is basically what session variables are ? Can't you use this ?).

    Patrice

    "Mark" <> a écrit dans le message de
    news:...
    > We use cookies to maintain some state information about a users session.
    > They are not file based due to the fact that we don't specify a expiration
    > date. They go away when the session ends. I know it's possible to modify

    a
    > file based cookie. However, what would it take for a hacker that did not
    > have access to our web server to modify the value of a ram based client
    > cookie that we're creating below? I'm not concerned about someone reading
    > what is in the cookie - I'm nervous about them being able to modify the
    > cookie value.
    >
    > Thanks in advance.
    > Mark
    >
    > HttpCookie ckCookie = Request.Cookies[strCookieName];
    > if (ckCookie == null)
    > {
    > ckCookie = new HttpCookie(strCookieName, strCookieValue);
    > Response.Cookies.Add(ckCookie);
    > }
    > else
    > {
    > Response.Cookies[strCookieName].Value = strCookieValue;
    > }
    >
    >
     
    Patrice, Apr 28, 2004
    #3
  4. Mark

    Mark Guest

    Great idea. A quick code sample, or pseduo code for both hashing and
    unhashing would be deeply appreciated.

    Mark

    "Steve Drake" <> wrote in message
    news:...
    > I would never assume it cannot be edit, cookie are sent in the HTTP

    headers
    > so you could intercept this and change the values.
    >
    > You could HASH the cookie.
    >
    > Steve
    >
    > Steve
    > "Mark" <> wrote in message
    > news:...
    > > We use cookies to maintain some state information about a users session.
    > > They are not file based due to the fact that we don't specify a

    expiration
    > > date. They go away when the session ends. I know it's possible to

    modify
    > a
    > > file based cookie. However, what would it take for a hacker that did

    not
    > > have access to our web server to modify the value of a ram based client
    > > cookie that we're creating below? I'm not concerned about someone

    reading
    > > what is in the cookie - I'm nervous about them being able to modify the
    > > cookie value.
    > >
    > > Thanks in advance.
    > > Mark
    > >
    > > HttpCookie ckCookie = Request.Cookies[strCookieName];
    > > if (ckCookie == null)
    > > {
    > > ckCookie = new HttpCookie(strCookieName, strCookieValue);
    > > Response.Cookies.Add(ckCookie);
    > > }
    > > else
    > > {
    > > Response.Cookies[strCookieName].Value = strCookieValue;
    > > }
    > >
    > >

    >
    >
     
    Mark, Apr 28, 2004
    #4
  5. SSL

    Another solution is to use SSL.
    --
    Peter O'Reilly
     
    Peter O'Reilly, Apr 28, 2004
    #5
  6. Mark

    Mark Guest

    Re: SSL

    Ah, good point. Let's assume I'm using SSL. What would it take for an
    authenticated user sitting at their client browser to modify their clear
    text ram based cookie values?

    Thanks again.
    Mark

    "Peter O'Reilly" <!N!O!.S!P!AM!> wrote in message
    news:...
    > Another solution is to use SSL.
    > --
    > Peter O'Reilly
    >
    >
     
    Mark, Apr 28, 2004
    #6
  7. Mark

    Steve Drake Guest

    You create a NEW cookie, base it on the vals from your non editable cookie,
    this new cookie is a sort of encrypted version of the non editable cookie,
    in your server code, you REGEN this cookie from the non editable value, if
    it doesent match, you asume the cookie has change.

    This is sort of like a checksum.

    I dont have a code sample, yet, but I do need todo this sort of thing soon.


    Steve

    you create a hash some sort of hash with some user info + the cookie name +
    the cookie valiue
    "Mark" <> wrote in message
    news:#...
    > Great idea. A quick code sample, or pseduo code for both hashing and
    > unhashing would be deeply appreciated.
    >
    > Mark
    >
    > "Steve Drake" <> wrote in message
    > news:...
    > > I would never assume it cannot be edit, cookie are sent in the HTTP

    > headers
    > > so you could intercept this and change the values.
    > >
    > > You could HASH the cookie.
    > >
    > > Steve
    > >
    > > Steve
    > > "Mark" <> wrote in message
    > > news:...
    > > > We use cookies to maintain some state information about a users

    session.
    > > > They are not file based due to the fact that we don't specify a

    > expiration
    > > > date. They go away when the session ends. I know it's possible to

    > modify
    > > a
    > > > file based cookie. However, what would it take for a hacker that did

    > not
    > > > have access to our web server to modify the value of a ram based

    client
    > > > cookie that we're creating below? I'm not concerned about someone

    > reading
    > > > what is in the cookie - I'm nervous about them being able to modify

    the
    > > > cookie value.
    > > >
    > > > Thanks in advance.
    > > > Mark
    > > >
    > > > HttpCookie ckCookie = Request.Cookies[strCookieName];
    > > > if (ckCookie == null)
    > > > {
    > > > ckCookie = new HttpCookie(strCookieName, strCookieValue);
    > > > Response.Cookies.Add(ckCookie);
    > > > }
    > > > else
    > > > {
    > > > Response.Cookies[strCookieName].Value = strCookieValue;
    > > > }
    > > >
    > > >

    > >
    > >

    >
    >
     
    Steve Drake, Apr 28, 2004
    #7
  8. Mark

    bruce barker Guest

    Re: SSL

    ssl prevents hijacking (some other user see the data and pretending to be
    them). ssl will in noway hinder the user hacking his own cookie. as client
    script can access the cookie, a user can modify his cookie with a little
    typing in the address bar (any browser), or if they can turn on a javascipt
    console, its even easier.

    -- bruce (sqlwork.com)


    "Mark" <> wrote in message
    news:...
    > Ah, good point. Let's assume I'm using SSL. What would it take for an
    > authenticated user sitting at their client browser to modify their clear
    > text ram based cookie values?
    >
    > Thanks again.
    > Mark
    >
    > "Peter O'Reilly" <!N!O!.S!P!AM!> wrote in message
    > news:...
    > > Another solution is to use SSL.
    > > --
    > > Peter O'Reilly
    > >
    > >

    >
    >
     
    bruce barker, Apr 28, 2004
    #8
  9. Mark

    Mark Guest

    Thanks Steve.

    Correct me if I'm wrong but this essentially requires both the client and
    the server to maintain this "value" that I'm passing in the cookie. To
    regenerate the value on the server, and then compare it to the client
    cookie, that means the server has to have a clue. :)

    In my scenario, the whole point of passing the cookie is that I don't want
    the server (session or otherwise) to have to regenerate the value. The
    cookie maintains this information so the server doesn't have to.

    Am I misreading your suggestion? Thanks again.

    Mark


    "Steve Drake" <> wrote in message
    news:...
    > You create a NEW cookie, base it on the vals from your non editable

    cookie,
    > this new cookie is a sort of encrypted version of the non editable cookie,
    > in your server code, you REGEN this cookie from the non editable value, if
    > it doesent match, you asume the cookie has change.
    >
    > This is sort of like a checksum.
    >
    > I dont have a code sample, yet, but I do need todo this sort of thing

    soon.
    >
    >
    > Steve
    >
    > you create a hash some sort of hash with some user info + the cookie name

    +
    > the cookie valiue
    > "Mark" <> wrote in message
    > news:#...
    > > Great idea. A quick code sample, or pseduo code for both hashing and
    > > unhashing would be deeply appreciated.
    > >
    > > Mark
    > >
    > > "Steve Drake" <> wrote in message
    > > news:...
    > > > I would never assume it cannot be edit, cookie are sent in the HTTP

    > > headers
    > > > so you could intercept this and change the values.
    > > >
    > > > You could HASH the cookie.
    > > >
    > > > Steve
    > > >
    > > > Steve
    > > > "Mark" <> wrote in message
    > > > news:...
    > > > > We use cookies to maintain some state information about a users

    > session.
    > > > > They are not file based due to the fact that we don't specify a

    > > expiration
    > > > > date. They go away when the session ends. I know it's possible to

    > > modify
    > > > a
    > > > > file based cookie. However, what would it take for a hacker that

    did
    > > not
    > > > > have access to our web server to modify the value of a ram based

    > client
    > > > > cookie that we're creating below? I'm not concerned about someone

    > > reading
    > > > > what is in the cookie - I'm nervous about them being able to modify

    > the
    > > > > cookie value.
    > > > >
    > > > > Thanks in advance.
    > > > > Mark
    > > > >
    > > > > HttpCookie ckCookie = Request.Cookies[strCookieName];
    > > > > if (ckCookie == null)
    > > > > {
    > > > > ckCookie = new HttpCookie(strCookieName, strCookieValue);
    > > > > Response.Cookies.Add(ckCookie);
    > > > > }
    > > > > else
    > > > > {
    > > > > Response.Cookies[strCookieName].Value = strCookieValue;
    > > > > }
    > > > >
    > > > >
    > > >
    > > >

    > >
    > >

    >
    >
     
    Mark, Apr 28, 2004
    #9
  10. Re: SSL

    "Mark" <> wrote in message
    news:...
    > Ah, good point. Let's assume I'm using SSL. What would it take for an
    > authenticated user sitting at their client browser to modify their clear
    > text ram based cookie values?
    >


    Your original message mentioned worries of a hacker. Your example above
    notes
    an authenticated user. The way I see it, how the hacker managed to get past
    authentication is the greater risk
    and concern.

    In other words, if the person authenticated is really the person intended to
    use the application, I do not see how any of what is contained in their
    cookie would be alarming as they are undoubtedly aware of their own social
    security number, credit card number, application settings selected or
    inputted, etc.

    Encrypted or not, keep in mind though that the user may see what cookie is
    being set, even if it's a session (memory resident) cookie, using such
    browsers as Mozilla and having such cookie alert setting turned on.

    If such security is really paramount, I would create a cookie containing an
    encrypted id that points to the user's session information contained on the
    server such as a database. This plus implementing SSL is about as stealth
    as one can imagine.

    --
    Peter O'Reilly
     
    Peter O'Reilly, Apr 28, 2004
    #10
  11. Mark

    Colin Young Guest

    It sounds from the discussion that you are concerned about your legitimate
    users trying to do things they shouldn't (I'm guessing privilege elevation
    or similar). If that is the case, the only thing you should store in the
    cookie is information that is known only to that user.

    For example, don't store a user ID only because that would allow an
    up-to-no-good user to simply change the ID to become a different person,
    possibly with elevated permissions. Instead, keep the ID and password in the
    cookie and verify it when the user attempts to perform an action.

    It may be more expensive in terms of computing resources and programming
    effort, but all security is coming up with the best balance between the cost
    of the security and the value of what is being protected. Bruce Schneier has
    a good essay on the topic at
    http://www.schneier.com/crypto-gram-0403.html#11.

    My suggestion would be to not put anything in the cookie that would provide
    a nefarious user with an easy way to guess, and have some way of detecting
    attacks. e.g. if some user is attempting to guess user IDs, in the worst
    case they change their user ID to '0' and become administrator. If you
    decide to play a trick and change the admin ID to some random number, you've
    made it difficult (not impossible) to guess, but unless you have some way of
    detecting attempts to change the user ID (i.e. a password and validation
    routine), you will have no idea that somebody is trying to crack your
    security and they can take as long as they want attempting to guess.

    Colin

    "Mark" <> wrote in message
    news:...
    > We use cookies to maintain some state information about a users session.
    > They are not file based due to the fact that we don't specify a expiration
    > date. They go away when the session ends. I know it's possible to modify

    a
    > file based cookie. However, what would it take for a hacker that did not
    > have access to our web server to modify the value of a ram based client
    > cookie that we're creating below? I'm not concerned about someone reading
    > what is in the cookie - I'm nervous about them being able to modify the
    > cookie value.
    >
    > Thanks in advance.
    > Mark
    >
    > HttpCookie ckCookie = Request.Cookies[strCookieName];
    > if (ckCookie == null)
    > {
    > ckCookie = new HttpCookie(strCookieName, strCookieValue);
    > Response.Cookies.Add(ckCookie);
    > }
    > else
    > {
    > Response.Cookies[strCookieName].Value = strCookieValue;
    > }
    >
    >
     
    Colin Young, Apr 28, 2004
    #11
  12. Mark

    Steve Drake Guest

    No, the value isn't need on the server, the server just holds the hashing
    code, you take the value and the hash sent to the sever, recreate the hash
    from the value sent if you get the same result as the hashed one.

    Your cookie sent from the server to the client could be :

    My Non Editable thing = "SomeValue"
    My Encrypted Value = "eulaVemos"

    When the cookies get sent back to the server, you take "Some Value", run you
    ENC code, it produces "eulaVemos" so the cookie has not been tampered, if
    .... you get

    My Non Editable thing = "WrongValue"
    My Encrypted Value = "eulaVemos"

    The server would create eulaVgnorW and compare it to eulaVemos so it would
    know its been tampered.

    You could get more intelligent by rotating a key that you use to encrypted
    on each requested for that user.

    I recon, this code could be added to the global asa to work with ALL
    cookies.

    Steve


    "Mark" <> wrote in message
    news:#...
    > Thanks Steve.
    >
    > Correct me if I'm wrong but this essentially requires both the client and
    > the server to maintain this "value" that I'm passing in the cookie. To
    > regenerate the value on the server, and then compare it to the client
    > cookie, that means the server has to have a clue. :)
    >
    > In my scenario, the whole point of passing the cookie is that I don't want
    > the server (session or otherwise) to have to regenerate the value. The
    > cookie maintains this information so the server doesn't have to.
    >
    > Am I misreading your suggestion? Thanks again.
    >
    > Mark
    >
    >
    > "Steve Drake" <> wrote in message
    > news:...
    > > You create a NEW cookie, base it on the vals from your non editable

    > cookie,
    > > this new cookie is a sort of encrypted version of the non editable

    cookie,
    > > in your server code, you REGEN this cookie from the non editable value,

    if
    > > it doesent match, you asume the cookie has change.
    > >
    > > This is sort of like a checksum.
    > >
    > > I dont have a code sample, yet, but I do need todo this sort of thing

    > soon.
    > >
    > >
    > > Steve
    > >
    > > you create a hash some sort of hash with some user info + the cookie

    name
    > +
    > > the cookie valiue
    > > "Mark" <> wrote in message
    > > news:#...
    > > > Great idea. A quick code sample, or pseduo code for both hashing and
    > > > unhashing would be deeply appreciated.
    > > >
    > > > Mark
    > > >
    > > > "Steve Drake" <> wrote in message
    > > > news:...
    > > > > I would never assume it cannot be edit, cookie are sent in the HTTP
    > > > headers
    > > > > so you could intercept this and change the values.
    > > > >
    > > > > You could HASH the cookie.
    > > > >
    > > > > Steve
    > > > >
    > > > > Steve
    > > > > "Mark" <> wrote in message
    > > > > news:...
    > > > > > We use cookies to maintain some state information about a users

    > > session.
    > > > > > They are not file based due to the fact that we don't specify a
    > > > expiration
    > > > > > date. They go away when the session ends. I know it's possible

    to
    > > > modify
    > > > > a
    > > > > > file based cookie. However, what would it take for a hacker that

    > did
    > > > not
    > > > > > have access to our web server to modify the value of a ram based

    > > client
    > > > > > cookie that we're creating below? I'm not concerned about someone
    > > > reading
    > > > > > what is in the cookie - I'm nervous about them being able to

    modify
    > > the
    > > > > > cookie value.
    > > > > >
    > > > > > Thanks in advance.
    > > > > > Mark
    > > > > >
    > > > > > HttpCookie ckCookie = Request.Cookies[strCookieName];
    > > > > > if (ckCookie == null)
    > > > > > {
    > > > > > ckCookie = new HttpCookie(strCookieName, strCookieValue);
    > > > > > Response.Cookies.Add(ckCookie);
    > > > > > }
    > > > > > else
    > > > > > {
    > > > > > Response.Cookies[strCookieName].Value = strCookieValue;
    > > > > > }
    > > > > >
    > > > > >
    > > > >
    > > > >
    > > >
    > > >

    > >
    > >

    >
    >
     
    Steve Drake, Apr 28, 2004
    #12
    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. Robert Posey
    Replies:
    0
    Views:
    697
    Robert Posey
    Nov 26, 2003
  2. Mark

    RAM based cookies

    Mark, Dec 13, 2005, in forum: ASP .Net
    Replies:
    1
    Views:
    352
    Bruce Barker
    Dec 13, 2005
  3. Mark

    RAM based cookies

    Mark, Dec 15, 2005, in forum: ASP .Net
    Replies:
    3
    Views:
    470
    Kevin Spencer
    Dec 15, 2005
  4. ashu
    Replies:
    1
    Views:
    484
  5. ashu
    Replies:
    2
    Views:
    642
    mysticlol
    Nov 6, 2006
Loading...

Share This Page