Machine.Config and Web.Config Guidelines


Settings in Machine.config apply machine-level defaults for your server. Where you want to enforce a particular configuration for all applications on your server, use allowOverride="false" on the <location> element as described above. This is particularly appropriate for hosting scenarios, where you need to enforce aspects of security policy for all applications on the server.

For those settings that can be configured on an individual application basis, it is normal for the application to provide a Web.config file. While it is possible to configure individual applications from Machine.config using multiple <location> elements, separate Web.config files provide deployment advantages and lead to smaller Machine.config files.

The main item to consider is which settings should be enforced by machine policy. This depends on your specific scenario. Some common scenarios follow:

  • Windows authentication . Consider a corporate intranet portal scenario where you want authentication to be abstracted away from the application and controlled by the organization through Active Directory. In this scenario, you can enforce Windows authentication, but allow individual applications to impersonate with the following configuration:

     <location path="" allowOverride="false">   <system.web>     <authentication mode="Windows"/>   </system.web> </location> 
  • Hosting scenario . Hosting companies need to constrain applications so they cannot access each other's resources and so that they have limited access to critical system resources. To do so, you can configure all applications to run at a partial-trust level. For example, the medium-trust level constrains an application so that it can only access files within its own virtual directory hierarchy and restricts access to other types of resources. For more information, see Chapter 9, "Using Code Access Security with ASP.NET." To apply a medium-trust policy for all applications on your server, use the following configuration:

     <location path="" allowOverride="false>   <system.web>     <trust level="Medium" />   </system.web> </location> 

ACLs and Permissions

Configuration files contain sensitive data and therefore require appropriately configured ACLs to restrict access.

Machine.config

By default, Machine.config is configured with the following ACL:

 Administrators: Full Control System: Full Control Power Users: Modify Users: Read and Execute LocalMachine\ASPNET (process identity): Read and Execute 
Note  

On Windows Server 2003, the Local Service and Network Service accounts are also granted read access.

Members of the Users group are granted read access by default, since all managed code that runs on the computer must be able to read Machine.config.

The default ACL on Machine.config is a secure default. If, however, you only have a single Web application running on the server, or all of your Web applications use the same process identity, you can further restrict the ACL by removing the user 's access control entry (ACE). If you do remove "users" from the DACL, you need to explicitly add the Web process identity.

Web.config

The .NET Framework does not install any Web.config files. If you install an application that supplies its own Web.config, it usually inherits its ACL from the inetpub directory, which by default grants read access to members of the Everyone group. To lock down an application-specific Web.config, use one the following ACLs.

For .NET Framework version 1.0:

 Administrators: Full control System: Full control ASP.NET process identity: Read UNC Identity: Read Impersonated Identity (Fixed Identity): Read Impersonated Identity (Original Caller): Read 

For .NET Framework version 1.1:

 Administrators: Full control System: Full control ASP.NET process identity: Read UNC Identity: Read Impersonated Identity (Fixed Identity): Read 

If your applications use impersonation of a n explicit account (that is, if they impersonate a a fixed identity), such as <identity impersonate="true" username="WebUser" password="Y0urStr0ngPassw0rd$"/> , then both that account (WebUser, in this case) and the process need Read access.

If your code base is on a Universal Naming Convention (UNC) share, you must grant read access to the IIS-provided UNC token identity.

If you are impersonating but not using explicit credentials, such as <identity impersonate="true"/> , and no UNC, then only the process should need access in the .NET Framework 1.1. For the .NET Framework 1.0, you must additionally configure the ACL to grant read access to any identity that will be impersonated (that is, you must grant read access to the original caller).




Improving Web Application Security. Threats and Countermeasures
Improving Web Application Security: Threats and Countermeasures
ISBN: 0735618429
EAN: 2147483647
Year: 2003
Pages: 613

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net