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

15 Jan 2008

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:

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

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:

FireFox

http://www.thespanner.co.uk/2007/11/14/spoofing-firefox-protected-object

IE 6/7.

http://www.0x000000.com/hacks/crossdomain/crossdomain.html

Safari/Windows

http://nvd.nist.gov/nvd.cfm?cvename=CVE-2007-3514

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

http://support.microsoft.com/kb/272095

shyam

2008-12-05T05:00:08.000Z

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

Chris Weber

2008-12-06T22:51:33.000Z

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

lookout.net

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