Re: Usage model - no source XML, just api calls

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 <[email protected]>
>> Date: Sun, Mar 1, 2009 at 8:46 PM
>> Subject: Re: Usage model - no source XML, just api calls
>> To: Dave Brosius <[email protected]>
>>
>>
>> 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:[email protected]
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