Select the product you need help with
ASP.NET Partial Trust does not guarantee application isolationArticle ID: 2698981 - View products that this article applies to. On This PageINTRODUCTIONASP.NET lets administrators host applications in partial trust modes such as medium trust. It also allows for the configuration of custom partial trust levels through custom policy files. For more information about how to use medium trust in ASP.NET 2.0, go to the following Microsoft Developer Network (MSDN) webpage: How To: Use Medium Trust in ASP.NET 2.0 We previously described ASP.NET partial trust as a mechanism for enforcing application isolation in a shared hosting environment in which multiple applications that have different trust levels are hosted on the same web server. We are updating our guidance about this to reflect that running an ASP.NET page framework application in partial trust does not guarantee complete isolation from other applications that are running in the same process or on the same computer.
(http://msdn.microsoft.com/en-us/library/ff648344.aspx)
Configuring ASP.NET page framework applications to run in separate low-privileged processes (by using individual application pools) is the recommended procedure to make sure of isolation from other ASP.NET page framework applications on the same web server. The following section provides details about how to configure applications for isolation. We are updating our other documentation to reflect the change in policy that is outlined in this article. MORE INFORMATIONServer administrators should apply the guidelines in this article to make sure that applications are isolated in shared hosting environments. These guidelines apply to hosting ASP.NET on Windows Server 2003 SP2 and later versions. The guidelines cover Internet Information Services (IIS) 6.0 to 7.5. Many of the tasks that are outlined here can be automated by using the AppCmd.exe
(http://learn.iis.net/page.aspx/114/getting-started-with-appcmdexe)
IIS command line tool in IIS 7 and 7.5 and by using IIS administration scripts
(http://www.microsoft.com/technet/prodtechnol/WindowsServer2003/Library/IIS/1805162e-6ac5-4a98-9a08-919c4c10827d.mspx?mfr=true)
in IIS 6.0.
How to put applications in separate IIS sitesIn a shared hosting environment, applications should be put in separate IIS sites. Configuration is better isolated between applications when they are hosted in separate sites. In addition, the .NET Framework CLR host will be separate. This provides additional isolation at that level.To put each application in a separate site, follow these steps: Internet Information Services 6.0 (Windows Server 2003 SP2)
Internet Information Services 7 (Windows Vista SP2 and Windows Server 2008 SP1) and Internet Information Services 7.5 (Windows 7 and Windows Server 2008 R2)
How to put sites in separate application poolsIn a shared hosting environment, applications should be put in separate application pools. This allows for applications to be isolated into separate operating system processes with unique identities. This provides a level of isolation from one site to another. (The following section describes how to configure application pool identities for isolation.)Internet Information Services 6.0 (Windows Server 2003 SP2)
Internet Information Services 7 (Windows Vista SP2 and Windows Server 2008 SP1) and Internet Information Services 7.5 (Windows 7 and Windows Server 2008 R2)After you follow the steps in the "How to put applications in separate IIS sites," section, the new site is automatically put in a new, separate application pool. However, if you have to configure an existing site to use a new, separate application pool, follow these steps:
How to configure application pools for isolation (process identity)Application pools host applications and sites in a Windows process (or processes). The identity under which the process runs is configurable. In a shared hosting environment, there should be a separate identity for each application. This makes sure that each application is running in the context of a unique account. This allows for correct isolation by using file-system discretionary access control lists (DACL) and the built-in process isolation features of the underlying operating system. To create a user account and then assign an application pool to use that account, follow these steps.Internet Information Services 6.0 (Windows Server 2003 SP2)Create a local user account to use as the application pool identity
Configure the application pool to use the new local user account
Internet Information Services 7 and 7.5 (Windows Vista SP2, Windows Server 2008 SP1, Windows 7 and Windows Server 2008 R2)
How to configure DACLs on application content locationsThe discretionary access control list (DACL) is a list of permissions that are associated with an object and that can be used to control access to the object. Using DACLs to restrict access to application content helps strengthen the isolation between sites that are hosted on the same web server. For more information about ACLs and IIS identities, see Secure Content in IIS Through File System ACLs
(http://learn.iis.net/page.aspx/583/secure-content-in-iis-through-file-system-acls)
All versions of IIS
Internet Information Services 6.0 (Windows Server 2003 SP2)
Internet Information Services 7 and 7.5 (Windows Vista SP2, Windows Server 2008 SP1, Windows 7 and Windows Server 2008 R2)
How to configure a Temporary ASP.NET Files folder location and how to set DACLs per siteASP.NET requires a location on the server to store temporary data such as compiled files. This is usually the Temporary ASP.NET Files folder. By default, this folder is under the folder where the .NET Framework is installed. Allocating a different temporary location for each site and securing the folder individually appropriately helps strengthen the isolation between sites that are hosted on the same web server. For more information about the Temporary ASP.NET Files folder, see Understanding ASP.NET Dynamic Compilation
(http://msdn.microsoft.com/en-us/library/ms366723.aspx)
.
How to configure a different Temporary ASP.NET Files folder location for each site
How to set appropriate DACLs on the Temporary ASP.NET Files folder location
How to remove sensitive configuration data from root configuration filesApplication web.config files are located in the content folder for the application that is being served. Even though ASP.NET will not serve the application web.config file, when it is practical, it is better to put security-sensitive information such as machine-key settings and connection strings in a configuration file that is outside the application location. This adds a defense against information disclosure.Internet Information Services 6.0 (Windows Server 2003 SP2)Storing security-sensitive configuration information in the root web.config file is not a good option for isolating data between different sites, because all sites have read access to this file. Therefore, on IIS 6 you should store sensitive configuration in your application web.config file. This lets sites isolate sensitive configuration from one another. In that case, your application will be relying on ASP.NET defenses to prevent the application web.config file from being served and to make sure that sensitive information is not disclosed.Internet Information Services 7 and 7.5 (Windows Vista SP2, Windows Server 2008 SP1, Windows 7 and Windows Server 2008 R2)For IIS 7 and later versions, move the sensitive configuration that is in the IIS applicationHost.config file into a <location> element that scopes the configuration to the site to which it applies. For more information, see How to Use Locking in IIS 7.0 Configuration
(http://learn.iis.net/page.aspx/145/how-to-use-locking-in-iis-configuration/)
.
Microsoft thanks
(http://technet.microsoft.com/en-us/security/bulletin/policy)
the following people for working with us to help protect customers:
Properties | Article Translations
|


Back to the top








