Hidden Form Fields and Cookie values are also sometimes vulnerable to these attack techniques. Encrypting hidden form fields and cookies usually protects them from tampering. Same problem; same solution. Viewstates typically have the advantage over cookies and hidden FFs, from a security control standpoint, of having native encryption and checksumming facilities provide by the programming environment/framework. These controls are as easy to turn on as flicking a switch. Super simple remediation. Most frameworks do not offer easy, native controls like this for cookies or hidden FFs. Would you agree that the issue here is RTFM? Many developers using Viewstates aren't aware they are using Viewstates. Think "Newbie Visual Studio Jockey" developers. They are using a control in their IDE and have no idea it's passing off stuff in b64 strings to the web-browser/client that can be decoded and/or modified. The most common scenario where developers disable native Viewstate controls is in multi-websever deployments when they start load-balancing. The Viewstate keys don't match across servers; the app breaks; the developers Google just enough info to decide to turn off Viewstate encryption/checksums (or the server admin does it). The fix for Viewstate load balancing issues is also super simple: Share Viewstate MAC/checksum or encryption keys. But it is fairly common not to do this until after a security assessment. Usually for the same reasons I outlined above: they aren't really even sure what Viewstate is doing. So good work. Nicely written advisories. Questions: 1) Did you find any unpublished new vulns in these specific products? 2) Are the core issues "if you turn off your compensating control your vulnerabilities are still vulnerable?" 3) Do most vendors enable Viewstate controls by default (like Microsoft does)? If not - I think you should highlight and underscore that. Certainly a default checksum would be smart. Ciao --- Arian Evans Solipsistic Software Security Statistician
