Securing Extension Mechanisms [was RE: XForms custom controls?]

Robert,

> There's something in this discussion that struck a nerve...  
> Aren't we putting ourselves into a situation where we are 
> taking a controlled environment and opening ourselves up to trouble?

> I understand the need to "extend" some of the capabilities of 
> the custom controls that we rely upon (the Directory picker 
> is an excellent example as pointed out by Micah...)  But I 
> fear greatly including ANY custom code or allowing ANY code 
> that I don't have control over (sans the player of course - I 
> have to trust someone...) onto my XForms form.
> 
> I almost want to say "isn't there a better way to do this?"

You raise some interesting questions, and I don't think anyone would claim
to have all the answers. However, I do believe strongly that simply locking
everything down is not the way to go.

If anyone is interested is seeing our work to date as we try to solve this
problem, take a look a the formsPlayer 2.0 preview, which includes the
Sidewinder Viewer. We put a new version up late yesterday which includes a
contact management sample application -- an XForm that connects using
xf:submission to an ADO database. In this example the database is an Access
database, but it could be SQL Server, MySQL, and so on.


OBJECT EXTENSION
The main extension feature -- which by the way, should provide Micah with
exactly what he needs -- is the support for many of the features described
in Mozilla's version of XBL. For those not familiar with it, XBL allows you
to dynamically define objects at run-time, using an XML language. You can
specify a package of methods, properties, event handlers and an 'expansion
template', and the whole package will be applied to nodes in your source
document, based on rules you define.

fP:2.0 comes with a set of XBL files for the main XForms widgets, but the
contacts demo shows how to add further XBL -- effectively 'local' objects --
using a 'bindings' file. We'd appreciate any feedback on this technique.


OBJECT CREATION
However, there is another set of features that point towards a possible
solution to the problem you describe Robert:

> If I read basic security doctrine correctly, isn't the first 
> principle of securing your machine: Do *not* install ANY 
> external application to your machine.  If I understand 
> ActiveX controls - aren't they applications?  Or application 
> components?
> 
> Nothing stops a .NET application from having it's behavior 
> altered simply because we over wrote an ActiveX control with 
> one that is a worm.

and they relate to the creation of objects. Normally you would use:

  var x = new ActiveXObject("abc");

to create objects in script. With Windows XP SP2 this triggers a dialog box,
and it would be good to just totally close off this way of creating objects.
In formsPlayer 2, all object creation is managed through our implementation
of the DOM 3 Implementation Registry (DOM3IR), which is part of DOM 3 Core
[1]. What this means is that we can provide to the DOM document a 'factory'
which only allows a script to create those objects that have been explicitly
supported by the 'factory'.

Exactly how these objects are created will be different for different
objects. For some there are object-specific mechanisms defined in the
various specifications. For example, if a DOM supports DOM 2 Events then
there should be a createEvent() method on the DOM. We figured it was a good
idea to add such a method to the DOM in fP:2, so then you don't need to use
ActiveXObject() (and can therefore leave Windows XP SP2 set to its most
secure).

This is illustrated here by some code from the contacts demo, in which an
event is dispatched each time the timer expires:

  var evt = document.createEvent("Event");
  var oEvtList = document.getElementById("mdl-contact");

  evt.initEvent("my-timeout", false, false);
  oEvtList.dispatchEvent(evt);

This also makes our script more cross-platform, since this is how Mozilla
creates event objects.


For objects without a specific creation mechanism, we use DOMImplementation,
but via an interface placed on the DOM document object. The above example
could be coded as follows:

  var de = document.implementation.getFeature("Events", "2.0");
  var evt = de.createEvent("Event");


ADVANTAGES
Pushing all object creation through a central broker like this is pretty
powerful, since it means you can then start to enhance that broker to tackle
some of the problems that you have described. For a start, the interface:

  document.implementation

can only return features (via getFeature()) that the 'implementation' has
been set up to support, and *not* any feature from the wide range of
features installed on your computer. An 'implementation' object is created
on start-up by the Sidewinder Viewer, so obviously the features available
can be varied, but the main point is that from within the scripts
themselves, it is not possible to get outside of the context that has been
set.

I'd be interested in any comments people have on this, since it's an area
that I think will need more and more attention in the coming period, as the
number of 'browsers' grows, and documents themselves are increasingly made
up of many languages.

Regards,

Mark


Mark Birbeck
CEO
x-port.net Ltd.

e: Mark.Birbeck@x-port.net
t: +44 (0) 20 7689 9232
w: http://www.formsPlayer.com/
b: http://internet-apps.blogspot.com/

Download our XForms processor from
http://www.formsPlayer.com/

Received on Wednesday, 20 April 2005 10:42:18 UTC