Securing View State

[アーティクル]
10/15/2014

The ViewState property provides a dictionary object for retaining values between multiple requests for the same page. This is the default method that Web pages use to preserve page and control property values between round trips.

When the page is processed, the current state of the page and controls is encoded and the resulting string is saved in the page as a hidden field. If the amount of data that is stored in the ViewState property exceeds the value specified in the MaxPageStateFieldLength property, the string is saved in the page as multiple hidden fields. When the page is posted back to the server, the page parses the view state string at page initialization and restores property information.

The information in this topic describes best practices that will help you improve the security of application data that is stored in view state.

While following coding and configuration best practices can improve the security of your application, it is also important that you continually keep your Web server computer up to date with the latest security updates for Microsoft Windows and Internet Information Services (IIS), as well as any security updates for Microsoft SQL Server or other membership data sources.

More detailed information about best practices for writing secure code and securing applications can be found in the book "Writing Secure Code" by Michael Howard and David LeBlanc, or through the guidance provided by Microsoft Patterns and Practices.

Securing View State Data on the Page

By default, view state data is stored on the page in a hidden field and is encoded using base64 encoding. In addition, a hash is created from the data using a machine authentication code (MAC) key. The hash value is added to the encoded view state data and the resulting string is stored on the page. When the page is posted back to the server, the ASP.NET page framework re-hashes the view state data and compares the hash with the hash stored previously in the page. If the hash does not match, an exception is raised indicating that view state data might be invalid.

By creating a hash value, the ASP.NET page framework can test whether the view state data has been tampered with. But view state data can still be viewed, and can potentially be intercepted and read by malicious users.

MAC Encoding

When the ASP.NET page framework creates a hash for view state data, it uses a MAC key that is either auto-generated or specified in the Machine.config file. If the key is auto-generated, it is created based on the MAC address of the computer. The MAC address is the unique GUID value of the network adapter in the computer.

It can be difficult for malicious users to reverse-engineer the MAC key based on the value in the page and the view state. Thus, MAC encoding is typically a reliable way to determine whether anyone has tampered with the view-state data.

In general, the larger the MAC key that is used to generate the hash, the less likely it is that the hash value for different strings will be the same. When the key is auto-generated, ASP.NET uses SHA1 encoding to create a large key. However, in a Web-farm environment, the key must be the same across all of the servers. If the key is not the same, and the page is posted back to a different server than the one that created the page, the ASP.NET page framework will raise an exception. Therefore, in a Web farm environment, you should specify a key in the Machine.config file instead of allowing ASP.NET to auto-generate one. The longer the key, the more secure it is; but the longer the key is the more time it takes to create a hash, so it is important to weigh security needs versus performance needs.

Encryption

While MAC encoding helps prevent tampering with view state data, it does not prevent users from viewing the data. View state data is stored in one or more hidden fields on the page and is encoded using base64 encoding. You can prevent people from viewing this data in two ways: transmitting the page over SSL and by encrypting the view state data. Requiring the page to be sent over SSL can help prevent data-packet sniffing and unauthorized data access by people who are not the intended recipients of the page.

However, the user who requested the page can still view the view state data because SSL decrypts the page to display it in the browser. This is fine if you are protecting the data primarily from people who should not be allowed to see the page and are not concerned about authorized users having access to view state data. However, in some cases controls might use view state to store information that no users should have access to. For example, the page might contain a data-bound control that stores item identifiers (data keys) in view state. If those identifiers contain sensitive data, such as social security numbers of customer IDs, you should encrypt the view-state data in addition or instead of sending over SSL.

To encrypt the data, set the page's ViewStateEncryptionMode property to true. If you store information in view state, you can use normal read and write techniques; the page handles all encryption and decryption for you. Encrypting view state data can affect the performance of your application, so do not use encryption unless you need it.

Control State Encryption

Web controls can maintain small amounts of data, called control state, that are required for the correct operation of the control. When a control uses control state, a view state field containing the control state is sent to the client on each request even when view state is turned off for the application or page.

Controls that use control state can require that view state be encrypted by calling the RegisterRequiresViewStateEncryption method. If any control on the page requires that view state be encrypted, then all view state on the page will be encrypted.

Per-user View State Encoding

If your Web site authenticates users, you can set the ViewStateUserKey property in the Page_Init event handler to associate the page's view state with a specific user. This helps prevent one-click attacks, in which a malicious user creates a valid, pre-filled Web page with view state from a previously created page. The attacker then lures a victim into clicking a link that sends the page to the server using the victim's identity.

When the ViewStateUserKey property is set, the attacker's identity is used to create the hash of the view state of the original page. When the victim is lured into resending the page, the hash values will be different because the user keys are different. The page will fail verification and an exception will be thrown.

You must the ViewStateUserKey property to a unique value for each user, such as the user name or identifier.

Securing Configuration in Shared Hosting Environment

In a shared hosting environment, malicious users can potentially modify state-management properties that might affect other applications on the computer. This can be done through direct modification to the Machine.config file, modification via the configuration APIs, and other administration and configuration tools. You can help prevent modification to your application configuration by encrypting sections of configuration files. For more information, see Encrypting Configuration Information Using Protected Configuration

次の方法で共有