Time to Say Goodbye to EnableViewStateMac
In December 2013, Microsoft released a security advisory warning and stated that configuration setting EnableViewStateMac=false is dangerous and could allow an elevation of privilege attack against the web site. This advisory then followed by the security patch KB 2905247 which was optional. But, in September 2014 security update, Microsoft finally has enforced the farewell to EnableViewStateMac for all versions of the ASP.NET framework. Microsoft .NET Framework updates comes with the Windows updates and this patch would affect when you install latest Windows updates.
What does it mean?
All version of the ASP.NET runtime 1.1 – 4.5.2 now forbid setting
<pages enableViewStateMac="false"/>and <%@ Page EnableViewStateMac="false" %>
So, if you have set EnableViewStateMac="false" anywhere in your application, your application will be affected by this change. If you are running the ASP.NET framework on your machine, this behavior will be picked up automatically the next time you check for updates.
So, what is 'View state MAC'?
View State is a hidden form field where .NET framework stores encoded form data for lookup in the subsequent request post backs to the same page. MAC stands for message authentication code, which is a cryptographic code generated by the server and appended to _VIEWSTATE hidden form field (The view state of a page is, by default, placed in a hidden form field named __VIEWSTATE). The MAC ensures that the client hasn’t tempered with these fields (_VIEWSTATE).
Okay, but why is EnableViewStateMac="false" dangerous?
If EnableViewStateMac is enabled, the .NET framework computes MAC and stores it in a hidden viewStateMac field of the response. When the request is posted back from the client, the .NET framework computes the MAC of the viewstate and verifies that it with the same value as seen in the hidden viewStateMac field in the request. If the two values do not match, .NET raises an error "Validation of viewstate MAC failed". Enabling this option prevents attackers from tampering the viewState data.
Microsoft is forbidding it because it is never safe to set EnableViewStateMac=”false”. Your web site is open to remote code execution attack. An attacker may be able to leverage this setting to upload and execute arbitrary code on the web server. This would grant attacker complete control over the web application subject to the permissions of the web worker process.
Will this patch break my application?
If you have set EnableViewStateMac=”false” anywhere in your application, this change will affect you. If the reason the MAC was disabled was to enable cross-page posts (when one page is posted to another page), the application will generally continue to work correctly. If the reason the MAC was disabled was to avoid synchronizing the <machineKey> setting in a web farm, the application will probably break.
If you are using EnableViewStateMac=”true” throughout your application, this change will not affect you. If you never touch the EnableViewStateMac switch at all in your application, this change will not affect you, as the default value for this setting is true.
As I wrap up this blog post let me try and answer to you one of the most important questions that you might be thinking right now.
What are the major behavioral changes you will witness after applying this patch?
A minor change in behavior of web forms has occurred due to this patch, but it is not a breaking change. So, now if a _VIEWSTATE field is written to the response, now it will be accompanied by the new <input type="hidden" name="__VIEWSTATEGENERATOR" ... /> field. This new form field is used by the ASP.NET runtime to determine whether a postback is going to same page or cross-page. It is similar in concept to the _PREVIOUSPAGE form field that is written when a control’s PostBackUrl property is set.