没人想要 XML 里的 ENTITY 部分

　　如果你的服务器使用RSS源，可以使用这个网址测试你的应用。

　　今年早些时候，Detectify 的Fredrik和Mathias写了一篇post，解释了他们是怎么在一个传统谷歌产品中发现的一个主要XXE（“XML External Entities Exploit”）。

　　他们创建一个XML有效负载，当上传到Google后，会从目标服务器的文件系统中回显任何他们想要的文件。

　　该文章上了Hacker新闻首页，引起了我的注意。这个漏洞对我来说很新奇，我很好奇我是不是可以使用同样的技术来探索Zapier（我的电脑）。

原作者没有准确的显示或解释该漏洞，除了它涉及到XML解析。我花了几个小时学习、搜索和逆向研究到底XXE攻击是个什么东西，它是怎么应用到Zapier.

　　解析XML并不是构建网络应用最流行的方式，但有一个很大的例外：RRS订阅源-它是建立在XML之上的。

　　在了解到这些后，我可以创建一个包含ENTITY这种邪恶标签的RSS负载：

　　测试有效载荷的一个快速的方法就是使用类似 pastebin或 gists的文本托管服务。就gists而言，Github甚至会根据文件的扩展名更正首部的content-type。

　　我跳过Zapier建立了一个Zap（这个Zap用到了一个被当做触发程序的RSS），加载测试步骤...

　　WOW！这太脆弱了。不要相信LXML's的默认设置。我们发布了一个补丁，在这个补丁包中我们随处可以触碰到XML：

　　这个Python LXML库的补丁使用起来非常简单，在你使用它的时候将resolve_entities属性设置为false就可以了：

from lxml import etreeparser = etree.XMLParser(resolve_entities=False)

　　可笑的是，如果我们用我们自己整出来的XML解析，而不去碰标准的库，我们的系统就不会这么脆弱不堪了。

顶级的HN评论员当时说道:

在大型的生产环境中药避免出现问题几乎是不可能的 - 其中一些问题将会非常令人厌烦. 卓越的、具有安全意识的公司因其对待这些问题方式而显得卓尔不凡

　　像这样的问题其实是我们的责任 —— 尽管Zapier过去只是一个要小得多的公司（只有八九个人），我们也适时的决定要去实现一套问题悬赏程序。

而到如今另一个HN线程则提醒了我，要搞砸XML解析是多么的容易.

　　而这里有一个可以在你自己的系统上运行的快速测试. 特别是如果你的应用会使用RSS种子的话，就要尝试使用下面这个URL作为种子，来看看会有什么问题发生:

https://gist.githubusercontent.com/mik…

　　如果你的服务器是脆弱的，你就会在的UI界面上展示RSS文章标题的地方看到有 /etc/passwd 这样的内容显示.