My blog has moved and can now be found at

No action is needed on your part if you are already subscribed to this blog via e-mail or its syndication feed.

Tuesday, April 27, 2004
« Upcoming Architecture Webcast on Shadowf... | Main | Improving .NET Application Performance a... »

On a list serve that I am on, a question was posed by a developer who is working with a hosting company that runs their ASP.NET webservers under a partial trust scenario.  The developer uses File I/O and Reflection within the control code for some functions.  The hosting company's recommendation to the developer was to ask that all of the controls be marked with the AllowPartiallyTrustedCallersAttribute (APTCA) attribute. The questions that were posed had to do with Code Access Security (CAS) under .NET 1.0 and 1.1 as well exactly what AllowPartiallyTrustedCallersAttribute (APTCA) does.

It was an interesting question and may be something that pops up more and more in the future, so I thought I would share the answer that I gave. Comments and corrections are very welcome.

ASP.NET Web Applications under .NET 1.0 run with FullTrust privileges (i.e. They are no way constrained by CAS). The concept of the “trust“ element simply did NOT exist in 1.0.  Only .NET 1.1 will allow you to run ASP.NET Web Applications under a partial trust scenario.

The basic concept behind AllowPartiallyTrustedCallersAttribute (APTCA) is that:

  • An assembly that has a strong name cannot, by default, be called by a partial trust assembly (i.e. an assembly that has not been granted Full Trust privileges). So by default, an ASP.NET Web Application that is running in a partial trust scenario cannot call a strongly named assembly.
  • The only way a partial trust assembly/ASP.NET Web App running under partial trust can call an assembly with a strong name is if the strong named assembly is marked with the APTCA.

BTW, Web Applications built on .NET 1.0 always run with full trust because the types in System.Web 1.0 demand full trust callers.  In .NET 1.1, the System.Web, System.Web.Services, System.XML and some others are marked with APTCA, so they can actually be called from a partially trusted ASP.NET Application.

So one of the basic approaches to running an application under partial trust is:

  • The ASP.NET Policy files grant full trust to any assembly that is located in the GAC.
  • Put your code that accesses the privileged resource in a wrapper assembly that is then strongly named so that it can be installed in the GAC.
  • The wrapper assembly, because it is in the GAC and has full trust can now call the privileged resource.
  • Mark the wrapper assembly with APTCA
  • Because the wrapper has been marked with APTCA, the ASP.NET application which is running under partial trust can actually call it.
  • In short, Web App cannot call the privileged resource directly, but can call the wrapper which in turn can the privileged resource.
Of course the thing to note is the gaping security hole in the above sequence. What is stopping every Tom, Dick and Jane from calling the wrapper assembly?  This is where Demands and Assertions come in.
So what exactly is a Demand?

If you have an assembly that calls a class from the .NET Framework that in turn accesses a privileged resource, that .NET class will "demand" the following? "Do you have the permission to access  me?" This is appropriately enough called "Issuing a permission demand".

At this point, what I think of as the Enforcer comes into the picture. The Enforcer is the .NET runtime.  Now the Enforcer does not just check the assembly that actually called the .NET Class. It checks everything up the call stack! i.e. It demands the permissions of not just your assembly, but that of the assembly/code that called your assembly as well.  This is known as "Walking the Stack", whereby the runtime examines the permissions of each caller in the stack and if ANY of those callers do not have the required permission, a SecurityException is thrown.

BTW, there is a variation on this called a Link Demand. In this case the Enforcer does not do a full stack walk, but simply checks the permissions of the immediate caller.  There are security implications to this as you need to be particularly aware of possible luring attacks.

Assert, Deny and PermitOnly methods of the Code Access permissions modify the behavior of the above mentioned Stack Walk.

Assert is of particular importance here. When you call the CAS.Assert method in your assembly, you stop the stack walk from moving any further up the call chain. In essence what you are doing is vouching for the trustworthiness of ANY of your code's callers. This needs to be used with a great deal of caution.

So what you should be doing in the above scenario is demand an alternate permission so that the runtime can authorize the calling code prior to calling assert.

And that in essence is the Sandboxing pattern for developing partial trust web apps.

Regarding the request from the hosting company.. Strongly naming the assembly, marking it with APTCA, and putting it in the \bin really does not do anything.. Because the assembly would NOT be fully trusted, it could not call the FileIOPermission or the ReflectionPermission, the first of which is Privileged Code and the second of which is a Privileged Operation.

Now if the control assembly was strongly named, marked with APTCA, and installed in the GAC, it would under the ASP.NET policy be running with Full Trust and would have such permissions.  But I am unsure if the hosting company would allow the installation of GAC'd assemblies.
Another option of course is customizing the policy to grant the required permission to the particular web app. But since this was a hosting scenario, I disregarded it as I would not be surprised if the hosting company had pretty strict restrictions as far as changes to default policies were concerned.
BTW, this info and a lot more are documented very thoroughly in Chapters 6-9 of "Improving Web Application Security: Threats and Countermeasures" from the Microsoft PAG :-)

[Now Playing: Ek Kunwara Phir Gaya Mara - Masti]

Tags:: Security
4/27/2004 11:59 PM Eastern Daylight Time  |  Comments [4]  |  Disclaimer  |  Permalink   
Sunday, May 8, 2005 12:06:46 AM (Eastern Daylight Time, UTC-04:00)
Sunday, May 8, 2005 12:06:46 AM (Eastern Daylight Time, UTC-04:00)
Robert Hurlbut's .Net Blog
Sunday, May 8, 2005 12:06:46 AM (Eastern Daylight Time, UTC-04:00)
Take a look at the videos from the OWASP Conference with videos of partial trust in operation !
<br>He has a 185 page Undocumented ASP.NET security on the subject.
<br>The OWASP ANSA toool was written to check and analyze exactly this issue.
<br>Enjoy !
Take a look at Dinis Cruz's work...
Sunday, May 8, 2005 12:06:46 AM (Eastern Daylight Time, UTC-04:00)
Respected sir,
<br> I visited your site,it is just wonderful and i got so much useful messages from this.I need some interview questions on which are frequently asked in interviews.I will be glad f you send me a reply.
<br>thanking you sir,
<br>yours truly,
<br>sreekanth.j (
Comments are closed.