Programming Microsoft ASP.NET 4 - Dino Esposito [369]
Common Issues with View State
Architecturally speaking, the importance of the view state cannot be denied because it is key to setting up the automatic state management feature of ASP.NET. A couple of hot issues are related to the usage of the view state, however. The most frequently asked questions about the view state are related to security and performance. Can we say that the view state is inherently secure and cannot be tampered with? How will the extra information contained in the view state affect the download time of the page? Let’s find out.
Encrypting and Securing
Many developers are doubtful about using the view state specifically because it is stored in a hidden field and left on the client at the mercy of potential intruders. Although the data is stored in a hashed format, there’s no absolute guarantee that it cannot be tampered with. The first comment I’d like to make in response to this is that the view state as implemented in ASP.NET is inherently more secure than any other hidden fields you might use (and that you were likely using, say, in old classic ASP applications). My second remark is that only data confidentiality is at risk. While this is a problem, it is minor compared to code injection.
Freely accessible in a hidden field named __VIEWSTATE, the view state information is, by default, hashed and Base64 encoded. To decode it on the client, a potential attacker must accomplish a number of steps, but the action is definitely possible. Once decoded, though, the view state reveals only its contents—that is, confidentiality is at risk. However, there’s no way an attacker can modify the view state to post malicious data. A tampered view state, in fact, is normally detected on the server and an exception is thrown.
For performance reasons, the view state is not encrypted. If it’s needed, though, you can turn the option on by acting on the web.config file, as follows:
When the validation attribute is set to 3DES, the view-state validation technique uses 3DES encryption and doesn’t hash the contents. If you use web.config, the settings apply to all pages in the application. You can also control encryption settings separately for each page. Furthermore, individual controls on the page can request to encrypt the view state. In case of a conflict, page settings win. You use the ViewStateEncryptionMode property, which accepts values from the ViewStateEncryptionMode enumeration. Feasible values are Auto, Always, and Never. The default value is Auto. When the value is Auto, ASP.NET encrypts the entire view state only if all controls want it encrypted. With values like Always and Never, the view state is always or never encrypted, regardless of the control settings.
Machine Authentication Check
If EnableViewStateMac is true, when the page posts back, the hash value is extracted and used to verify that the returned view state has not been tampered with on the client. If it has been, an exception is thrown. The net effect is that you might be able to read the contents of the view state, but to replace it you need the encryption key, which is in the Web server’s LSA. The
The @Page directive contains an attribute named EnableViewStateMac, whose only purpose is making the view state a bit more secure by detecting any possible attempt at corrupting the original data. When serialized, and if EnableViewStateMac is set to true, the view state is appended with a validator hash string based on the algorithm and the key defined in the