Role based security flaw?

20 Mar 2006 4:19 PM

Andy

Hi all,

I'm implementing role based security, but I keep having this nagging
feeling that it may not be as secure.

Using role based security to classes / methods, whats to stop a
malicious client from creating their own prinicpal that answers yes to
ever IsInRole call? What should I watch for to prevent this? Limit
the principal to certain types (WindowsPrincipal, my custom one, etc)?

Thanks
Andy

20 Mar 2006 5:29 PM

Joe Kaplan (MVP - ADSI)

Is this on a client installed app? If so, there is nothing you can do to
prevent them from doing any kind of hacking they want. The code is
installed locally, so they basically own it if they are an admin or can
elevate their privileges. Admins can attach debuggers and do whatever they
want to the app in memory as it runs. This has always been the case.

If the app is installed server side, then you do all the security checking.
You can then enforce whatever mechanism you want. I would not be worried
about it in an ASP.NET app unless you can't trust your adminitrators.

Noe that you can still do some enforcing of a security model on the client
side and take measures to help prevent tampering, but you have to be
realistic about what you can achieve. Some threat modeling will go a long
way here. For example, you can do runtime checks to verify that the
IPrincpal is a certain type, but you can't prevent that type from getting
hoisted on the machine itself and replaced by a rogue one. CAS can't fix
this because CAS can be disabled. By knowing what you can and cannot do,
you can get a better picture of the risks. If it is really important, make
the server enforce it.

Joe K.

Show quoteHide quote

"Andy" <ajj3***@alum.rit.edu> wrote in message
news:1142871595.482806.196200@i39g2000cwa.googlegroups.com...
> Hi all,
>
> I'm implementing role based security, but I keep having this nagging
> feeling that it may not be as secure.
>
> Using role based security to classes / methods, whats to stop a
> malicious client from creating their own prinicpal that answers yes to
> ever IsInRole call? What should I watch for to prevent this? Limit
> the principal to certain types (WindowsPrincipal, my custom one, etc)?
>
> Thanks
> Andy
>

20 Mar 2006 7:07 PM

oldbear

Hi Joe

I appreciate the limitations of virtual machines as regards manipulating the
CLR, but that aside version 2.0 of the .Net framework stops you turning off
CAS. Yes, you can turn it off using CASPOL, but only for as long as CASPOL
remains active
(http://msdn.microsoft.com/netframework/default.aspx?pull=/library/en-us/dnnetsec/html/foundstone.asp#founds_topic3).

Using CAS as a gatekeeper here could stop the application from allowing
replacement of the principal object. Just turn the 'Allow Principal Control'
flag off in the Security permission. If this is a Windows application, apply
this to the Windows app via a code group, and as long as the user doesn't
have permission to alter CAS this offers some protection. However, if the
user has physical access to the machine (as they will do with a Windows app)
then it is easier for the user to compromise the application anyway.

If this is a web app, code injection (eg. using sql injection to add a web
page to the app) could allow alteration of the principal. Turning off the
'Allow Principal Control' flag in the security configuration file is one
barrier to this happening.

Hope this helps

Chris Seary

Show quoteHide quote

"Joe Kaplan (MVP - ADSI)" wrote:

> Is this on a client installed app? If so, there is nothing you can do to
> prevent them from doing any kind of hacking they want. The code is
> installed locally, so they basically own it if they are an admin or can
> elevate their privileges. Admins can attach debuggers and do whatever they
> want to the app in memory as it runs. This has always been the case.
>
> If the app is installed server side, then you do all the security checking.
> You can then enforce whatever mechanism you want. I would not be worried
> about it in an ASP.NET app unless you can't trust your adminitrators.
>
> Noe that you can still do some enforcing of a security model on the client
> side and take measures to help prevent tampering, but you have to be
> realistic about what you can achieve. Some threat modeling will go a long
> way here. For example, you can do runtime checks to verify that the
> IPrincpal is a certain type, but you can't prevent that type from getting
> hoisted on the machine itself and replaced by a rogue one. CAS can't fix
> this because CAS can be disabled. By knowing what you can and cannot do,
> you can get a better picture of the risks. If it is really important, make
> the server enforce it.
>
> Joe K.
>
> "Andy" <ajj3***@alum.rit.edu> wrote in message
> news:1142871595.482806.196200@i39g2000cwa.googlegroups.com...
> > Hi all,
> >
> > I'm implementing role based security, but I keep having this nagging
> > feeling that it may not be as secure.
> >
> > Using role based security to classes / methods, whats to stop a
> > malicious client from creating their own prinicpal that answers yes to
> > ever IsInRole call? What should I watch for to prevent this? Limit
> > the principal to certain types (WindowsPrincipal, my custom one, etc)?
> >
> > Thanks
> > Andy
> >
>
>
>

20 Mar 2006 8:19 PM

Andy

Joe and oldbear,

Thanks for your comments.

I've done both win and web apps; currently I'm working on a local win
app, but I'm not really worried about internal uses (its a very small
company), this is just a question that's been on my mind for a while.

I have a business layer which can remote to a server to do any data
access, and in the past I enforced a certain principal type there, I
was wondering if there was another way that I could go about it if i
did become concerned.

I'll check into the Allow Principal control flag.

Thanks
Andy

20 Mar 2006 8:24 PM

William Stacey [MVP]

Isn't checking for this enouph?:
1) ID is a WindowsIdentity
2) IsAuthenticated == true
3) Check roles as needed.

Is there a way around that?

--
William Stacey [MVP]

20 Mar 2006 8:29 PM

Andy

William,

#2 and #3 are easy; use PrincipalPermission. #1 requires you to add
lines of code to places... My question was trying to gauge if the
benefit would be worth the time.

Even if all those are met, its possible that the identity was
authenticated from a rogue domain (well, it might be, I'm not 100% if
that's possible).

Andy

20 Mar 2006 8:49 PM

Joe Kaplan (MVP - ADSI)

WindowsIdentity can't be faked (unless you start hacking with a debugger or
something). However, I thought this discussion came up in the context of
general role-based security with IPrincipal and not a specific
implementation that relied on WindowsPrincipal. If you can use Windows
security, it is harder to fake and probably easier to deal with.

If you are dealing with your own custom IPrincipal, then it is probably
easier for someone to hack that, but by that time, the game is probably over
for either implementation. As soon as someone starts replacing your local
assemblies with hacked binaries or doing other goofy stuff, the game is
pretty much over.

To answer your other question, it is definitely possible to make some kind
of a remote call to a server to enforce security if that is an option.
Remoting or web services would work fine for that. You still have the
possibility of your local code that does that check getting hoisted, but it
sounds like you are mostly interested in keeping the honest people honest,
so that probably isn't a huge concern.

CAS can defnitely also help keep the honest people honest.

Joe K.

Show quoteHide quote

"Andy" <ajj3***@alum.rit.edu> wrote in message
news:1142886555.029704.82080@g10g2000cwb.googlegroups.com...
> William,
>
> #2 and #3 are easy; use PrincipalPermission. #1 requires you to add
> lines of code to places... My question was trying to gauge if the
> benefit would be worth the time.
>
> Even if all those are met, its possible that the identity was
> authenticated from a rogue domain (well, it might be, I'm not 100% if
> that's possible).
>
> Andy
>

20 Mar 2006 9:13 PM

William Stacey [MVP]

| #2 and #3 are easy; use PrincipalPermission. #1 requires you to add
| lines of code to places... My question was trying to gauge if the
| benefit would be worth the time.

You could use one line of code in your entry point method(s), to verify user
or throw exception, then use only attributes in your method chain after
that.
I would make sure your public remote entry points are few and well protected
with your Verify() helper. Then after you do Impersonate, your role
security attributes should be fine.

| Even if all those are met, its possible that the identity was
| authenticated from a rogue domain (well, it might be, I'm not 100% if
| that's possible).

If that is possible, then what is more secure? So where does that leave
this? Is this a client app or a client/server. How are you authorizing
clients to the server (wse, negotiatestream/remoting, etc)?
--wjs

21 Mar 2006 8:39 AM

oldbear

Hi

Did you mean PrincipalPermission attributes in the later method chain? These
are a little troublesome for Windows authentication, due to the domain part
having to be hard-coded - this makes it hard to move the app from test
environment to acceptance to production etc. I always use the programmatic
version, or even check the .IsInRole method of the principal.

If there's still a concern ragrding users tampering with the Windows app,
then why not use a web service instead, and move much of the logic to the web
server. You could still provide a Windows interface for the user. And flowing
the user identity would be much easier (just flow the default credentials).

Although you can use a number of gatekeepers, such as CAS, it's sensible to
assume that all client code or input has been compromised. Moving more of it
to the server would reduce this issue.

Diniz Cruz (.Net Project Leader for OWASP) has an excellent demonstration of
what you can do with a .Net Windows Forms front end:

http://www.developerday.co.uk/ddd/slides.asp

Look at the .wmv 'Attacking Web and Windows Applications'.

However, I accept that your app may require a richer interface that doesn't
suit my recommendation.

Hope this helps

Chris Seary

Show quoteHide quote

"William Stacey [MVP]" wrote:

> | #2 and #3 are easy; use PrincipalPermission. #1 requires you to add
> | lines of code to places... My question was trying to gauge if the
> | benefit would be worth the time.
>
> You could use one line of code in your entry point method(s), to verify user
> or throw exception, then use only attributes in your method chain after
> that.
> I would make sure your public remote entry points are few and well protected
> with your Verify() helper. Then after you do Impersonate, your role
> security attributes should be fine.
>
> | Even if all those are met, its possible that the identity was
> | authenticated from a rogue domain (well, it might be, I'm not 100% if
> | that's possible).
>
> If that is possible, then what is more secure? So where does that leave
> this? Is this a client app or a client/server. How are you authorizing
> clients to the server (wse, negotiatestream/remoting, etc)?
> --wjs
>
>
>

21 Mar 2006 9:08 PM

Andy

I wanted to thank everyone for their comments, they provided alot of
insight.

Its an internal only client app, so I'm not terribly worried security
(yet). I just wanted to get this question answered before I totally
buy into going the role based security route.

As far as what I'm doing, i'm tagging classes (Don't need anything that
too grained yet) with PrincipalPermissions, demanding that the user be
in a particular role and authenticated (The name of the role doesn't
include the domain part, so moving it between environments won't be
difficult).

Thanks again everyone.