我们有一个应用程序，它使用XSLT格式化XML数据以显示为XHTML。
系统能够处理任意XML模式，因此需要由系统用户上载模式和XSLT。显然，这是一项仅允许管理员级用户执行的任务，但是这也是一个非常大的目标，所以我试图让它更安全。
我应该提到我们正在使用Saxon 9.0 B
有没有标准方法来清理用户提供的XSLT？到目前为止，我已经确定了三个可能的问题，虽然我很有意思，可能还有更多我根本没有想到的：
xsl：import和document（）函数可以在服务器文件系统中获取。这很容易使用自定义URI解析器锁定，所以我很有信心我有这个涵盖
输出可以包含javascript。我正在考虑使用像OWASP Anti-Samy这样的东西来列出允许的输出标签。
XSLT可以调用java函数。这是目前令我头疼的问题。我不想完全关闭这个功能（虽然目前我甚至看不到怎么做），因为我们正在使用它。我首选的解决方案是能够锁定可接受的java命名空间，以便只能执行已知的安全功能。我对其他建议持开放态度。
黄金标准将是一个标准库，它只处理所有已知的基于XSLT的漏洞，但未能解决上面列出的问题（尤其是3）的任何建议都会受到很多关注。
提前致谢
答案 0 :(得分：2)
Saxon有一个配置选项可禁用“自反”（动态加载）扩展功能。这并不妨碍使用已通过API在配置中明确注册的“集成”扩展功能。这似乎符合您允许服务提供商注册扩展功能的要求，但不允许样式表作者这样做。
如果需要，您可以通过定义自己的JavaExtensionFunctionFactory来控制扩展函数调用的绑定方式。这是相当低级的系统编程，您可能需要研究源代码以了解需要覆盖哪些方法以满足您的需求。
除了document（）之外，还需要考虑collection（），unparsed-text（），xsl：result-document。在所有情况下都有撒克逊钩子，可以让你控制行为。
答案 1 :(得分：0)
我不认为在服务器上上传和执行任何人的XSLT是明智之举。
有些东西无法阻止或检测，例如拒绝服务攻击，如：
无休止的递归会占用所有可用内存，并在堆栈溢出时崩溃服务器。
需要花费很多分钟或数小时的转换 - 由于暂停问题是不可判定的，我们不知道这是故意的永久循环，还是偶然的程序员错误，或者可能会或可能不会收敛的计算。 / p>
当然还有许多其他漏洞利用，例如引用递归定义的实体......