Please note: This post is now outdated. See http://blogs.msdn.com/b/webdev/archive/2014/09/09/farewell-enableviewstatemac.aspx for the most up-to-date information.
A few months ago, we posted that we were making changes to the way EnableViewStateMac behaves in ASP.NET. I’ll forego the typical blog post ceremony and cut right to the chase: starting with ASP.NET 4.5.2, the runtime enforces EnableViewStateMac=true. If an application sets <%@ Page EnableViewStateMac=”false” %> as a directive or <pages enableViewStateMac=”false” /> as a config setting, the runtime ignores it and pretends that the developer had written “true” instead.
Currently the .NET Framework 4.5.2 is an optional download on Microsoft Download Center. However, these changes will eventually be pushed out over Windows Update / Microsoft Update. Servers which have opted in to WU / MU servicing will automatically get this new behavior at that time. (At present we have no timeline for when this will be pushed out over WU / MU.)
We’re aware that this change could affect a substantial number of web applications. It is never our intention to break web applications in an in-place update, but we felt it necessary to address this issue head-on due to the prevalence of misinformation regarding this switch and the number of customers who are running with it set to an insecure setting. To see if you need to take any action with regard to your existing ASP.NET applications, please read on.
What if I have EnableViewStateMac set to true everywhere?
Great! No action is required on your part. Nothing will change; your application will continue to work as it always has.
What if I never set EnableViewStateMac to anything, true or false?
No action is required on your part. Nothing will change. The default value for this switch has always been true, so your application will continue to work as it always has.
When is it safe to set EnableViewStateMac=false?
It is never safe to set EnableViewstateMac=false.
Doesn’t setting EnableViewStateMac=true harm performance?
No. The EnableViewStateMac switch has no measurable impact on performance.
What’s the worst that can happen if I set EnableViewStateMac=false?
As called out in the original advisory, an attacker may be able to leverage this setting to upload and execute arbitrary code on the web server. This would grant her complete control over the web application subject to the permissions of the web worker process.
Can I set EnableViewStateMac=false if I also set EnableViewState=false?
No. It doesn’t matter if the application uses EnableViewState=false or if the application requires authentication. It is categorically insecure to set EnableViewStateMac=false, even on a single page.
What about cross-page posts?
In 4.5.2, the ASP.NET framework special cases cross-page posts to minimize the chance of them causing errors at postback time. However, setting <form action=”some-different-page.aspx” /> has never been the recommendation for cross-page posts in WebForms. Consider using PostBackUrl instead to make this scenario work. See http://msdn.microsoft.com/en-us/library/ms178140(v=vs.100).aspx for more information.
What if my servers are in a web farm and I don’t want to sync <machineKey> elements?
You are required to create a <machineKey> element and synchronize it across machines in your farm. See KB 2915218, Appendix A for full instructions on how to generate a <machineKey> element. That appendix contains a block of code that you can copy and paste into a PowerShell window. This will generate a <machineKey> element locally that you can put into your Web.config.
Note: these keys are sensitive. Anybody who has access to them could end up with full administrative control over your web application. For this reason we suggest that you never use an online “click here to generate a <machineKey> element” utility. Only ever use <machineKey> elements that you generated yourself on your own machine. And use caution not to leak these keys in public places like online forums.
What if I encounter MAC validation errors when I set EnableViewStateMac=true?
We updated the “validation of view state MAC failed” error message to contain a link to KB 2915218, which lists common reasons that the MAC verification step might fail. Check that article to see if it calls out an item specific to your scenario.
Are there any other behavioral changes as a result of this?
Yes, there is a minor behavioral difference as a result of the EnableViewStateMac change. If a __VIEWSTATE form field is written out to the response, it will now be accompanied by a new form field <input type=”hidden” name=”__VIEWSTATEGENERATOR” … />. This new form field is used by the ASP.NET runtime to help determine whether a postback is going to the same page or is cross-page. It’s similar in concept to the __PREVIOUSPAGE form field that is written when a control’s PostBackUrl property is set.
What about ASP.NET 2.x / 3.x?
As of September 2014, all versions of ASP.NET 1.1 – 4.5.2 now forbid setting EnableViewStateMac=”false”. Please see http://blogs.msdn.com/b/webdev/archive/2014/09/09/farewell-enableviewstatemac.aspx for up-to-date information regarding these framework versions.
If you have any questions about this change, please let us know. Thanks, and happy coding!