Ram based Cookies

[Mark]

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]

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

 

[Patrice]

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]

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

Mark

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

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;
}

 

[Peter O'Reilly]

Another solution is to use SSL.

 

[Mark]

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

 

[Steve Drake]

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

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

Mark

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

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;
}

 

[bruce barker]

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)

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

 

[Mark]

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

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

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

Mark

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
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;
}

 

[Peter O'Reilly]

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.

 

[Colin Young]

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

 

[Steve Drake]

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

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

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

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

Mark

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
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;
}