Re: xsl 1.1 security model?

Michael Kay wrote:
> 
> > There's an interesting problem with xslt 1.1 client-side security.
> >
> > Two of the main features are the document and script elements.
> 
> Is the problem any different from scripts/applets run from an HTML page in
> the browser? Obviously a browser has to limit what such code can do, but I
> can't see that XSL creates any new requirements beyond dynamic HTML.
> 
One reason a lot of people are irritated by Microsoft is that they
appear not to have considered security when adding some otherwise
delightful features. Think of the Melissa virus. And the wonderfully
camouflaged shell-fragment file-type which fuelled the "I love you"
email disaster.

I really don't want the XML community to follow this particular
precedent. Let's start considering security isuues, explictly, even if
we find don't have change a single feature this time round.

> > I think that the spec should say something about user-agents
> > having the ability to disable xsl:script (for anything except XSLT, of
> course).
> 
> I guess a note to that effect wouldn't do any harm. But of course the
> implementor has the option to ignore xsl:script entirely, so such a note
> wouldn't add anything substantive to the spec.
> 
The ability to write to multiple named documents seems to me to be just
as dangerous as the ability to call external scripts (if not more so -
after all, ecmascript has no standard way of writing to named files).

Should the xsl:document element be enabled client-side, or is the answer
so obvious that the question didn't need asking?

And would an implementation that disabled the xsl:document element
client-side still be XSLT 1.1 compliant?

Francis.

 XSL-List info and archive:  http://www.mulberrytech.com/xsl/xsl-list