Applying domain restrictions to a browser plugin (ActiveX or XPCOM)

For Internet Explorer, there's Microsoft's Sitelock. For Mozilla, I'm not sure what there is... In that case, we've been working on some solutions that could hold up cross-browser on a Windows platform. Sitelock takes a solid approach, check out the code and you'll see it implements the IObjectSafetySiteLockImpl, replacing the ATL IObjectSafety interface. What am I talking about? Well sometimes, when you develop a browser plugin like an ActiveX control for IE or an XPCOM object for Mozilla, you only want it to load and run from a few trusted domains. The plugin/control runs potentially powerful code after all, executing in the user's context. For example, you're a large social networking site, and your new control helps synchronize offline and online data for the user. Well first off, you want to make sure it's secure as possible:

  1. code flaws have been identified and addressed (buffer overflows, leaks, etc.)

  2. repurposing threats have been identified and mitigated (the control should not do anything more than it needs, and should be very careful when performing file, registry, or network operations)

To gain a higher level of assurance that this control won't be exploited, you take more steps to restrict the domains which are allowed to call it.

So without Sitelock for Mozilla, we're in search of an alternative solution that will work across both IE and Mozilla. We know a few things available for the cross-browser domain restriction solution:

  • we can use C/C++

  • we have access to the DOM

  • we have access to COM+

  • we'd like access to WININET but that's too far down the stack

Right now, we're primarily interested in getting the true domain which is loading and calling the plugin. How can we gaurantee this? We try getting it from the DOM's document.domain property, but know that the document.domain property has historically been a source of security vulnerability in all major browsers. There have even recently been ways to spoof the address bar, or the domain property using JavaScript and other means, and there likely will in the future. For example:


IE 6/7.


After some research we're testing some other options. Right now our best bet might be looking like:

  • using IWebBrowser2::get_LocationURL() for Internet Explorer

  • using window.location.href for Mozilla

  • InternetCrackUrl() to parse the hostname

  • After some testing we don't see the document.domain type issues present in window.location.href, so it seems to be holding up short some unknown browser-flaw.

nice article,
can you tell me the solution to check if xpcom component is running from trusted site.

Last I checked it was checking window.location.href for Mozilla and then using InternetCrackUrl() to parse the hostname.