如果您可以称我为 PHP 新手，我是一名 PHP 新手。但是在过去分析过 XML 和 XSLT 库的安全漏洞，并且最近完成了一个使用大量 XML 的应用程序的工作，这就是我能想到的：

• 如果可以传入导致特权代码执行的 XSL 转换，您可能必须找到一些方法来禁用此类执行。在 Java 世界（我来自哪里），这个“功能”不是标准，但您可以在Xalan-J 转换器中找到它实现，其中已经构建了几个扩展. 如果攻击者要传递一个 XSL 文件，该文件试图执行 SQL 查询（使用 SQL 扩展名），或执行服务器上已经可用的代码（使用 Java 扩展名），那么 Xalan-J 会这样做，如果条件是对的。我不确定这是否适用于 PHP 使用的转换器，但值得确保转换器将 XML 转换为 XML，并且不执行任何其他操作（这似乎是您的要求）。我会用更简单的话重申这一点 - 选择一个尽可能多地锁定的 XML 转换器，以仅提供转换 XML 文档的必要功能。
• 文件和其他 URI（对攻击者不可见）可以在 XSL 中指定，它们将由转换器获取并可以包含在生成的 XML 中。这是外部实体扩展（XXE）攻击。如果文件可被底层进程访问，则可以通过这种方式获取/etc/passwd等/etc/shadow。如果可以，禁用实体引用的扩展。
• 与 XXE 相关的是XDoS，它允许安装拒绝服务攻击，从而消耗 CPU 周期。对策包括：
  • 限制解析器可以执行的实体扩展的数量（类似于Java API for XML Processing 1.4 所需的安全处理支持）。这方面的一个相关对策是限制可以出现在文档中任何元素中的属性数量。
  • 禁止使用 DTD；您的解析器必须配置为拒绝其中包含 DOCTYPE 元素的任何文档。这是 SOAP 实现所采用的方法。
• 也有可能出现反射型 XSS（假设您没有使用 JavaScript 填充文本区域），因为 XSL 转换不需要生成有效的 XML 或 HTML。结果可能只是任何随机的字符序列。因此，必须对输出进行适当的转义以防止任何 XSS 攻击。
• XML 解析器本身的漏洞将使其他形式的攻击成为可能。这个 CERT 公告是一个典型的代表，因为它表明了 XML 解析库中的潜在问题。由于各种规范对解析器施加的各种要求，解析器很复杂；有时这会导致解析器无法以安全方式处理某些字符序列的极端情况。尽管编写安全解析器已经做了大量工作，但不能认为这项工作还没有完成。在这种情况下，适当的建议是选择一个实现良好且易于理解的 XML 解析库，并定期修补解析库以进行安全修复。

以上内容不一定全面，但我认为这是一个很好的起点。