Subject: RE: [xsl] The evaluate function From: Joerg Pietschmann <joerg.pietschmann@xxxxxx> Date: Tue, 08 Jan 2002 14:16:05 +0100 |
"Matt G." <matt_g_@xxxxxxxxxxx> 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
Current Thread |
---|
|
<- Previous | Index | Next -> |
---|---|---|
RE: [xsl] The evaluate function, Matt G. | Thread | RE: [xsl] The evaluate function, Mark Feblowitz |
RE: [xsl] Accessing Variables while, Seema R | Date | Re: [xsl] text() and not(), David Carlisle |
Month |