O'Reilly logo

Professional ASP.NET 3.5 Security, Membership, and Role Management with C# and VB by Stefan Schackow, Bilal Haidar

Stay ahead with the world's most comprehensive technology and business learning platform.

With Safari, you learn the way you learn best. Get unlimited access to videos, live online training, learning paths, books, tutorials, and more.

Start Free Trial

No credit card required

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.

With Safari, you learn the way you learn best. Get unlimited access to videos, live online training, learning paths, books, interactive tutorials, and more.

Start Free Trial

No credit card required