This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
NOTE: I haven't seen the current version of the editor copy and this issue may already have been addressed. Sorry for the noise it that's the case. When not properly used, this function can be a back door for code injection (see http://www.balisage.net/Proceedings/vol7/html/Vlist02/BalisageVol7-Vlist02.html). A simple way to provide a safer way to use this kind of feature is store user input in variables and to make reference to these variable in the XPath expression that is evaluated. However, it is not always safe either to give access to the whole scope of variables that are available where the function is being called. My suggestion would be to have the following signature for this function: xsl:evaluatehttp://www.balisage.net/Proceedings/vol7/html/Vlist02/BalisageVol7-Vlist02.html(xpath as xs:string, parameters as map()?) as item()? The second argument (parameters) would be a map defining the variables passed to the XPath expression (the keys would be considered as variable names). The safest way to limit any kind of leakage and sandbox the XPath expression would even be to evaluate the XPath expression with not even a context node (the context node could still be passed as a parameter in the map): xsl:function("$context/foo[@bar=$value]", map{'context':= ., 'value' := $user-input}) Of course, you could still use the function in a unsafe way but at least you'd have the tools to make it easy to use it safely! Does that make sense? Eric
The current specification uses an instruction xsl:evaluate, with nested xsl:with-param elements to define the values of any variables used in the constructed XPath expression. The expression does not have access to the variables defined in the stylesheet, other than any variables explicitly passed using xsl:with-param. Using an instruction rather than a function also allows control over other aspects of the context such as the namespace bindings and the base URI. (We specified xsl:evaluate before we had maps, which is perhaps why we don't pass the parameters as a map). Of course, the risk of injection remains if people (rather than using parameters) use string concatenation to construct the expression, without adequate checking. I think it's entirely appropriate to include a warning of the risks.
(In reply to comment #1) > The current specification uses an instruction xsl:evaluate, with nested > xsl:with-param elements to define the values of any variables used in the > constructed XPath expression. The expression does not have access to the > variables defined in the stylesheet, other than any variables explicitly passed > using xsl:with-param. > > Using an instruction rather than a function also allows control over other > aspects of the context such as the namespace bindings and the base URI. (We > specified xsl:evaluate before we had maps, which is perhaps why we don't pass > the parameters as a map). An instruction is also more coherent with function definitions. I wonder how you can return nodes, unless maybe if the instruction is a declaration (like an SQL prepare statement) separate from the actual call but I guess I'd rather wait for the next Working Draft than make blind guesses! > Of course, the risk of injection remains if people (rather than using > parameters) use string concatenation to construct the expression, without > adequate checking. I think it's entirely appropriate to include a warning of > the risks. Yes. Thanks, Eric
Instructions have always been able to return nodes, it's just slightly inconvenient to access those nodes from within an XPath expression - you have to bind the result of the instruction to a variable, or return it as the result of a function. A recent idea that's been suggested (no more than that) is to allow any instruction to have an attribute bind="name" which makes the instruction act like a variable declaration, binding its result to the given variable name.
I have drafted the following (non-normative) Note which I propose adding to the spec: <note><p>Stylesheet authors need to be aware of the security risks associated with the use of <elcode>xsl:evaluate</elcode>. The instruction should not be used to execute code from an untrusted source. To avoid the risk of code injection, user-supplied data should never be inserted into the expression using string concatenation, but should always be referenced by use of parameters. Implementations <rfc2119>should</rfc2119> provide mechanisms allowing calls on extension functions to be disabled.</p></note>
Corrected version of the proposed note: I have drafted the following (non-normative) Note which I propose adding to the spec: <note><p>Stylesheet authors need to be aware of the security risks associated with the use of <elcode>xsl:evaluate</elcode>. The instruction should not be used to execute code from an untrusted source. To avoid the risk of code injection, user-supplied data should never be inserted into the expression using string concatenation, but should always be referenced by use of parameters. Implementations <rfc2119>should</rfc2119> provide mechanisms allowing calls on <elcode>xsl:evaluate</elcode> to be disabled.</p></note>
The WG accepted the proposal in comment 5, and believes this is sufficient to resolve the bug. Eric, if you accept this, please close the bug.
Sounds good, thanks!