- From: Michael Kay <mhk@mhk.me.uk>
- Date: Fri, 20 Aug 2004 16:00:27 +0100
- To: <public-qt-comments@w3.org>
- Cc: <tvs@hawaii.edu>
Ted Shaneyfelt commented on 13 Aug 2004: "This is likely to quietly open countless security breaches where webmasters in the past have trusted xslt to be uploaded and to execute on their machines because of it's safe nature. By simply upgrading an operating system or other component, the system will quietly become vulnerable to simple attacks." This comment somehow escaped my attention until now. Apologies for not responding. I added the warning about the security implications of XSLT extension functions because I had become aware that many users (and some implementors) were unaware of the risks. At one stage W3C itself was running an XSLT conversion service on its servers that allowed users to submit arbitrary stylesheets that were able to call Java methods on the server where they ran: I was able to demonstrate that this gave me the ability to obtain a full directory listing of the server, and I could probably have modified or deleted files had I chosen to do so. I don't think we can prohibit extension functions entirely, but I do think we can do more to alert vendors and users to the risks, and I'm pleased that you spotted the paragraph which attempts to do so. I think we must leave the question about how security is configured to individual vendors. Your suggestions about using a mime type are interesting, but would only be useful if vendors of client-side XSLT-aware browsers were prepared to modify their products. My own product, Saxon, has a switch to disable all use of extension functions. As I'm sure you realize, there's no difference here between XSLT 2.0 and 1.0. Michael Kay
Received on Friday, 20 August 2004 15:01:01 UTC