Securing Web Parts Pages

[アーティクル]
12/04/2014

Web Parts is the new feature of ASP.NET that gives end users the ability to modify or personalize Web pages. Having personalized Web pages is very enabling and powerful for users of Web applications, but it also has security implications that developers should know about.

Web Parts Security Issues

Because Web Parts is a feature of ASP.NET, and Web Parts controls are extended ASP.NET server controls, Web Parts pages are susceptible to all the same risks as ASP.NET pages. A Web application with pages that use Web Parts controls is really just a specialized type of ASP.NET application, and an application that uses Web Parts can run in any trust level that an ordinary ASP.NET application can. For general information about ASP.NET Web site security, see ASP.NET Security. However, Web Parts has some unique security issues that normal ASP.NET pages do not have. These issues are discussed in the following sections.

Importing Control Data

The Web Parts feature with the greatest security risks is the import feature. This feature allows a user to import an XML description file that contains state and property data for a server control (the control's assembly file must already be available on the Web server). Importing data for controls is a way for users to share data and easily configure complex controls. But the inherent risk is that there could be malicious data in the description file. For example, if someone has placed malicious script code as the value of a string property in the description file, then that script could potentially be executed when a user imports the description file and adds the referenced server control to a Web page. To minimize the risk of importing description files with malicious data, server controls that have string-typed properties should always encode the property data. Another risk involves importing types through description files (see Web Parts Control Description Files). A malicious user could submit requests to load many assemblies into the AppDomain, resulting in an excessive amount of memory being consumed. If you want to avoid the risks associated with import, you can disable the feature altogether simply by not using the server control that implements it. Or you can limit what users have access to the control. For instance, you could use role management, and if a user is in the administrator role, you could programmatically add the ImportCatalogPart to the page for that user. For more information about the control, see the reference topic for the ImportCatalogPart class.

Exporting Control Data

The export feature has nearly as much potential for risk as import, because it can expose sensitive data. Export enables users to save the property and state data for a particular control into an XML description file. (This is the same file that can be imported using the import feature.) The primary risk here is that users might export sensitive data out of the application and into the description file, which is a simple text file that anyone with the proper permissions could read. Export is disabled by default in ASP.NET, so if you do not need the feature, you can safely ignore it. This is clearly the most secure option.

If you do want to enable export, you should be aware of the options for determining which properties can be exported. When you create a WebPart or server control that will be used in a WebPartZone zone, for each public property that you want to make exportable, you can add the Personalizable metadata attribute. This makes the property exportable if export is enabled, and it also raises a message box to the user, warning that the data will be exported. One of the parameters of the Personalizable attribute is called IsSensitive. This Boolean parameter is useful if you have a property that you want to be exportable in some situations, but not in others. For details and an example, see the reference topic for the ExportMode property.

Understanding Personalization Details

Web Parts personalization is the feature that enables users to modify Web pages to suit their preferences, and to save their settings in long-term storage, so that the personalized pages retain the settings across browser sessions. Most Web Parts features require personalization; therefore, it is enabled by default in ASP.NET Web sites, although it is used only on pages that contain Web Parts controls. Because personalization is such a powerful feature, it also carries some degree of risk. Users are able to modify the actual layout, appearance, and even the content and controls on a Web page. The personalization data is stored in a database and is used to render pages, so users have a lot of potential for malicious activity relating to the content of a site. Users that have access to shared personalization scope can even change the way pages will appear for all users.

If you have a particular page that uses Web Parts features but does not require personalization (for example, one of the common pages in a portal site), it is a good practice to disable personalization, because this enhances performance and reduces your site's exposure to security risks. For more information, see How to: Disable Web Parts Personalization.

Authenticating Users for Personalization

Personalization requires authenticated users. You cannot enable personalization for anonymous users. This means that to have full personalization and Web Parts functionality, your Web site must use Windows or Forms-based authentication. For information about authentication options, see ASP.NET Authentication. To set up a site using the new membership feature (which uses Forms authentication), see Managing Users by Using Membership.

Granting Minimal Access to Shared Personalization

Web Parts personalization changes always apply to a given range or scope of users. Changes made in user scope are visible only to the user making the changes, whereas changes made in shared scope are visible to all users. Shared personalization scope exists so that users in a manager or administrative role can make changes to a page that apply to all users of a site. By default, all users are denied access to shared scope. Only selected users should be given access, which must be done explicitly in a Web site's configuration file. For details, see How to: Enable Shared Personalization of Web Parts Pages.

Using Tested and Trusted Controls

Because Web Parts provides users with powerful capabilities, such as the ability to add new server controls to a page, developers should be very cautious about which server controls they use within a Web Parts application. Server controls, especially ones from third parties or vendors, should be carefully reviewed and tested to ensure that they can be trusted for use in a Web Parts application. For example, suppose a particular server control is poorly designed and inefficient in its memory usage. If you add that control to a Web Parts catalog, users can add it to a Web page. And because a control in a catalog can be added to a page any number of times (multiple instances), a user could add the poorly performing control multiple times, which could effectively generate a denial of service attack when the page tries to process many instances of the control. For more information about Web Parts catalogs, see the reference topic for the CatalogPart class.

Using Authorization and Filtering on Controls

Web Parts has a feature that enables you to set and check the authorization level for the server controls you use to create the user interface (UI) of your Web Parts pages. If a control is authorized based on the criteria you set, it will appear on the page, and if it is authorized at some reduced level or not at all, you can change its appearance accordingly, or hide it altogether. For example, suppose you have a user who is designated as an administrator. There might be a server control that you want to be visible only to the administrator. Using the authorization and filtering features of Web Parts, you could make sure that this control appears only to a designated administrator, and is hidden from other users. The primary mechanisms for using authorization and filtering are the AuthorizationFilter property of the WebPart class, and the IsAuthorized and OnAuthorizeWebPart methods of the WebPartManager class.

Encoding String-Typed Properties in Editing Controls

One unique feature of Web Parts is that end users can switch a page into an editing mode, and they can edit a server control by changing its layout, appearance, behavior, and its personalizable property values. But this presents some risk, because a malicious user could insert inappropriate data, or attempt a script injection attack, using the ability to edit string-typed properties. As a security practice, if you create custom EditorPart controls to edit server controls, and if any of the personalizable properties in a given server control are of a string type or use a string converter, your EditorPart control should encode the string data before assigning it to the property. For an example, see the reference documentation on the HtmlEncode method.

次の方法で共有