9.5. Summary

Since ASP.NET 1.0, page developers have benefited from the ability to hash and encrypt viewstate. You could also make viewstate information unique to a specific user with the ViewStateUserKey property. With the introduction of the viewstate encryption mode feature back in ASP.NET 2.0, control developers had the option of automatically turning on viewstate encryption when they know their controls store potentially sensitive data in viewstate.

When data is submitted to an ASP.NET page, all input should initially be considered untrusted. Although the majority of the work involved in scrubbing input data lies with the developer, ASP.NET does have some protections that work on your behalf. Since ASP.NET 1.1, the runtime validates form data, query-string values and cookie values for suspicious string sequences. Although this type of check is not exhaustive, it does cover the most likely forms of malicious input. Both ASP.NET 2.0 and ASP.NET include logic to protect against fraudulent postbacks. Because postbacks can be easily triggered with a few lines of JavaScript, it is possible to forge postback data to controls and events that were not rendered on the page. By default, ASP.NET 2.0 and ASP.NET 3.5 check for this situation and will not trigger server-side events for nonvisible or disabled controls and events that were never rendered on the client.

Get Professional ASP.NET 3.5 Security, Membership, and Role Management with C# and VB now with the O’Reilly learning platform.

O’Reilly members experience books, live events, courses curated by job role, and more from O’Reilly and nearly 200 top publishers.