The view state feature is essential to a large number of ASP.NET applications because it is a built-in way to maintain state across consecutive invocations of the same page within the same session. View state can be disabled, or at least restricted, in applications that make intensive use of controls and for which bandwidth is a serious problem. The view state, in fact, does not add power to the client but does fatten the page being downloaded. In some cases, the extra burden caused by the view state can easily reach 10 KB, more than doubling the normal size of the page.
Rather than being concerned with performance, however, programmers seem to be more sensitive to possible security issues related to the view state. Although not well explained by the MSDN documentation, the view state is absolutely safe to use as long as you don’t change the default settings. Reading the view state on the client is still possible, but that's only a security hole if you use the view state to store sensitive information such as credit-card numbers, passwords, or connection strings.
A rogue client can attempt to modify the view state, but once the page posts back to the server, the ASP.NET runtime would be able to detect the tampering and raise a security exception. Let's consider the security of the view state.
When the ASP.NET runtime creates the view state string, it recursively calls all the page controls to populate the page's state bag dictionary with their own view state properties. The resulting dictionary is serialized to a binary string using the .NET binary formatter. At this point, ASP.NET can calculate a hash value based on three inputs: the contents of the view state, the page type hash code, and the machine key. The resulting value is calculated using the SHA1 hashing algorithm and is normally 160 bits long. This sequence of bytes is appended to the binary stream. Finally, the binary stream is encoded as Base64 and inserted into the hidden field. In this architecture, it's clear that any changes performed on the client are detected on the server and the security exception is raised.
Notice, though, that the view state is not encrypted. So it is potentially readable on the client. If you want to maintain some sort of data confidentiality, use secure sockets instead.
The view state antitampering mechanism is set up by default and is controlled through the EnableViewStateMac attribute of the @Page directive. When the attribute is set to True (the undocumented default), the view state is protected using the hash value. If you change the default settings and disable the EnableViewStateMac feature, then the view state would simply be a Base64 string that can be deserialized to a .NET dictionary using the binary formatter.
Finally, notice that the machine key used to fuel the hash algorithm is stored in the local security authority of the Windows NT/2000 server machine (the LSA). However, in case of web farms, you have to synchronize all machine keys in all servers and must store the key in the configuration file. The key length can vary from a minimum of 40 characters (20 bytes) to a maximum of 128 characters (64 bytes).
Dino Esposito is Wintellect's ADO.NET and XML expert, and a trainer and consultant based in Rome, Italy. Dino is a contributing editor to Windows Developer Magazine and MSDN Magazine, and the author of several books for Microsoft Press including Building Web Solutions with ASP.NET and ADO.NET and Applied XML Programming for .NET. Contact Dino at [email protected].
