'securing' cookies/login info

[darrel]

This is an issue I brought up probably a year or so ago, got some advice,
then was sidetracked on the project until now. So, here I am again. ;o)

The situation is that we have an older chunk of code I've been tasked to
maintain 'as-is'. It's a CMS we wrote in ASP.net 1.1 about 4 years ago.

It works.

But we have one major issue and that's when people log in, maybe 5% of the
time, the end up with someone elses credentials. There's multiple things
we're likely doing wrong here, so I'll try to explain all the variables that
would effect this and then ask some specific questions:

- a user logs into one of 3 separate apps
- login function is called, which checks their credentials in the DB and
then writes a cookie with their credentials
- every page in the CMS (regardless of which of the 3 apps they are in)
loads a usercontrol onto the page. This usecrontrol then reads said cookie
and sets the value of various PUBLIC SHARED variables.

Things that I know are bad:

- the fact we used 3 apps. This should be one app.
- we're storing credentials in a cookie. Quite insecure (though not the end
of the world in this case)
- the way I'm reading in the cookie data

What happens:

- most of the time, nothing. But, once in a while you can tell that a
person has just logged in and from the time they hit LOGIN to the time the
server sends them their web page, someone else has done the same and the
usercontrol reads in the data of SOMONE else's cookie. If the end-user
refreshes the page, then they're back to their cookie.

What I could do:

1) rewrite the app in asp.net 2.0 and use the built in permissions/roles
system
2) have the cookie only write out their logged-in status and their
username, then check that against the DB each time
3) Not use cookies but session state instead?
4) Fix my bad usercontrol/Public Shared variables?

Option 1 and 2 are out as I'm supposed to be touching this code as little as
possible.

Are option 3 and 4 viable? What, exactly, is causing my issue (cookie data
being sent to the wrong user?) Is it as simple as fixing the way I'm reading
the cookie? Is it better to use session state?

IIRC the last time I went through this, the main issue is the 'SHARED'
variable, which allows every instantiation of it to be 'the' most updated
version that everyone reads. However, I can't remove SHARED as I can't then
access that property from the page that loads the usercontrol. I'm pretty
sure this is all due to me not having a full grasp of OOP and therefor not
creating a new instance of the class I need.

_Darrel

[=?Utf-8?B?YnJ1Y2UgYmFya2Vy?=]

RE: 'securing' cookies/login info

your problem is the shared variables. they are shared for all users, so if
one user request changes them, then they are changed for all users.

it sounds like they are set at the begin of the request, so as long two
people do not hit the site at the same time, you are ok.

you can fix the site by removing all shared variables, or add a lock, so
only one user at a time can use the site (this may be the easiest, as load
does not appear to be a problem)

-- bruce (sqlwork.com)


"darrel" wrote:

This is an issue I brought up probably a year or so ago, got some advice,
then was sidetracked on the project until now. So, here I am again. ;o)
>
The situation is that we have an older chunk of code I've been tasked to
maintain 'as-is'. It's a CMS we wrote in ASP.net 1.1 about 4 years ago.
>
It works.
>
But we have one major issue and that's when people log in, maybe 5% of the
time, the end up with someone elses credentials. There's multiple things
we're likely doing wrong here, so I'll try to explain all the variables that
would effect this and then ask some specific questions:
>
- a user logs into one of 3 separate apps
- login function is called, which checks their credentials in the DB and
then writes a cookie with their credentials
- every page in the CMS (regardless of which of the 3 apps they are in)
loads a usercontrol onto the page. This usecrontrol then reads said cookie
and sets the value of various PUBLIC SHARED variables.
>
Things that I know are bad:
>
- the fact we used 3 apps. This should be one app.
- we're storing credentials in a cookie. Quite insecure (though not the end
of the world in this case)
- the way I'm reading in the cookie data
>
What happens:
>
- most of the time, nothing. But, once in a while you can tell that a
person has just logged in and from the time they hit LOGIN to the time the
server sends them their web page, someone else has done the same and the
usercontrol reads in the data of SOMONE else's cookie. If the end-user
refreshes the page, then they're back to their cookie.
>
What I could do:
>
1) rewrite the app in asp.net 2.0 and use the built in permissions/roles
system
2) have the cookie only write out their logged-in status and their
username, then check that against the DB each time
3) Not use cookies but session state instead?
4) Fix my bad usercontrol/Public Shared variables?
>
Option 1 and 2 are out as I'm supposed to be touching this code as little as
possible.
>
Are option 3 and 4 viable? What, exactly, is causing my issue (cookie data
being sent to the wrong user?) Is it as simple as fixing the way I'm reading
the cookie? Is it better to use session state?
>
IIRC the last time I went through this, the main issue is the 'SHARED'
variable, which allows every instantiation of it to be 'the' most updated
version that everyone reads. However, I can't remove SHARED as I can't then
access that property from the page that loads the usercontrol. I'm pretty
sure this is all due to me not having a full grasp of OOP and therefor not
creating a new instance of the class I need.
>
_Darrel
>
>
>

[darrel]

Re: 'securing' cookies/login info

you can fix the site by removing all shared variables

That's what I thought. What I'm not so sure about, though, is what to
replace them with.

If I removed the 'shared' declaration, I can't access the variable in the
control from the page that is loading it.

or add a lock, so
only one user at a time can use the site (this may be the easiest, as load
does not appear to be a problem)

Not sure what you mean by that. Do you mean if someone is using the CMS,
block anyone else from using it?

-Darrel

[Mark Fitzpatrick]

Re: 'securing' cookies/login info

Create properties on the control. Then, in the page, you can access the
properties in the control and set them. The timing is important as if you
set them in the Page_Load event of the page, they won't be available in the
Page_Load of the control since it fires at a different time. The OnPreRender
method of the control will be able to read the properties set by the page in
a Page_Load event. If the code that handles the variables is loaded earlier,
then you can access them earlier in the control's event lifecycle.

Hope this helps,
Mark Fitzpatrick
Microsoft MVP - Expression

"darrel" <notreal@nowher e.comwrote in message
news:#DTqyy3rIH A.1952@TK2MSFTN GP05.phx.gbl...

>you can fix the site by removing all shared variables

>
That's what I thought. What I'm not so sure about, though, is what to
replace them with.
>
If I removed the 'shared' declaration, I can't access the variable in the
control from the page that is loading it.
>

>or add a lock, so
>only one user at a time can use the site (this may be the easiest, as
>load
>does not appear to be a problem)

>
Not sure what you mean by that. Do you mean if someone is using the CMS,
block anyone else from using it?
>
-Darrel
>

[darrel]

Re: 'securing' cookies/login info

Create properties on the control. Then, in the page, you can access the

properties in the control and set them. The timing is important as if you
set them in the Page_Load event of the page, they won't be available in
the Page_Load of the control since it fires at a different time. The
OnPreRender method of the control will be able to read the properties set
by the page in a Page_Load event. If the code that handles the variables
is loaded earlier, then you can access them earlier in the control's event
lifecycle.

good old properties. so, I assume properties don't have the 'shared' issue
with them being shared across the application by each user? If so, that
certainly sounds like the best 'band aid' solution for this project until it
can be rewritten.

-Darrel

[Mark Fitzpatrick]

Re: 'securing' cookies/login info

That's correct. Properties aren't shared. What is typically done is to store
and save the property using the viewstate of the control like so:

public string MyProperty
{
get
{
if(ViewState["MyProperty "] != null)
return ViewState["MyProperty "] .ToString();
else
return string.empty;
}
set {ViewState["MyProperty "] = value; }
}

You can do more complex types by using a cast. For example, here's a boolean
with a default value of False if it hasn't been set.

public boolMyBooleanPr operty
{
get
{
if(ViewState["MyBooleanPrope rty"] != null)
return (bool)ViewState["MyBooleanPrope rty"]
else
return false;
}
set {ViewState["MyBooleanPrope rty"] = value; }
}

These definitions will go within each control that needs them. You may find
it easier to create a new base class that inherits from the UserControl
class for the user controls that would have these properties already
defined. That way if most of the controls need the same properties on each
of them you can just inherit from this new base class instead of having to
define the properties in all your controls by hand.

Hope this helps,
Mark Fitzpatrick
Microsoft MVP - Expression

"darrel" <notreal@nowher e.comwrote in message
news:OjcmBhFsIH A.1236@TK2MSFTN GP02.phx.gbl...

>Create properties on the control. Then, in the page, you can access the
>properties in the control and set them. The timing is important as if you
>set them in the Page_Load event of the page, they won't be available in
>the Page_Load of the control since it fires at a different time. The
>OnPreRender method of the control will be able to read the properties set
>by the page in a Page_Load event. If the code that handles the variables
>is loaded earlier, then you can access them earlier in the control's
>event lifecycle.

>
good old properties. so, I assume properties don't have the 'shared' issue
with them being shared across the application by each user? If so, that
certainly sounds like the best 'band aid' solution for this project until
it can be rewritten.
>
-Darrel
>