{"id":884,"date":"2013-12-10T10:00:00","date_gmt":"2013-12-10T10:00:00","guid":{"rendered":"https:\/\/blogs.msdn.microsoft.com\/webdev\/2013\/12\/10\/asp-net-december-2013-security-updates\/"},"modified":"2013-12-10T10:00:00","modified_gmt":"2013-12-10T10:00:00","slug":"asp-net-december-2013-security-updates","status":"publish","type":"post","link":"https:\/\/devblogs.microsoft.com\/dotnet\/asp-net-december-2013-security-updates\/","title":{"rendered":"ASP.NET December 2013 Security Updates"},"content":{"rendered":"

Today is Patch Tuesday, and the ASP.NET team would like to announce that we have two items included in this month’s release. The first is a bulletin affecting certain versions of SignalR; the second is an advisory affecting ASP.NET Web Forms (.aspx) applications. Each item is briefly outlined below. For more information, consult Security TechCenter<\/a> for this month’s releases.<\/p>\n

Cross-site scripting (XSS) vulnerability in ASP.NET SignalR<\/h3>\n

Main article: Bulletin <\/b>MS13-103<\/b><\/a> (<\/b>KB 2905244<\/b><\/a>)<\/b><\/p>\n

Some versions of ASP.NET SignalR contain a bug which could under certain circumstances allow an attacker to run arbitrary JavaScript in the context of a site visitor’s browser. This is an example of a cross-site scripting (XSS) attack<\/a>.<\/p>\n

Action items<\/h4>\n

If your web application uses SignalR, consult the table below for the recommended course of action.<\/p>\n\n\n\n\n\n\n
\n

SignalR version<\/b><\/p>\n<\/td>\n

\n

Recommended steps<\/b><\/p>\n<\/td>\n<\/thead>\n

\n

1.0.0 – 1.0.1<\/b><\/p>\n<\/td>\n

\n

These versions of SignalR are not vulnerable<\/b> to this attack, so no update is necessary. However, the 1.0.x branch is not under active support by Microsoft. It is recommended that applications upgrade to the latest 1.x version to remain in a supported state. At the time of this article’s publication, the latest supported 1.x version is 1.1.4. <\/p>\n<\/td>\n<\/tr>\n

\n

1.1.0 – 1.1.3<\/b><\/p>\n<\/td>\n

\n

These versions of SignalR are vulnerable<\/b> to the attack, and applications which rely on them should upgrade to the latest 1.x version as soon as possible. At the time of this article’s publication, the latest supported 1.x version is 1.1.4.<\/p>\n<\/td>\n<\/tr>\n

\n

2.0.0<\/b><\/p>\n<\/td>\n

\n

This version of SignalR is vulnerable<\/b> to the attack, and applications which rely on it should upgrade to the latest 2.x version as soon as possible. At the time of this article’s publication, the latest supported 2.x version is 2.0.1.<\/p>\n<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n

See KB 2905244<\/a> for more information on how to update the version of SignalR used by your application.<\/p>\n

Insecure ASP.NET Web Forms (.aspx) configuration could allow remote code execution<\/h3>\n

Main article: <\/b>KB 2905247<\/b><\/a><\/b><\/p>\n

By default, ASP.NET Web Forms contains the configuration setting EnableViewStateMac=true, which helps verify that the __VIEWSTATE field and related fields haven’t been tampered with. MSDN warns against setting this switch to false<\/i><\/a> on a production site due to the ability for an attacker to forge malicious payloads. If a web developer sets EnableViewStateMac=false for any page in his site, an attacker could leverage this to upload and invoke arbitrary executable code within the context of the web service account. This is an example of a remote code execution (RCE) attack.<\/p>\n

Action items<\/h4>\n

The EnableViewStateMac switch has a default value of true<\/i> unless the web developer has explicitly set this switch to false<\/i>. To see if your application is vulnerable, search the source files that comprise your application for the term EnableViewStateMac<\/i> (all one word), and verify that the switch is never set to false<\/i> anywhere in your application. The search must minimally include .config, .aspx, .cs, and .vb files. However, it is safer to search all file extensions.<\/p>\n

Important note:<\/b>
The next version of ASP.NET will forbid<\/b> setting EnableViewStateMac=false. Applications which set EnableViewStateMac=false may no longer function properly once this update is pushed out. Web developers must<\/b> take this time to ensure that their applications do not set this switch to an insecure value.<\/p>\n

As part of this advisory, we are also publishing a KB article on how to resolve “validation of view state MAC failed” exceptions that may have led developers to set EnableViewStateMac=false in the first place. That KB article can be found here<\/a>.<\/p>\n

Additional resources<\/h3>\n

Further information on this month’s security releases can be found at the following locations:<\/p>\n