ASP.NET applications are made of managed code and run inside the Common Language Runtime (CLR). In the CLR, running code is assigned to a security zone based on the evidence it provides about its origin—typically, the original URL. Each security zone corresponds to a set of permissions and each set of permissions correspond to a trust level. In the default case, ASP.NET applications run from the MyComputer zone with full trust. Are fully trusted applications a bad thing?
The real problem is not with the ASP.NET application itself, but rather with the fact that the application is publicly exposed over the Internet—one of the most hostile environments ever. A hacker who succeeds in taking control of a fully trusted ASP.NET presents himself to the server platform as a fully trusted client. The risk with a fully trusted ASP.NET application is that it can become a potential and trusted platform for hackers to launch attacks.
Being fully trusted, ASP.NET applications are allowed to do whatever their account is allowed to do. Changing the worker process account is not recommended—although it is a perfectly legitimate action—so changing the trust level is the only option left to reduce the attack surface.
You can configure security permissions for an ASP.NET application by tweaking the <trust> section in the root web.config file. In this way, you can decide whether it has to run fully or partially trusted. The following snippet shows how to scale the trust level down to Medium trust:
<trust level="Medium" originUrl="" />
Feasible values for the level attribute are Full, High, Medium, Low, and Minimal. Full trust means that an application can execute arbitrary native code in the process context in which it runs. This is the default setting. High trust is only a bit more restrictive than Full trust and is appropriate for applications you want to run with lower privilege to mitigate risks. Introduced with ASP.NET 1.1, Medium trusted code can read and write its own application directories and can interact with databases. Low trust code can read its own application resources but can't interact with resources located outside of the application space. Finally, Minimal trust code can't interact with any protected resources and is appropriate for nonprofessional hosting sites that simply intend to support generic HTML code and highly isolated business logic.
Let's review more in detail the capabilities of an application when it runs with a Medium privilege. By rule of thumb, in fact, Medium trust should be fine for most ASP.NET applications and applying it shouldn't cause significant headaches. Medium applications have unrestricted access to SQL Server, provided that a non-blank password is used. Access to other Web resources is allowed as long as the target URL is indicated through the originUrl attribute in the <trust> tag.
What if one of the tasks to perform requires privileges that the trust level doesn't grant? The simplest thing you can do is customize the policy file for the trust level and add any permissions that are missing. No code changes are required, but administrator rights are needed to edit the security policy file. From a security point of view, this approach is flawed and opens security holes. Instead, you can delegate to external components the execution of any task that exceeds the current permission set. The external component can be a serviced component or a command-line tool having all required permissions. This technique is known as sandboxing.
Not all assemblies allow callers that are less than fully trusted. If your ASP.NET application has to place calls into one of such assemblies (that is, an assembly that doesn't include the AllowPartiallyTrustedCallers attribute) code sandboxing is the only option you have.
Dino Esposito is Wintellect's ADO.NET and XML expert, and a trainer and consultant
based in Rome, Italy. Dino is a contributing editor to Windows Developer
Network and MSDN Magazine, and the author of several books for Microsoft
Press including Building Web Solutions with ASP.NET and ADO.NET
and Applied XML Programming for .NET. Contact Dino at [email protected].
