[Bug 16151] New: Security concern about xsl:evaluate

https://www.w3.org/Bugs/Public/show_bug.cgi?id=16151

           Summary: Security concern about xsl:evaluate
           Product: XPath / XQuery / XSLT
           Version: Working drafts
          Platform: All
        OS/Version: All
            Status: NEW
          Severity: normal
          Priority: P2
         Component: XSLT 3.0
        AssignedTo: mike@saxonica.com
        ReportedBy: vdv@dyomedea.com
         QAContact: public-qt-comments@w3.org


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

-- 
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:12:37 UTC