Freigeben über

IE9 - XBAPs Disabled in the Internet Zone

  • Artikel

As I mentioned last month, .NET Framework XAML Browser Applications (XBAPs) are now prevented from loading from the Internet Zone in IE9. When visiting an Internet site that utilizes an XBAP, an error message is shown, indicating that the application type has been disabled:

IE Screenshot showing disabled XBAP

XBAPs are a powerful technology based on .NET Framework technologies, but they are not commonly used on the Internet. Our crawls of the top 100,000 websites found no uses of the technology.  We know that many customers use XBAPs on internal sites and, as such, these applications remain enabled in the Local Intranet, Trusted, and Local Machine zones.

The mechanism used to implement this change is simple; IE9 Setup adjusts the existing URLACTION_WINDOWS_BROWSER_APPLICATIONS (0x2400) to Disable (0x3) for the Internet Zone, and adjusts the Medium-High security zone template to match. Group Policy or end-user configuration of the XAML Browser Applications setting inside Tools > Internet Options > Security settings permits enablement of XBAPs for the Internet zone, although this is not recommended. Instead, to unblock any scenarios where XBAPs are needed for Internet sites, end-users or IT Administrators may add an XBAP’s origin to the Trusted Sites list, using either the Internet Control Panel’s Security Tab or by using the site-to-zone assignment feature of Group Policy.

One caveat to keep in mind is that the .NET Framework evaluates the URLAction based on the origin of the XBAP. In the case where a HTML document utilizes a cross-origin XBAP, the URL of the XBAP is mapped to a Zone and the Zone settings for that zone are consulted; the outer document’s URL is not considered.

One common question is “Why did you change this setting to Disable rather than Prompt? ”

We elected not to change the URLAction’s value to prompt as our research shows that users tend not to make good choices in any of our legacy modal security prompts. We’ve done significant work in IE9 to nearly eliminate the modal prompts. Worse still, the XBAP URLAction was never in the set with a descriptive prompt message, so the user-experience in the “Prompt” state isn’t a good one:

Screenshot of unhelpful Prompt message

Application developers using XBAPs in the Internet Zone should consider moving to other distribution mechanisms. For instance, ClickOnce executables have a lightweight trust experience and don’t require Zone changes on the part of the user.

-Eric Lawrence

PS: Also, please note that if the IE9 ActiveX Filtering feature is enabled, XBAP contents will be blocked even in the Trusted Zone. The user may unblock ActiveX and XBAPs using the blue icon at the right-side of the address bar.

Comments

  • Anonymous
    March 10, 2011
    Is this the same thing that keeps forcing a firefox add-on on me?

    [EricLaw]: It's hard to tell if you're just trolling here. The original .NET Framework 3.5 installer did offer a Firefox addon for XBAP support, but it was removed from Win7 and .NET 4.0.

  • Anonymous
    March 14, 2011
    Well, I was using it.  Silverlight doesn't support 3d without much workaround, so it was logical to use pages with, xbap at least until SL5 comes around.

  • Anonymous
    March 15, 2011
    I think there is actually a flaw in that adoption test.  If one checks the top 100,000 most popular websites, then there indeed must be 0 instances of xbap, simply because most popular websites are those that use Mac-proof Linux-proof technologies, which xbap is not.  That doesn't mean that a 100,000 of less popular websites don't use them, those that only target Windows. Of course, one could also reroute pages based on the browser information, and only show an xbap if requirements are met.  That also isn't something that a widest-reach oriented website would do.  But if you do, you can use the entire WPF framework.

  • Anonymous
    March 21, 2011
    @WPFUser: Don't make the mistake of thinking that we ~only~ looked at the top 100,000 sites.

  • Anonymous
    March 22, 2011
    I think Microsoft understated the use of XBAPs in the field. http://www.bighammer.com/

  • Anonymous
    March 25, 2011
    @EricLaw: I am not making that mistake, although reading literally, one could so interpret your words. I do find it ironic that it's now Firefox that runs xbaps (when properly equipped), while IE9 doesn't. So, we'll have to NOT recommend using IE9 in order to run a .NET page...?! I'd be a bit more comfortable with this new restriction if the official message was that specific vulnerabilities--real or even potential--prompted the trust limitation. Doesn't seem to be the case. But if not that, why bother restricting?

  • Anonymous
    April 14, 2011
    What is the rationale this change? I understand that the popular website may not use XBAP, but what's the harm to leave IE9 with the same XBAP support as IE8 or below? Did Microsoft experience any problems supporting XBAP in IE9? What about IE10 or above? Will Microsoft drop support for XBAP completely? [EricLaw: XBAPs expose a variety of powerful capabilities which represent a significant attack surface that is not present in the comparable alternative of ClickOnce. We have no current plans to remove XBAP entirely.]

  • Anonymous
    November 14, 2012
    homedepot.bighammer.com/.../DIY is a site that uses XBAPs and no longer works.

  • Anonymous
    January 05, 2013
    The comment has been removed