Hosting ASP.NET Applications in Medium Trust
By Scott Mitchell
Introduction
Many independent developers and small companies building Internet-accessible web applications turn to web hosting companies
to host their website. Web hosting companies offer a variety of plans, from dedicated servers to shared plans. Shared plans,
which are the most economical and practical for low-traffic websites, can have anywhere from 25 to 150 separated websites
hosted from the same web server. When hosting multiple websites on the same server, it is important that one website cannot
affect or harm another site. For example, both the web hosting company and its (honest) customers want to prevent one
website from, say, reading the connect string information from Web.config of another website.
ASP.NET allows for web hosting companies to define trust levels, which dictate what operations are permitted by ASP.NET
applications. A web hosting company can either use one of the preset trust levels - Full, High, Medium, Low, or Minimal -
or can create a custom trust level. Full turst, which is the default, allows ASP.NET applications to execute native
code, to read from the Registry and Windows Event Log, and to read and write to files outside of the application's virtual
directory. In short, with full trust one web application could delete the entire contents of another web application!
Fortunately, most web hosting companies run in medium trust, which greatly reduces the potential for harm by limiting the
set of operations an ASP.NET application can perform. While the protection granted by medium trust is reassuring, its
limited functionality can be aggrevating for honest developers. In this article we'll look at how the trust-level is specified,
what functionality is limited by medium trust, and some techniques to work around these limitations. Read on to learn more!
Specifying Trust Levels
An ASP.NET application's trust level is specified in Web.config via the <trust> element:
<trust level="[Full|High|Medium|Low|Minimal]" />
The default trust level is Full, which grants unrestricted permissions. This is a dangerous trust level when working
in a shared environment because it allows one web application to interact with the file system of anothers. For example,
if you are in a shared environment that physically arranges its shared web applications in a common folder (i.e.,
C:\Inetpub\wwwroot\WebApplicationName1, C:\Inetpub\wwwroot\WebApplicationName2,
..., C:\Inetpub\wwwroot\WebApplicationNameN, and so on), one web application could use the following
code to display the Web.config contents of all of the other web applications on the server:
'Look for Web.config files in parent directories
Dim myPath As String = Request.PhysicalApplicationPath
Dim parentPath As String = String.Concat(myPath, "..\")
Dim parentPathInfo As New DirectoryInfo(parentPath)
For Each folder As DirectoryInfo In parentPathInfo.GetDirectories()
Dim fileOfInterest As String = Path.Combine(folder.FullName, "Web.config")
If File.Exists(fileOfInterest) Then
Dim webConfigReader As StreamReader = File.OpenText(fileOfInterest)
Response.Write(String.Format("<p><b>Data for File {0}:</b></p><p>{1}</p><hr />", fileOfInterest, _
Server.HtmlEncode(webConfigReader.ReadToEnd())))
webConfigReader.Close()
End If
Next
Since connection strings are usually placed in Web.config, the nefarious user running the above code would
now be able to connect to other customers' databases, where there might be sensitive customer information. The point is,
if an ASP.NET application is running in full trust, there's nothing to stop them from reading, creating, modifying,
or deleting files in your web application's file system.
Fortunately, most web hosting companies follow the advice in Microsoft's ASP.NET
2.0 Hosting Deployment Guide and place their shared web applications in medium trust. This is accomplished by modifying
the machine-level Web.config file in the %windir%\Microsoft.NET\Framework\{version}\CONFIG folder.
Moreover, this setting can be locked by the web hosting company. See How To:
Use Medium Trust in ASP.NET 2.0 for more information on setting the default trust level for a web server and how to lock
this setting. The good news is that if the setting is correctly locked in the machine-level Web.config file, a
web application hosted on the server cannot override the setting.
If you attempt to run the above code in a medium trust enviornment, a SecurityException will be thrown when
attempting to create a DirectoryInfo object on the parent path.
Medium Trust Permissions
If an application is placed in medium tust, it is limited in the operations it can perform. The How To:
Use Medium Trust in ASP.NET 2.0 article summarizes the main limitations as follows:
Limited FileIOPermissions: Only files within the application's virtual directory hierarchy can be accessed or modified.
Limited OleDbPermissions: the ADO.NET managed OLE DB data provider cannot be used to access databases.
Limited EventLogPermissions: you cannot access the Windows Event Log.
Limited WebPermission: you cannot make HTTP requests outside of your domain.
Limited RegistryPermission: you cannot access the Windows Registry.
Limited ReflectionPermission: you cannot use reflection.
Of course, a web hosting company may not necessarily be running strictly within medium trust. They may customize the permissions
to, say, allow OleDbPermissions so that their customers can work with the managed OLE DB provider. For a detailed understanding
of what permissions are allowed and which ones are denied, contact your web hosting company.
Working Around Medium Trust Limitations
If you are writing an application that may be used by others in a hosted environment, it is important to understand the
impact of medium trust and to strive to ensure that your application will work in medium trust. It is important to test
your application in a medium trust environment, which you can do by setting the <trust> element in
Web.config. If you are using a third-party component or application that requires certain permissions that
are typically denied when running in medium trust, your best bet it to contact your web hosting company and ask them to
customize your trust level so that your website can function properly.
Some code that is prohibited from running in medium trust can be replaced by similar code that is runnable under medium
trust. One such example is working with configuration information. Under medium trust you cannot use .NET's configuration
API to read elements within the <system.web> element in Web.config. This is because the
configuration API is not only inspecting your application's Web.config file, but also is examining configuration
information up the chain and therefore in areas that fall outside of your web application's virtual directory. However,
if you are only interested in the value(s) within the Web.config file in your application, you can read
the file using .NET's XML-related classes.
A concrete example of this can be seen in my skmValidator controls. Back in September 2006 I published an article titled
Creating Validator Controls for the CheckBox and CheckBoxList,
which looked at building a custom validation control for the CheckBox and CheckBoxList Web controls. For reasons that aren't
pertinent to this article, this control needed to determine whether the application was configured to emit legacy HTML.
By default, ASP.NET 2.0 applications emit XHTML, but they can be configured
to emit legacy HTML instead. This information can be set in the <xhtmlConformance> element in
Web.config.
In any event, I wrote the code so that it used .NET 2.0's configuration API:
This code worked fine when running in full trust (which is how I tested it), but failed in medium trust. Since I failed to
test in medium trust, I didn't catch this problem. I therefore wasn't aware of this problem until helpful reader Michael T.
pointed it out to me (along with a fix). The fix was to use .NET's XML-related classes to open and read the contents of
Web.config, searching for the <xhtmlConformance> element. Michael's code follows:
bool result;
try
{
string webConfigFile = Path.Combine(HttpContext.Current.Request.PhysicalApplicationPath, "web.config");
XmlTextReader webConfigReader = new XmlTextReader(new StreamReader(webConfigFile));
result = ((webConfigReader.ReadToFollowing("xhtmlConformance")) && (webConfigReader.GetAttribute("mode") == "Legacy"));
webConfigReader.Close();
}
catch
{
result = false;
}
return result;
Conclusion
Web hosting companies that offer shared plans typically force web applications to run in medium trust so as to prevent
one customer from purposefully or accidentally harming another customer's website. Medium trust disables access to the Registry,
and the Windows Event Log. It limits code from making external HTTP requests or modifying the file system outside
of the application's virtual directory hierarchy.
While the reduced permission set of medium trust helps protect ASP.NET applications in a shared environment, it can introduce
problems when integrating third-party applications that might not have been thoroughly tested to work in medium trust (or
who need to perform operations that simply cannot be done in medium trust). You may be able to circumvent some of these
limitations via alternate techniques, or you may have to contact your web host company and ask them to customize your trust level
so that such operations are possible.
