Running ASP.NET in a Shared Hosting Environment
I was recently working on an issue with a large international hosting company. This company hosts many websites in a shared hosting environment, and one of their customers had uploaded a page that performed some tasks using ASP.NET that greatly concerned them.
The ASP.NET page allowed the following when it was browsed:
- Browsing of files in the Windows directory using the System.IO namespace.
- Browsing of folders in the Program Files directory using the System.IO namespace.
- Browsing of files in the System32 directory using the System.IO namespace.
- Output of the OS name and version number using the Environment class.
- Output of the physical disk path (including one on an external file server) for the website's content using Server.MapPath.
- Output of the server's local IP address using server variables.
These capabilities are not unique to ASP.NET. Most server-side programming technologies allow for the same functionality. However, my customer was concerned over exposing this much information about his internal environment and he wanted me to do something about it!
As you certainly know, ASP.NET runs inside of the CLR (Common Language Runtime), and because of that, ASP.NET is able to take advantage of the CLR's capabilities. One of those capabilities is a powerful security architecture that makes it easy to define the capabilities of a .NET Framework application.
By default, ASP.NET runs under full trust. That means that an ASP.NET application has a lot of powerful functionality, some of which might not be desirable in a shared hosting environment. The solution to my customer's problem was to change ASP.NET to run under medium trust. When running under medium trust, an ASP.NET application runs in a much more restricted environment. Among other restrictions, running under medium trust prevents an ASP.NET application from accessing any directories outside of the application's own directory structure.
To run ASP.NET under medium trust, a simple change is made to the default web.config file located in the Microsoft.NET\Framework\v2.0.50727\Config folder. The specific change you should make is in the following section.
<location allowOverride="true">
<system.web>
<securityPolicy>
<trustLevel name="Full" policyFile="internal"/>
<trustLevel name="High"
policyFile="web_hightrust.config"/>
<trustLevel name="Medium"
policyFile="web_mediumtrust.config"/>
<trustLevel name="Low"
policyFile="web_lowtrust.config"/>
<trustLevel name="Minimal"
policyFile="web_minimaltrust.config"/>
</securityPolicy>
<trust level="Full" originUrl=""/>
</system.web>
</location>
The first change you'll want to make is to set the allowOverride attribute to false. By making that change, you prevent an ASP.NET developer from overriding your change in his or her own web.config file. After making that change, you'll need to change the trust level from Full to Medium. Once you'd made those changes, the new section looks like the following. Changes appear in bold text.
<location allowOverride="false">
<system.web>
<securityPolicy>
<trustLevel name="Full" policyFile="internal"/>
<trustLevel name="High"
policyFile="web_hightrust.config"/>
<trustLevel name="Medium"
policyFile="web_mediumtrust.config"/>
<trustLevel name="Low"
policyFile="web_lowtrust.config"/>
<trustLevel name="Minimal"
policyFile="web_minimaltrust.config"/>
</securityPolicy>
<trust level="Medium" originUrl=""/>
</system.web>
</location>
Notice that the <trustLevel> element defines which configuration file contains the specific configuration settings for the specific trust level. The configuration for medium trust is contained a file called web_mediumtrust.config which is also located in the Config folder.
You can modify the web_mediumtrust.config file if you want more precise control over your security model. For example, my customer was concerned that ASP.NET developers were able to use the Environment class to access the OS name and the computer's netbios name. I was able to resolve that for him by making a modification to the ASP.NET permission set in the web_mediumtrust.config file.
<IPermission
class="EnvironmentPermission"
version="1"
Read="TEMP;TMP;USERNAME;OS;COMPUTERNAME"
/>
By removing OS and COMPUTERNAME from the Read attribute of this element, I was able to prevent ASP.NET developers from accessing the information that concerned my customer.
You can read more about other limitations that this method imposes along with many more details in the following MSDN article.
http://msdn2.microsoft.com/en-us/library/ms998341.aspx
If you're interested in performing these same steps in ASP.NET 1.1, you can get details on doing so by watching the following video.
http://msdn.microsoft.com/msdntv/episode.aspx?xml=episodes/en/20050317ASPNETSS/manifest.xml
Jim
