Background
GRDDL specifies that some files retrieved from the Web should be interpreted as XSLT and executed in the client machine. As with any technology involving the local execution of untrusted programs, particularly in a programming language which supports both local and remote input/output operations, there is a potential risk of malicious code.
Legal
The reader is reminded that the Jena GRDDL Reader is distributed under the Jena License terms. Nothing in the documentation, including this file, should be read, as granting rights or expectations not granted under that license. In particular, the reader is reminded that:
THIS SOFTWARE IS PROVIDED BY THE AUTHOR ``AS IS'' AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (etc.)
Security Goals of Jena GRDDL Reader
Releases of the Jena GRDDL Reader should include documention covering known security issues.
The first release disables certain features of XSLT 2.0 as indicated below. These steps allow the code to pass the tests being used to explore these issues. No defences are in place against a denial of service attack.
| Feature | How disabled |
|---|---|
document()
|
Use of
javax.xml.transform.Transformer.setURIResolver()
to set a URI resolver that always throws an exception.
|
doc()
|
|
<xsl:result-document>
|
Setting value of the Saxon attribute
ALLOW_EXTERNAL_FUNCTIONS
to false,
and (the JAXP) feature
http://javax.xml.XMLConstants/feature/secure-processing
to true.
|
| extension functions [1] | |
unparsed-text()
|
A static initializer in the GRDDL code, modifies the functions tables inside Saxon, to disable these functions. |
unparsed-text-avaliable()
|
[1] However, some EXSLT and Saxon extension may still work, as determined by the Saxon implementation.
Potential Weaknesses
No features of the Java security model are used. In particularly, unsafe operations are permitted, if they are invoked in some way not involving the disabled features, or if the disabling of the disabled features fails in some way, or is circumvented by malicious code.
Any defects in the code disabling the above features of XSLT 2.0 will leave security holes.
The disabling of unparsed-text()
depends on the internals of the saxon8 implementation
of XSLT 2.0. A different version of saxon other than
that included in the GRDDL download, may have
different internals, and the code disabling
unparsed-text() may
fail to work with such a version.
Any other insecure features of XSLT 2.0 will probably result in security holes.
In particular, it is believed that
xsl:include and xsl:import
are adequately secure, and they are not disabled.
This belief may be mistaken.