Xalan could play in the general Java Security Manager framework and allow you to bound the set of extension functions, if only by allowing you to specify the classloader.
On Mon, Mar 2, 2009 at 12:57 PM, Johan Zxcer <nab...@zurahn.com> 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. >> >> > > -- > View this message in context: > http://www.nabble.com/Usage-model---no-source-XML%2C-just-api-calls-tp22264025p22293216.html > Sent from the Xalan - J - Users mailing list archive at Nabble.com. > >
