How To Encrypt Viewstates In Dotnet

Remedy

ASP.NET provides encryption for ViewState parameters. For page based protection, place the following directive at the top of affected page.
<%@Page ViewStateEncryptionMode="Always" %>
You can also set this option for the whole application by using web.config files. Apply the following configuration for your application's web.config file.
<System.Web >
   <pages viewStateEncryptionMode="Always">
</System.Web >

Encrypt ViewState in ASP.NET 2.0

o reduce the chance of someone intercepting the information stored in the ViewState, it is good design to encrypt the ViewState. You could do this in previous releases of ASP.NET, but the support for encryption has been improved in ASP.NET 2.0, allowing you to set this on a page-by-page basis. In the previous release of ASP.NET, the page developer could turn encryption on and off at the application level through a config setting. When validation was set to 3DES, ViewState was encrypted before being rendered in the page.

  <configuration>
     <system.web>
       <machineKey validation="3DES" />
    </system.web>
  </configuration>

In ASP.NET 2.0 the support for controlling and utilizing encryption has been expanded. Encryption settings can now be controlled separately for each page. In addition, the controls on the page can request that encryption be used for the ViewState, but even this request can be overridden by the page setting.

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.