Re: Role based security flaw?

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



"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" <ajj3085@xxxxxxxxxxxx> wrote in message
news:1142871595.482806.196200@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
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




.

Relevant Pages

  • Re: Interplatform (interprocess, interlanguage) communication
    ... If I'm using XML at all, and JAXB suits, I'll use JAXB. ... one can wonder though, what really would be the gain of using XML syntax in many such cases, vs the typical "relative niceness" of a line oriented format. ... typically I don't deal a whole lot with anything "security ... a 3rd party could somehow break the app and get control of the users' OS ...
    (comp.lang.java.programmer)
  • Re: Interplatform (interprocess, interlanguage) communication
    ... If I'm using XML at all, and JAXB suits, I'll use JAXB. ... typically I don't deal a whole lot with anything "security ... a 3rd party could somehow break the app and get control of the users' OS ... standards like the Java Secure Coding Guidelines, ...
    (comp.lang.java.programmer)
  • Re: Security Exception when deploying a VB.NET 2003 Solution
    ... It runs fine on any workstation. ... folder 2 levels up from the BIN folder where the application resides. ... Microsoft .NET security errors upon trying to start the Executable. ... I bet the workstaion is WinXP and your app is trying to write data( ...
    (microsoft.public.vsnet.general)
  • TWSL2011-008: Focus Stealing Vulnerability in Android
    ... Trustwave's SpiderLabs Security Advisory TWSL2011-008: ... Focus Stealing Vulnerability in Android ... the same app or a different app. ... This vulnerability has not been fixed at the time of this advisory. ...
    (Bugtraq)
  • [Full-disclosure] TWSL2011-008: Focus Stealing Vulnerability in Android
    ... Trustwave's SpiderLabs Security Advisory TWSL2011-008: ... Focus Stealing Vulnerability in Android ... the same app or a different app. ... This vulnerability has not been fixed at the time of this advisory. ...
    (Full-Disclosure)