十四、XML 外部实体注入
作者：Peter Yaworski
译者：飞龙
协议：CC BY-NC-SA 4.0
XML 外部实体（XXE）漏洞涉及利用应用解析 XML 输入的方式，更具体来说，应用程序处理输入中外部实体的包含方式。为了完全理解理解如何利用，以及他的潜力。我觉得我们最好首先理解什么是 XML 和外部实体。
元语言是用于描述其它语言的语言，这就是 XML。它在 HTML 之后开发，来弥补 HTML 的不足。HTML 用于定义数据的展示，专注于它应该是什么样子。房子，XML 用于定义数据如何被组织。
例如，HTML 中，你的标签为
读完了之后，你可以大致猜测出 XML 文档的目的 -- 为了展示职位列表，但是如果它在 Web 页面上展示，你不知道它看起来是什么样。XML 的第一行是一个声明头部，表示 XML 的版本，以及编码类型。在编写此文的时候，XML 有两个版本，1.0 和 1.1。它们的具体区别超出了本书范围，因为它们在你渗透的时候没什么影响。
在初始的头部之后，标签
这里，我们拥有了内部 DTD 声明。要注意我们仍然使用一个声明头部开始，表示我们的文档遵循 XML 1.0 和 UTF8 编码。但是之后，我们为 XML 定义了要遵循的DOCTYPE。使用外部 DTD 是类似的，除了!DOCTYPE是。XML 解析器在解析 XML 文件时，之后会解析jobs.dtd的内容。这非常重要，因为!ENTITY标签被近似处理，并且是我们利用的关键。
XML 实体像是一个信息的占位符。再次使用我们之前的例子。，如果我们想让每个职位都包含到我们网站的链接，每次都编写地址简直太麻烦了，尤其是 URL 可能改变的时候。反之，我们可以使用!ENTITY，并且让解析器在解析时获取内容，并插入到文档中。你可以看看我们在哪里这样做。
与外部 DTD 文档类似，我们可以更新我们的 XML 文档来包含这个想法：
]>
Hacker
1000000
Shot the web
&url;
这里你会注意到，我继续并添加了Website的!ELEMENT，但是不是#PCDATA，而是ANY。这意味着Website可以包含任何可解析的数据组合。我也定义了一个!ENTITY，带有SYSTEM属性，告诉解析器获取wensite.txt文件的数据。现在一切都清楚了。
将它们放到一起，如果我包含了/etc/passwd，而不是website.txt，你觉得会发生什么？你可能户菜刀，我们的 XML 会被解析，并且服务器敏感文件/etc/passwd的内容会包含进我们的内容。但是我们是 XML 的作者，所以为什么要这么做呢？
好吧。当受害者的应用可以滥用，在 XML 的解析中包含这种外部实体时，XXE 攻击就发生了。换句话说，应用有一些 XML 预期，但是在接收时却不验证它。所以，只是解析他所得到的东西。例如，假设我正在运行一个职位公告板，并允许你注册并通过 XML 上传职位。开发我的应用时，我可能使我的 DTD 文件可以被你访问，并且假设你提交了符合需求的文件。我没有意识到它的危险，决定天真地解析收到的内容，并没有任何验证。但是作为一个黑客，你决定提交：
]>
&xxe;
就像你现在了解的那样，当这个文件被解析时，我的解析器会收到它，并且看到内部 DTD 定义了foo文档类型，告诉它foo可以包含任何可解析的数据，并且有个!ENTITY xxe，它应该读取我的/etc/passwd文件（file://的用法表示/etc/passwd的完整的文件 URL 路径），并会将&xxe;替换为这个文件的内容。之后你以定义
但是等一下，还有更多的东西。如果应用不打印出回应，而是仅仅解析你的内容会怎么样？使用上面的例子，内容会解析但是永远不会反回给我们。好吧，如果我们不包含本地文件，而是打算和恶意服务器通信会怎么样？像是这样：
]>
&callhome;
在解释它之前，你可能已经注意到我在callhome URL 中使用了%来代替&，%xxe。这是因为%用于实体在 DTD 定义内部被求值的情况，而&用于实体在 XML 文档中被求值的情况。现在，当 XML 文档被解析，callhome !ENTITY会读取/etc/passwd的内容，并远程调用http://www.malicous.com，将文件内容作为 URL 参数来发送，因为我们控制了该服务器，我们可以检查我们的日志，并且足够确保拥有了/etc/passwd的内容。Web 应用的游戏就结束了。
所以，站点如何防范 XXE 漏洞？它们可以禁止解析任何外部实体。
链接
查看 OWASP 外部实体（XXE）解析
XXE 速查表