RE: [xsl] The evaluate function

[Joerg Pietschmann <joerg dot pietschmann at zkb dot ch>]

"Matt G." <matt_g_@hotmail.com> wrote
> Why would someone allow users to pass input directly to an XPath evaluate
> function?  This seems to me like a bad idea.

It is. It will happen anyway. Historically, we've seen CGI scripts
containing stuff like
  grep $QUERY /path/to/files/*
which didn't seem to be bad idea until someone entered
 "* /dev/null;rm ". Defending against this kind of attacks is harder
than it may seem at the first glance. You need to quote special
characters properly, Perl aquired an regexp quoting function for
this purpose. You can, of course alternatively filter or reject
expressions with certain special characters, thereby potentially
reducing the power of the search significantly.

Checking search expressions for malicious ones is even harder in
XSLT which is not famous for its string manipulation capabilities,
even though the regexp support in 2.0 will help somewhat. And there
will be enough people who are unwilling/unable to do the checking
outside of XSLT.

Furthermore, i don't even see how the quoting approach can be
applied to non-trivial XPath expressions. And for very simple
expressions like fieldnames, evaluate() is not needed anyway
(i mean *[name()=$value] and such could be used).

>  Furthermore, proper use of
> permissions should prevent access to system configuration files.

You know, there are environments where this means serious work
and/or inconveniences at the daily work. Also, if every system
was properly configured, the traffic in comp.risks and similar
forums would be significantly reduced.

XSLT processors havn't made it yet onto the security risk lists.
I'm tempted to write about how to spy on intranets using client-side
XSLT and document()... There are also useful exploits in a server
environment, for example you can try to peek into protected material
of other customers of a hosting service. I doubt web hosters are
aware that there may be a problem.

> What is such an extension function even doing in an XSLT processor!?

You know, there are enterprises providing added value to their
customers. :-) Take a peek into the appropriate forums. Don't be
surprised about the level of stupidity occasionaly brought to
light there.

> I don't think it makes sense to handicap a standard, based on
> vulnerabilities introduced by nonstandard extensions used on poorly
> administrated systems.

I still think that you don't need evaluate() as often as claimed.
Especially i wouldn't say that omitting evaluate() will handicap
the standard. If support for evaluate() becomes mandatory, i guess
we'll see evaluate() used much more often for problems which could
be solved without it than legitimate uses, thereby unnecessarily
degrading security and performance. Actually, i'd be surprised if the
list archive contains a single real-world example which can't be
solved without evaluate() and isn't also an example of bad design.
The ones i remember included reading XPath expressions from XML
files, which could have been avoided by "XML-ifying" the expression.

I don't have problems with a standardized evaluate() functions, i just
think processor support should not be mandatory, and there should be
standardized mechanisms for example to disable access to extension
functions or to disable it completely. It's like the old discussion
about xsl:script.

Regards
J.Pietschmann

 XSL-List info and archive:  http://www.mulberrytech.com/xsl/xsl-list