One of the most important security principles for software development is least privilege.
Simply put, least privilege means that an application, process, or user should have the least access to resources required to accomplish a task and no more. By following this principle, even if your application is attacked or a user goes on the payroll of your nastiest competitor, you'll have limited the potential damage. Bottom line: implementing partial trust in ASP.NET is the single biggest thing you can do to make your applications secure.
ASP.NET has some powerful tools for implementing the principle of least privilege in your applications. But developers often do not use partial trust techniques, which never ceases to surprise me. Sure, the techniques require understanding security and how ASP.NET implements code access security, but isn't that pretty much a prerequisite these days for secure ASP.NET development? (The answer is Yes! in case you weren't sure.) Sure, partial trust techniques take a little more work, but by the end of this article you'll understand that it isn't all that much more work.
Even though the default trust level in ASP.NET is Full trust (an evil choice of Microsoft's in my opinion), you should never deploy a real, non-trivial application that way. But what are the other options? What do you have to give up to become more secure?
This article looks at how to create partially trusted web applications, but not by using any of the poorly fitting standard trust levels included with .NET out of the box. Instead I'll show you two easy techniques to make your ASP.NET applications substantially more secure. The first technique demonstrates how to create a custom trust level, tailored to the needs of a specific application to offer maximum protection. The second technique shows you how to segregate dangerous code—code that needs a higher privilege level to perform some specific action—into a protected sandbox. You'll commonly use a combination of these techniques for the highest level of security.
Along the way I'll explore permissions and how ASP.NET implements the Common Language Runtime's (CLR) code access security (CAS) to implement its trust levels. I assume that you know at least the basics of code access security and .NET permissions, as well as how to put together and run ASP.NET applications. You should also be familiar with how .NET configuration files work, understand the roles of machine.config and the machine-wide root web.config file, and application configuration files.
I'll begin with a short overview about partial trust, code access security, and why they are so critical to secure ASP.NET applications. Bear with me through this next section: I'll cover some important points for understanding partial trust, and then I'll dive deep into configurations and code.