Securing View State in ASP.NET

View state data is stored in the web page in a hidden field and is encoded using base64 encoding. In addition, a hash of the view state data is created from the data by using a machine authentication code (MAC) key. The hash value is added to the encoded view state data and the resulting string is stored in the page. When the page is posted back to the server, the ASP.NET page framework re-computes the hash value and compares it with the value stored in view state. If the hash values do not match, an exception is raised that indicates 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 corrupted or tampered with. However, even if it is not tampered with, view state data can still be intercepted and read by malicious users.

Using the MAC for Computing the View State Hash Value

The MAC key that is used to compute the view state hash value 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, which is the unique GUID value of the network adapter in that computer.

It can be difficult for malicious users to reverse-engineer the MAC key based on the hash value in view state. Thus, MAC encoding is a reasonably reliable way to determine whether view state data has been changed.

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 SHA-1 encoding to create a large key. However, in a Web-farm environment, the key must be the same across all 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 letting ASP.NET auto-generate one. In that case, make sure that you create a key that is long enough to offer sufficient security for the hashed value. However, the longer the key is, the more time it takes to create a hash. Therefore, you must weigh security needs versus performance needs.

Encrypting View State

Although MAC encoding helps prevent tampering with view state data, it does not prevent users from viewing the data. You can prevent people from viewing this data in two ways: by 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 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 customer IDs, you should encrypt the view state data in addition to or instead of sending the page over SSL.

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