Setting up secure custom Web Controls

[cpnet]

I've read through "Building Secure MS ASP.NET Applications", and "Improving
Web Application Security", but I'm a little confused about how to properly
set up security.

I am building a few controls/components that will be used by another party
in their own web app - and I have no involvement in the actual web app, only
these custom controls/components. One of my custom controls relies on the
Infragistics WebTree control.

Right now, my controls/components are split up into 3 assemblies, and
because of this, some methods/properties have to be public even though only
my own assemblies should be able to call these 'public' methods/proprties.
I also want to ensure in some cases that only my own assemblies can have
classes that inherit from other classes in my assemblies. I understand that
if I strongly name my assemblies, then I can use an attibute on the 'public'
members to ensure that only my own assemblies can call them. However, I
start to get confused, because it seems I start to get into issues of full
trust vs. partial trust, demands vs. link demands, asserts, and APTCA. I'm
not completely sure when I need to be concerned with each of these things.
Finally, I want to have an additional satellite assembly (that will be more
frequently updated, and backwards compatible with my other assemblies).
This satellite assembly will contain an Xml 'file' in a resource that only
my assemblies should have access to.

My controls will only function in an ASP.NET web-app, but some of my
components and classes may be used in a non-ASP.NET and/or ASP.NET
environment. What do I need to do to keep things secure, yet still
functional in a web-app?

As far as I can tell I have to:

- Mark my assemblies with APTCA
- Strongly name my assemblies and have them installed in the GAC (but what
happens if the consumer of my controls just put's them in the web-apps \bin
dir instead)?
- use full demands on public members I want to secure (but also user
asserts on my assembly code that calls these members to deal with stack-walk
issues)
- encrypt the Xml in my satellite resource assembly, and secure the method
that will provide a decrypted version of the resource
- use a publisher policy file(/assembly?) to enable me to update the
sattelite assembly containing the Xml resource without having to update my
other assemblies while using strong names for all assemblies


Have I got it right? Is there an easier way? At this point, I'm seriously
considering just packaging everything into a single assembly (.dll) to avoid
all the hassles.

 

[[MSFT]]

Hello,

As my understanding, you have a Web control and several sub assemblies
which will called by the web control. You want only the webcontrol can call
the sub assemblies. Is this right?

I think you may consider the StrongNameIdentityPermission Attribute for the
issue:

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/cpref/html/
frlrfsystemsecuritypermissionsstrongnameidentitypermissionattributeclasstopi
c.asp

For more about Code Access security:

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/cpguide/htm
l/cpconCodeAccessSecurity.asp

Hope this help,

Luke

 

[cpnet]

Hi Luke,

I have read the content at the links below (most of it is actually contained
in the books I mentioned). However, it seems that since these assemblies
have methods/classes that will be used by an ASP.NET application, then I
have to include the AllowPartiallyTrustedCallersAttribute in my assemblies.
But then it seems you get into link demands, and worrying about stack
walking etc. I'm not clear from this content, which of these things I need
to worry about to properly secure my assemblies, make sure only my own
assemblies can call certain public methods within my assemblies, make sure
that the ASP.NET app code can call my 'unsecured' public methods and so on.

To try and be more clear about the steps I think I need to take, I think I
need to:

- Mark my assemblies with APTCA (i.e. use the
AllowPartiallyTrustedCallersAttribute attribute)
- Strongly name my assemblies and have them installed in the GAC (but what
happens if the consumer of my controls just put's them in the web-apps \bin
dir instead)?
- use full demands (ie use the StrongNameIdentityPermission attribute) on
public members I want to secure (but also user
asserts on my assembly code that calls these members to deal with stack-walk
issues)
- encrypt the Xml in my satellite resource assembly, and secure the method
that will provide a decrypted version of the resource
- use a publisher policy file(/assembly?) to enable me to update the
sattelite assembly containing the Xml resource without having to update my
other assemblies while using strong names for all assemblies

Is all of the above necessary, or do I have anything wrong?

Thanks,
cpnet

 

[[MSFT]]

From the description. I think all of the steps listed are necessary for the
issue. By the way, when you put a strong named assembly in GAC, it can be
assecced by all application on the computer. If it was in web-apps \bin,
only the web app can access them directly. Other application need to know
the exact path to access it.

Luke

 

[cpnet]

Ok, thanks. I do realize that stuff in the GAC can be used by all apps, but
my understanding was that if I didn't put stuff in the GAC, then the strong
naming and security attrbutes etc. won't work properly. In other words, I
thought that to be able to use the StrongNameIdentityPermission attribute on
my public methods to ensure only my own assemblies can call these methods, I
had to put my assembiles in the GAC?

 

[[MSFT]]

GAC is just used for sharing an assembly among several applications. It is
not a pre-requisite for StrongNameIdentityPermission. Here is an article
about GAC:

Working with Assemblies and the Global Assembly Cache
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/cpguide/htm
l/cpconworkingwithassembliesglobalassemblycache.asp

You assembly should have a strong name, but can be out of GAC.

Luke

 

[cpnet]

Great, thanks.