W3C home > Mailing lists > Public > public-qt-comments@w3.org > February 2012

[Bug 16151] Security concern about xsl:evaluate

From: <bugzilla@jessica.w3.org>
Date: Tue, 28 Feb 2012 17:44:53 +0000
To: public-qt-comments@w3.org
Message-Id: <E1S2R6b-00061b-Iu@jessica.w3.org>
https://www.w3.org/Bugs/Public/show_bug.cgi?id=16151

--- Comment #2 from Eric van der Vlist <vdv@dyomedea.com> 2012-02-28 17:44:52 UTC ---
(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

-- 
Configure bugmail: https://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.
Received on Tuesday, 28 February 2012 17:45:00 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 16:57:37 UTC