Securing ASP.NET Site Navigation
ASP.NET site navigation provides functionality for maintaining a central store of links to all the pages of a Web site. The links can then be rendered as lists or as navigation menus on each page by including a specific Web server control.
ASP.NET site navigation is most commonly used with navigation controls, such as the SiteMapPath, SiteMapDataSource, TreeView, and Menu controls; or it is used programmatically with the SiteMap and SiteMapProvider classes. The information in this topic describes how to improve the security of the navigation features.
While following coding and configuration best practices can help improve the security of your application, it is also important that you continually keep your application server up to date with the latest security updates for Microsoft Windows and Internet Information Services (IIS), as well as any updates for Microsoft SQL Server or other membership data sources. For more information, see the Windows Update Web site.
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 on the Microsoft Patterns and Practices Web site. Also, see Basic Security Practices for Web Applications.
The ASP.NET site-navigation features are enabled by default. They can be disabled by setting the enabled attribute for the siteMap element to false in the configuration file (Web.config). The following section discusses securing navigation-related data in the Web.config file. For information about navigation configuration settings and their default values, see siteMap Element (ASP.NET Settings Schema).
Securing Configuration Values
You do not need to secure navigation configuration settings that are contained in a Web.config file if you use the default ASP.NET site-map provider. However, if you implement a custom site-map provider that uses a database and you store the database connection string in a configuration file, follow the recommendations in Securing Data Access to encrypt the connection string.
In a hosted environment, the configuration file should deny override rights for the siteMap Element (ASP.NET Settings Schema) element to help prevent someone from reconfiguring the site to use a different site map or site-map provider. For more information, see Locking Configuration Settings. Also, see ASP.NET Application Security in Hosted Environments.
URLs can be mapped in a configuration file to a friendly URL by using the urlMappings Element (ASP.NET Settings Schema) element in the Web.config file. ASP.NET only allows application-relative syntax, for example, ~/filename.aspx. In other words, ASP.NET does not allow mapped URLs to point to a page that is outside of the application. This helps protect against any attempts by an ISP client to view a page that is outside of their application in a hosted environment.
By default, ASP.NET is configured to protect files with known file name extensions — such as .sitemap — from being downloaded by a client. To help protect your data, place any custom site-map data files that have a file name extension other than .sitemap in the App_Data folder and apply the appropriate access control lists (ACLs). For example, on Windows 2000 or Windows XP, grant the ASP.NET process account read-only access. On Windows 2003, grant the Network Service read-only access. For more information, see ASP.NET Required Access Control Lists (ACLs).
ASP.NET site navigation will only load a site-map file if the file exists in the directory structure of the application. This helps protect applications in a hosted environment from having their site-map data loaded by another application.
ASP.NET site navigation does not allow access to files outside of the directory structure of the application. If a site map contains a node that references another site-map file, and the file location is outside of the application, an exception occurs. The exception contains the path that is specified in the SiteMapNode, listing it as outside of the application scope, but the exception does not indicate whether the path is valid. This helps protect against someone using ASP.NET site navigation to discover valid file paths on a server.
For information about how you can help protect your site-map data if you implement a custom site-map provider that uses a database, see Securing Data Access.
Site Map Load Process
The default ASP.NET site-map provider loads site-map data as an XML document and caches it as static data when the application starts. An excessively large site-map file can use a lot of memory and CPU power at load time. In a hosted environment, restrict the size of site maps that customers are allowed to create for their sites. This helps protect against denial of service attacks.
The ASP.NET site navigation features depend on file notifications to keep navigation data up to date. When a site-map file is changed, ASP.NET reloads the site-map data. This can cause a problem if your site navigation structure is made up of child site maps that have write access granted to users who might not understand that each change they make will cause a reload. Make sure to set restrictive access on all site-map files. Define your user groups by who has permission to update files at which locations, and then set the permissions on site-map files to the individual user groups.
ASP.NET site navigation allows individual site-map nodes to be secured by a role. If you want to hide part of the navigation structure of your site from certain users, you can enable ASP.NET security trimming. Once enabled, ASP.NET checks URL authorization and optionally checks file access permissions to the file that is listed in a site-map node. ASP.NET displays the link to that file only if the user has access. If you want to allow all users to view a link to a restricted file, set the roles attribute on the corresponding site-map nodes to an asterisk (*), or wildcard character, which will enable all clients to view the link. For more information, see ASP.NET Site-Map Security Trimming.
Including External URLs in a Site Map
In a site map, you can reference URLs that are outside of your ASP.NET application. However, access to a URL outside of the application cannot be tested by ASP.NET. For example, if you create a site-map node that corresponds to http://www.microsoft.com and you enable security trimming, the hyperlink will not be visible to clients because ASP.NET cannot test access permissions for an external URL. If you enable security trimming and you have site-map nodes that correspond to external URLs, set the roles attribute on those nodes to an asterisk (*), which will enable all clients to view the link even though ASP.NET cannot authorize access to the external link.
The site navigation classes are publicly available to any code that is running on the computer. Site navigation classes run under minimal trust. However, low trust is required to load site-map data because ASP.NET needs to use file I/O operations when opening a site-map file using the default site-map provider, XmlSiteMapProvider. Optionally, you can develop a custom site-map provider that does not have this restriction.
When implementing a custom site-map provider, ensure that the provider has been reviewed for security best practices. This is especially important in a hosting scenario where a custom site-map provider, if not implemented correctly, could leak information or contain default configuration settings that are not secure. Follow best practices to help avoid attacks, such as SQL injection attacks. For example, you should always verify parameter input.
For information about securing a database, see Securing Data Access. Also, see ASP.NET Application Security in Hosted Environments.
The following sections discuss how you can mitigate potential security risks that are exposed by unexpected error messages and events.
Exceptions thrown by ASP.NET site navigation features do not expose privileged information. Review and test custom classes in your Web application for invalid input and requests to help ensure that privileged information will not be exposed when exceptions occur.
To help prevent exposing sensitive information to unwanted sources, either turn on custom errors for your application, or display detailed error messages only when the client is the Web server itself. For more information, see customErrors Element (ASP.NET Settings Schema).
If your computer is running Windows Server 2003, you can help improve the security of your application by securing the event log. Also, set parameters regarding the size, retention, and so on of the event log to help prevent an indirect denial of service attack against the log. By default, only members of the Administrators security group can view event logs. For more information about configuring event logs, search for "Event Viewer" in Windows Help and Support.