Securing Browser Definition Files
Browser definition files (.browser files) contain information about the capabilities of classes of browsers (such as Internet Explorer) and specific browsers (such as Internet Explorer 6.0). At run time, ASP.NET uses the information in .browser files to determine what browser has made the request, what capabilities the browser has, and how to render markup to that browser. For more information, see Browser Definition File Schema (browsers Element).
For detailed information about best practices for writing secure code and securing applications, see the book "Writing Secure Code" by Michael Howard and David LeBlanc, and see the guidance provided by Microsoft Patterns and Practices.
Note
Browser definition files are new in the .NET Framework version 2.0. In earlier versions of the .NET Framework, the browserCaps element was used to define browser definitions in configuration files.
Browser Definition File Security
All browser capability features, including the .NET Framework classes and the browser definition files, require partial trust at the application level, and require full trust at the global level. The global browser definition assembly is signed with a unique machine key before placement in the global assembly cache and cannot be tampered with. The browser definition files in the %SystemRoot%\Microsoft.NET\Framework\version\CONFIG\Browsers directory are protected by access control lists (ACLs) and require administrative privileges to modify.
Browser Definition File Directories
The global Browser directory and the application-level App_Browsers subdirectory should contain only files with the file name extension .browser. Only .browser files are compiled by the ASP.NET browser capabilities feature. Additionally, ASP.NET protects the files in these directories from being served by the Web server and from being accessed by code in other applications.
Browser Definition Files ACLs
The following table lists the ACLs that are set by default on the .browser files located in the %SystemRoot%\Microsoft.NET\Framework\version\CONFIG\Browsers directory. These ACLs are also set on the directory itself, but they include Modify permissions for the CREATOR OWNER group. The directory is read only.
Windows account |
Permissions |
|---|---|
Administrators |
Full control |
ASP.NET Machine Account (<server>\ASPNET) |
Read and Execute |
CREATOR OWNER |
Full control |
IIS_WPG (<server>\IIS_WPG) |
Read and Execute |
LOCAL SERVICE |
Read and Execute |
NETWORK SERVICE |
Read and Execute |
Power Users (<server>\Power Users) |
Modify |
SYSTEM |
Full control |
Users (<server>\Users) |
Read and Execute |
The following table lists the ACLs that should be set on application-level .browser files in the App_Browsers subdirectory.
Windows account |
Permissions |
|---|---|
Administrators |
Full control |
IIS_WPG (<server>\IIS_WPG) |
Read and Execute |
INTERACTIVE |
Read |
Internet Guest Account (<server>\IUSR_<server>) |
Read |
NETWORK |
Read |
NETWORK SERVICE |
Read |
SYSTEM |
Full control |
Users (<server>\Users) |
Read and Execute |
Special |
Adding Browser Definition Files
Do not download or install browser definition files unless you trust their source. For example, examine a new browser definition file to see if any unfamiliar namespaces are referenced in any of the following attributes:
The markupTextWriterType attribute of the controlAdapters element.
The value attribute of the capability element.
The controlType and adapterType attributes of the adapter element.
For information about valid elements and attributes, see Browser Definition File Schema (browsers Element).
Changing Browser Definition Files
If you add new browser definition files to the global directory or if you make changes to global browser definition files, those changes have no effect until you manually recompile the browser capabilities collection using the Aspnet_regbrowsers.exe tool, available in the %SystemRoot%\Microsoft.NET\Framework\version folder, or programmatically cause recompilation by using the BrowserCapabilitiesCodeGenerator class.
However, you do not need to recompile changes to application-level browser definitions. Changes to those definitions are recompiled and reapplied dynamically.
Securing Browser Definition Files in a Shared Hosting Environment
In a shared hosting environment, malicious users can potentially modify browser definition file settings through direct modification of the browser definition files, modification via the configuration APIs, and other administration and configuration tools. To mitigate this threat, maintain strong ACLs on browser definition files. The contents of browser definition file directories are compiled, therefore they should be protected in the same way as any other code directory in the application. If a user is prevented by the host administrator from adding code to an application, the user should also be prevented from adding browser definition files.
Holding a File-Lock on a Browser Definition File
Only multiple attempts to save to a browser definition file or open a file handle can lock a browser definition file. A malicious user might attempt to lock the browser definition files in the %SystemRoot%\Microsoft.NET\Framework\version\CONFIG\Browsers directory. However, locking a browser definition file requires Full trust, which is disabled in ASP.NET by default.
Using the Configuration API to Read Arbitrary Files
The classes of the browser definition configuration API cannot read any directories that are not part of the application domain, or any files that do not have a .browser file name extension.
Caching Browser Capabilities
At run time, browser definition file information is merged into a collection of known browsers in a BrowserCapabilitiesFactory object. When a request is made, ASP.NET identifies the requesting browser by the request header and compiles an HttpCapabilitiesBase object that corresponds to the requesting browser. The object is cached and might be used again for a different request made by the same browser.
A malicious client might try to flood your Web server with requests where each new request uses a different request header, causing ASP.NET to generate and cache browser capability objects for each request, which in turn can result in a denial-of-service attack. To mitigate this threat, configure the userAgentCacheKeyLength attribute of the browserCaps Element (ASP.NET Settings Schema) element in the Machine.config file or a Web.config file. This element defines the character length to use as the key to identify cached capabilities objects in the internal cache. The default is 64. You can reduce this value to make it more likely that a matching browser will be found in the cache, reducing the load on the cache.
Exceptions
To help prevent sensitive information from being exposed to unwanted sources, configure your application either not to display detailed error messages or to display detailed error messages only when the client is the Web server itself. For more information, see customErrors Element (ASP.NET Settings Schema).
Event Log
If your server is running Windows Server 2003, you can improve the security of your application by securing the event log and by setting parameters regarding the size, retention, and other features of the event log to help prevent an indirect denial of service attack. For more information about configuring event logs, search for "Event Viewer" in Windows Help and Support.
See Also
Tasks
How to: Detect Browser Types in ASP.NET Web Pages
Concepts
ASP.NET Web Server Controls and Browser Capabilities
Securing Browser Definition Files
ASP.NET Configuration Scenarios
ASP.NET Device Filtering Overview
Architectural Overview of Adaptive Control Behavior
ASP.NET Mobile Web Development Overview
Securing ASP.NET Configuration
Reference
Browser Definition File Schema (browsers Element)