Hi,
We built a (web) content management system using Xalan XSLT for
transforming XML-documents into one HTML file. We basically use your
described model: we start by running an XSL without a source document
(or actually an empty XML document). The XSL may then call Java methods
on a given context-object (a Java object which is given as a parameter
to the Transform). In our system, a call to the context object could
invoke another XSL transform on an XML-document, returning the result of
the transform for further processing. This may result in a complex tree
of transforms.
As a simple example:
<xsl:stylesheet xmlns:java="http://xml.apache.org/xslt/java";
exclude-result-prefixes="java">
<xsl:param name="context"/>
<xsl:template match="/">
<result>
<xsl:value-of select="concat('Hello,', java:getUserName($context))"/>
</result>
</xsl:template>
</xsl:stylesheet>
The 'context' object may be any Java object which has the method
'getUserName()'. You could create a different 'context' instance, based
on the authorization of the client. In fact, you could check the client
XSL's by processing them with your own XSL and check if only the
'context' parameter is used for Java-calls.
Dennis
Johan Zxcer wrote:
I disagree that Xalan by definition is doing something that should have to be
treated specially versus all the other packages I must trust in order to
build a service.
Assume a web client-server app with the proper layers of security and
authentication in place. Add to this an XSL processor with extensions
disabled (and proper settings to avoid deep recursion etc); the style-sheet
itself is anything from the client, but the static data source is strictly
controlled by the server. No issue here, the processor is strictly bound by
the data provided to it, no need for an extra layer of security.
Now I want to expose a useful function - say sin(). If I could specify that
just the Math class be exposed for use as extensible functions, have I
changed my security vulnerabilities? No, I'm simply exposing a controlled
set of functions; there's no reason to suddenly make everything more complex
simply to isolate the processor. But if the only choice is to expose all
classes available to a given process, I am forced to create a separate
process to manage these, including the IPC needed to get to the information
back and forth.
Now I'm not at all against doing the work necessary to build a secure
application, but this forces a particular architecture that adds a lot of
complexity and maintenance, when a simple whitelist would be just as secure
(and perhaps more secure in the grand scheme, how many Xalan users have
built apps not realizing that by default all java classes are available to
be run by a *style sheet*?)
Back to practical reality though, it sounds like there is no such API
mechanism built in to Xalan. However looking at the extension/ObjectFactory
class, I may be able to accomplish what I need by temporarily changing the
current SecurityManager in place to set the limits I need, and Xalan will
respect that. Not exactly thread safe, I'll post how it works out though..
bimargulies wrote:
From: Benson Margulies <bimargul...@gmail.com>
Date: Sun, Mar 1, 2009 at 8:46 PM
Subject: Re: Usage model - no source XML, just api calls
To: Dave Brosius <dbros...@mebigfatguy.com>
This whole story doesn't make sense entirely from a security
standpoint. Let's see if I've got this straight:
people you don't trust to look at the data are allows to write and
render stylesheets. The JVM is connected to a database full of data
they aren't allowed to see in detail, only in summary. You are
concerned that they will go fishing for functions that would allow
them to grab what they cannot see.
From a security standpoint, I'd say that you need some more
architecture here. Like, put the sensitive data behind a web service,
require authentication, and have the web service API be just the
allowed aggregating functions. Then turn them loose on Xalan/xslt,
secure in the knowledge that all they can do by being cute is shoot
themselves in the feet.
--
Dennis van der Laan
begin:vcard
fn:Dennis van der Laan
n:van der Laan;Dennis
org:Center for Information Technology;Application Development
email;internet:d.g.van.der.l...@rug.nl
title:Software Engineer
tel;work:+31 50 363 9273
x-mozilla-html:FALSE
url:http://www.rug.nl/staff/d.g.van.der.laan
version:2.1
end:vcard
