即使您有一个“格式良好”的 XML 文档，也不能防止攻击 - 注入并不总是会破坏 XML 文档。为了防止 XML 注入攻击，以下措施应该有所帮助：

• 检查有效的 XML 模式定义；
• 验证/清理输入；
• 检查并执行编码；

为了我的回答完整性，我想添加几个有用的链接：

• XML 注入测试 (OWASP-DV-008)
• WASC：XML 注入
• WASC：XPath 注入
• IBM：避免 XPath 注入的危险

使用 DTD 和 XSD 的安全 XML 处理很棘手。

在使用解析器处理 xml 文件之前，您应该确保为您的用例引用了正确的 dtd 和 xsd（并且不添加混合的 xml 内容，例如备用 xmlns、xml 中的本地 dtd 定义、实体扩展等）。

正如我在 OWASP 播客上听到的OWASP Podcast 下载在这里，并且在这种情况下特别相关，将您接受的数据（xml 内容）列入白名单，永远不要将您对该内容的已知问题列入黑名单。

关闭外部引用很棒（想想有人通过使用 file:// 协议而不是 dtd 来引用您的 /etc/passwd 或 /etc/shadow 文件）。

您可以使用解析器和目录文件来控制/替换外部引用，并使用无法破坏的已知良好本地副本http://xml.apache.org/commons/components/resolver/resolver-article.html

您可以使用外部验证程序/库，例如 Sun/Oracle 的多模式验证器。http://msv.java.net/即使内部没有要验证的内容，它也可以提供验证，并且可以使用 RELAX NG 等不同/互补技术来验证您的 xml。

小心各种注入（SQL、Javascript、xmlns、image、svg、url、xslt、xpath 等），因为它们都可能被注入并传输到它们激活的上下文中，并对您的数据库服务器造成危险，应用服务器或您的客户端环境。考虑一个带有 IE 危害的 base64 编码图像，该图像被传输到您的基础设施内的网页中（游戏结束）。

您的 xml 处理基础架构上的拒绝服务也可能令人担忧，但可能与您的系统无关。

注意：@anonymous 为相关资源提供了一些很棒的 url。

不对 XML 进行语法检查的主要风险是解析无效。

如果读取 XML 的软件无法处理无效输入，它可能会崩溃、出现意外情况、自发爆炸（可能不会）等。这些情况可能会导致安全漏洞 - 但如果软件足够脆弱，无法处理处理无效的 XML，它很可能会有其他安全漏洞，甚至可能在“有效”数据中。

打个比方，大多数 Web 应用程序的安全漏洞（例如 SQL 注入）不是使用无效的 HTML 进行攻击，而是使用语法有效的输入进行攻击，这会在解析时导致问题。在您的情况下，XML 是输入。模式检查很少足以验证输入，尤其是在 XSD/DTD/自动生成的任何内容的情况下。无论处理应用程序本身的输入，也需要对其进行检查。