Secure ASP.NET
Is requirePermission a Hack or a Useful Feature?
By Don Kiely
Over the last few years in this column I ve explored how writing partial trust ASP.NET applications is reasonably straightforward. Microsoft has provided .NET developers plenty of tools for utilizing code access security so that an assembly can have restricted permissions based on its evidence. Even if a user has full administrative rights on the local machine, an assembly may not be able to make full use of resources because, for example, it is running from an untrusted location (such as the Internet).
As you write more sophisticated partial trust ASP.NET applications, you ll start bumping into some of what seem like idiosyncrasies of code access security and trust levels in ASP.NET. One in particular came to my attention recently through Rick Stahl s blog post titled ConfigSection Security. I encourage you to go read it, but the quick summary is that after developing some code used in an ASP.NET application, he tested it under the standard Medium trust level. That broke some things, including the ability to access custom configuration sections.
As Rick discovered, the required System.Configuration.ConfigurationPermission is only included with the Full and High standard trust levels. If you use the recommended Medium trust level for your ASP.NET application or create a custom trust level based on the Medium trust level your assembly by default won t have that permission. Any attempt to access a custom configuration section at the Medium or lower trust levels will result in a SecurityException.
The normal solution to this kind of problem is to create a custom trust level and include the permission. But unless you sandbox the code that accesses configuration sections, this means that the entire assembly will have the ConfigurationPermission. This violates the principle of least privilege, limiting what code can do to that which is absolutely necessary. Put another way, it unnecessarily opens security holes in your application and potentially exposes sensitive information you ve saved in the custom configuration section.
To get around the necessity of granting an entire assembly this permission, in .NET 2.0 Microsoft added a new attribute to the <section> element of configuration files: requirePermission. This attribute is set to true by default, but by setting it to false you tell the CLR to bypass checking whether the assembly has the ConfigurationPermission. Now, no matter what trust level your application is running with, it can read the section and you haven t granted any extraordinary permission to all your code.
By the way, the default machine.config file sets requirePermission to false in a few of its standard sections: appSettings, connectionStrings, and xmlSerializer. This is why you can access those sections without heightened permission.
The caution here is that you shouldn t use requirePermission with sections that have sensitive information. Doing so could result in exposing secrets to hostile code.
But Is It Secure?
So requirePermission is a useful addition to ASP.NET 2.0, getting around some gnarly problems. But is it secure? By setting requirePermission to true, you re essentially telling the CLR to let any and all code access the data stored in the configuration section. On the surface, this seems to be a Bad Thing, because it potentially opens up the contents of the configuration section to hostile code. On the other hand, your ASP.NET code, no matter its trust level, has to have access to the section in order to run properly. And on the third hand, because ConfigurationPermission is an all or nothing permission full or not at all you can fine tune access to configuration sections by using requirePermission.
I have to admit that requirePermission set to true makes me nervous. Typically, I d much rather create a custom trust level instead of circumventing the CLR this way. That way, you have much more control over access to the section. But if the section doesn t contain important secrets, the attribute can be a great way to fine tune code access to configuration sections.
By the way, if you do ASP.NET development and haven t added Rick Stahl s blog to your RSS reader, you re missing out on some incredible information!
Don Kiely, MVP, MCSD, is a senior technology consultant, building custom applications as well as providing business and technology consulting services. His development work involves tools such as SQL Server, Visual Basic, C#, ASP.NET, and Microsoft Office. He writes regularly for several trade journals, and trains developers in database and .NET technologies. You can reach Don at mailto:[email protected] and read his blog at http://www.sqljunkies.com/weblog/donkiely/.
