文章总结： 这份文档是对CVE-2026-82329（JFrogArtifactory认证缺陷，CVSS9.8）PoC仓库的深度审计报告。核心发现包括：仓库为机器生成的检测脚本集合而非利用工具；poc.py内置6类认证绕过手法清单，覆盖Tomcat系中间件经典绕过家族；vulnerable-app为Flask行为模拟器而非真实Artifactory。建议将检测逻辑当数据管理，实网使用需人工确认evidence字段，并警惕curl|bash供应链风险。 综合评分： 90 文章分类： 漏洞分析,代码审计,安全工具,渗透测试,红队
CVE-2026-82329
网安之家-CyberHomestead
2026年9月2日 08:00 湖北
在小说阅读器读本章
去阅读
在公众号小说中沉浸阅读
Part’counter(counterh1CVE-2026-82329 PoC 仓库审计报告：JFrog Artifactory 认证缺陷的检测、原理与落地
分析对象：https://github.com/HORKimhab/CVE-2026-82329 上游来源：fankh/vulnerability-poc（仓库 README 自述的 Credit） 用途声明：授权测试 / 教学研究。文中所有攻击面分析均基于仓库自带 Docker 靶场与检测脚本，仅限在自有实验环境复现。
ounter(counterh20. 先说结论（TL;DR）
- 这不是一个”工具”，而是一个机器生成的 CVE 复现靶场 + 检测脚本集合。仓库描述写着 “Draft or TODO”，README 结尾有一行
Generated by PoC Generator on 2026-08-29，说明整个目录是 fankh PoC 集合的自动镜像，加了捐赠二维码和 SEO 关键词。审计它要把它当”样本”看，而不是当”武器”看。 - CVE 本体：JFrog Artifactory 在默认配置下存在认证弱点（CWE-287 Improper Authentication），CVSS 9.8，未认证的网络攻击者可获取管理员权限。仓库内
poc.py定位是 检测（detection-only），不含真正的利用原语。 - 仓库里的 “vulnerable-app” 不是 Artifactory，是一个 Flask 写的行为模拟器：它复刻的是”默认凭据 + 默认 API Key 前缀即可拿管理员”这条缺陷逻辑，用来给 poc.py 提供靶子。
- 真正有价值的部分是 poc.py 内置的 6 类认证绕过手法清单（
;/路径参数、//双斜杠、X-JFrog-Override-Base-Url头、X-Forwarded-* 伪造、anonymous Basic 头、默认凭据爆破），这些对应的是 Java/Tomcat 系中间件认证绕过的经典家族，在实网 Artifactory 及同类中间件上长期有效。 - 文风提示：这个仓库的 README 里有
bash <(curl ...)一键执行外部脚本的引导。任何 curl|bash 之前先审脚本，这本身就是一个供应链攻击面。
ounter(counterh21. 名字、来历与”前世今生”
1.1 命名拆解
- CVE-2026-82329：标准 CVE 编号格式
CVE-年份-序号。编号本身没有语义，语义来自发布机构的描述：“JFrog Artifactory contains an authentication weakness that, under default configuration, may allow an unauthenticated attacker with network access to obtain administrative privileges.” - 目录名
CVE-2026-82329-fankh：fankh是上游 PoC 收集仓库的作者名，这个后缀用来标记内容来源，避免和同名目录冲突。 - User-Agent
AttackWatch-PoC-Scanner/1.0（poc.py 内置）：说明 poc.py 是从一个叫 AttackWatch 的 PoC 生成流水线里出来的，README 那行Generated by PoC Generator是同一条流水线的指纹。
1.2 仓库生态位
HORKimhab 这个账号维护着一组互相关联的仓库：awesome-cybersecurity-resources（资源合集）、poc-cve-collection（PoC 集合）、本仓库（单 CVE 镜像）。本仓库的模式是：从 fankh/vulnerability-poc 同步单条 CVE 的 PoC + 靶场，套上免责声明、捐赠码、韩语翻译，形成独立仓库。提交历史只有一条 sync: CVE-2026-82329，印证了”同步镜像”的定位。
1.3 历史脉络：Artifactory 的认证绕过家族史
JFrog Artifactory 是制品库（Maven/Docker/npm 私服），常年部署在企业内网核心区，持有大量构建凭据和部署 API Key，因此历来是认证/授权缺陷的重灾区。历史上反复出现的问题模式：
| 模式 | 机制 | 本仓库对应检测项 |
| — | — | — |
| Tomcat 路径参数绕过 | Spring/Tomcat 对 ;jsessionid=x 的截断处理与安全过滤器不一致，/api/security/users;jsessionid=x 让鉴权过滤器匹配不上受保护路径 | Path parameter bypass |
| 路径规范化差异 | 反代/过滤器做 .. 归一化，后端路由不归一（或反之），/api/repositories/..;/api/security/users 穿越 | Path traversal ;/../ |
| URL 解析歧义 | //artifactory//api//... 双斜杠导致过滤器前缀匹配失败 | Double slash bypass |
| 内部 Header 信任 | X-JFrog-Override-Base-Url 等运维头被当作可信输入，可影响重定向/base-url 计算进而绕过 | Header injection |
| 反代头伪造源 | X-Forwarded-For: 127.0.0.1 让”仅本机可访问”的检查失真 | Forwarded header spoof |
| 默认/匿名凭据 | 出厂 admin 默认口令、匿名访问开启、默认 API Key 前缀 AKCp5 | Default credentials / Anonymous Basic |
AKCp5 是 Artifactory API Key 的真实前缀（Access Key token 以 AKCp 开头是公开常识），说明生成流水线至少核对过产品事实。这也是审计这类自动生成 PoC 时的基本功：区分哪些是”生成器模板话术”，哪些是”产品真实特征”。
ounter(counterh22. 仓库结构总览
CVE-2026-82329/
├── README.md # 顶层：捐赠、免责、一键脚本、SEO 关键词
├── LICENSE
└── CVE-2026-82329-fankh/
├── README.md / README_KO.md # CVE 说明（英文/韩文）
├── poc.py # 16.7KB，核心：四阶段检测器
├── docker-compose.yml # 双容器靶场（漏洞版 8080 / 修复版 8081）
├── run-tests.sh / run-tests.ps1
├── vulnerable-app/ # Flask 模拟的"带缺陷配置"实例
│ ├── app.py # 5.9KB
│ ├── Dockerfile
│ └── requirements.txt # flask + requests
└── patched-app/ # 修复对照版
├── app.py # 6.5KB
├── Dockerfile
└── requirements.txt
设计思路是标准的 红蓝对照三件套：一份检测脚本 + 漏洞靶场 + 修复靶场，用 run-tests.sh 串成回归测试。这个结构本身值得抄——写任何 PoC 都应该带一个”修复版”证明检测逻辑不是恒真。
ounter(counterh23. poc.py 逐行审计：四阶段检测流水线
3.1 架构
check_vulnerability() 是编排器，按证据强度递进：
Stage 1 产品识别(check_product) —— 被动，指纹
Stage 2 版本判定(check_version) —— 被动，读版本接口/响应头比对区间
Stage 3a 绕过验证(test_bypass_based) —— 主动，6 类绕过 + 4 组默认口令
Stage 3b 缺口验证(test_auth_check) —— 主动，7 个管理端点未授权可达性
置信度是手工配权的：版本匹配 30~40 分，每个未授权可达端点 +10（封顶 95），每个绕过成功 +5（封顶 98）。这种”证据累加打分”的写法比二值判断更适合大规模扫描降噪。
3.2 值得学的细节
产品指纹多信号汇聚（check_product）：不赌单一特征，而是同时看四个响应头（X-Artifactory-Id、X-Artifactory-Node-Id、X-JFrog-Version、Server 含 artifactory）加一个 body 关键词，任一命中即判定。遇到反代剥离头的情况也能靠 body 兜底。
版本提取三层降级（check_version）：JSON 字段（version/artifactoryVersion）→ 正则抓 x.y.z → 响应头 X-JFrog-Version/X-Artifactory-Version。版本区间用两条正则表达：
(r"^([0-6]\.[0-9]+\.[0-9]+)", "6.x and below"),
(r"^7\.([0-9]|[1-6][0-9]|7[0-1])\.[0-9]+", "7.0.x - 7.71.x")
第二条的正则写法有个容易被忽略的妙处：7\.([0-9]|[1-6][0-9]|7[0-1])\. 用”两位数枚举”而不是 7\.7[0-9]\. 之类的宽匹配，精确把 7.0–7.71 圈进区间、把 7.72+ 排除。审计时如果只扫一眼很容易漏掉这个边界。
_looks_authenticated() 的启发式判定是整个脚本最核心的函数，值得逐条看：
if resp.status_code in (401, 403): return False # 显式拒绝 = 认证在
if resp.status_code >= 500: return False # 5xx 视为不可判
if resp.status_code not in (200, 204): return False
# body 含 "authentication required"/"unauthorized" 等 → 判假
# body 含 "artifactory-config"/"repositories"/"users"/'"key":"' → 判真
# 200 且非 HTML 且非空 → 判真（兜底，防自定义页面）
它防住了两个经典误报：一是返回 200 但 body 其实是登录页（用 unauth_markers 排除），二是纯靠状态码误判（用 auth_markers 要求出现管理数据特征）。最后的”200 + 非 HTML”兜底则是为了适配返回纯 JSON/文本的 API。副作用是这个兜底也可能误报（任何非 HTML 的 200 都算成功），所以实网用时要读 evidence 字段人工确认。
绕过手法数据化：6 个绕过被写成 {name, path, headers} 数组而不是散落的函数，加手法只需要加一条字典——这是把”检测逻辑”当数据管理的典型好品味，方便批量维护和 YAML 化外置。
3.3 值得吐槽的细节
--callback参数解析了、传了，但check_vulnerability(callback_url=...)里根本没用。这是 PoC 生成器模板里预留 OOB 检测插槽没填上的痕迹。审计这种机器生成代码要习惯这种”半成品接口”。-c/--check是默认行为，不传也一样，属于冗余参数。- 默认口令爆破放在绕过测试里且成功就
break，没有做Retry-After处理，对启用了账户锁定的真实目标会触发告警——检测脚本本身也是攻击流量，这个要在授权范围内用。 _looks_authenticated里'"key":"'这类 marker 大小写敏感（先 lower 过所以实际没问题），但auth_markers里混了大小写不同的写法，阅读成本高。
ounter(counterh24. vulnerable-app/app.py 审计：模拟器的”缺陷”是怎么写的
它不是真 Artifactory，而是把缺陷逻辑抽成三个可被 poc.py 命中的行为：
# 1) 默认凭据:admin/password (sha256 落库),无首登强制改密、无 MFA、无锁定
USERS = {"admin": {"password_hash": sha256("password"), "role": "administrator",
"default_credentials": True,
"api_key": "AKCp5" + "a"*68}}
# 2) 认证端点:命中默认凭据直接发管理员会话 + 吐 API Key
@app.route('/api/security/authenticate', POST)
... session['role'] = 'administrator'; return {"api_key": ...}
# 3) 管理端点的"前缀校验"缺陷 —— 这是全文件最精妙的一处:
@app.route('/api/admin/system')
api_key = request.headers.get('X-JFrog-Art-Api', '')
if api_key and api_key.startswith("AKCp5"): # ← 只验前缀!
...授予 user_management/system_configuration/repository_admin/license_management
审计重点：startswith("AKCp5") 这一行就是整个模拟漏洞的”题眼”。真实世界里对应的缺陷类是”密钥格式校验代替密钥归属校验”——即用密钥的外形特征做授权决策，而不是查表验证完整密钥。任何人猜到前缀就能过。修复版的对照写法是 hmac.compare_digest(token, USERS[user_id].get('session_token',''))，做完整值常量时间比较。这一对代码放在一起，就是”认证五要素”（你是谁、你怎么证明、证明给谁看、凭什么授权、凭什么抗爆破）的活教材。
另外它有配置漂移类的小 bug：容器内 app.run(port=8081)，而 Dockerfile EXPOSE 5000、compose 里又是 8080:5000 映射——实际上 Flask 监听 8081，容器 5000 端口没人听，这个靶场直接 docker-compose up 起来是连不上的（/health 检查的路径在 vulnerable-app 里也不存在，只有 /）。这正是自动生成 PoC 的典型质量问题：三个文件的端口约定互相对不上。跑这个靶场需要手工把 app.py 的端口改成 5000，或把 compose 映射改成 8080:8081。
到操作系统调用层的追踪（把这条认证缺陷链落到 syscall）：
攻击端 (poc.py):
requests.request() → urllib3 → http.client
→ socket.getaddrinfo(target) # libc 解析器, /etc/hosts → DNS UDP/53 或 TCP/53
→ socket.connect(fd, sockaddr_in) # syscall connect(2), 三次握手 SYN→SYN/ACK→ACK
→ send/write(fd, http报文) # syscall sendto(2)/write(2), TLS 则经 OpenSSL SSL_write
→ recv/read(fd) # syscall recvfrom(2), 内核协议栈软中断收包
服务端 (Flask/Werkzeug):
accept(fd) → 新 conn fd # syscall accept4(2), werkzeug ThreadedWSGIServer 每连接一线程 → clone(2)
读取请求 → 解析 WSGI environ # 纯用户态字符串处理, 无额外 syscall
sha256(password) # 调 OpenSSL EVP → 内核 crypto 子系统(或 AES-NI/SHA-NI 硬件指令)
session 签名 # itsdangerous HMAC-SHA1, 用户态
jsonify 响应 → write(fd) # 回包
认证缺陷本身全部发生在用户态应用逻辑，不涉及内核漏洞；OS 层面能加的闸门是：防火墙把管理端口限制到管理网段（iptables -A INPUT -p tcp --dport 8081 ! -s mgmt/24 -j DROP）、sshd/consul 等同类的”默认监听 0.0.0.0″收敛。这解释了为什么 advisory 强调 “with network access”——网络可达是唯一前提。
ounter(counterh25. patched-app 审计：修复版做对了什么
diff 全量读过，修复版是一个教科书级加固清单，逐条对应漏洞成因：
| 修复项 | 对应缺陷 | 代码位置 |
| — | — | — |
| 删除默认凭据，ADMIN_INITIAL_PASSWORD 环境变量强制注入且 ≥16 字符，否则 RuntimeError 拒绝启动 | 默认口令 | require_admin_setup() |
| must_change_password=True 首登强制改密 | 无强制轮换 | 同上 |
| FAILED_ATTEMPTS + 5 次锁定 15 分钟（HTTP 429） | 无速率限制 | is_locked_out()/record_failed_attempt() |
| check_password_hash （PBKDF2-SHA256 60 万轮）+ 用户不存在时也算 dummy hash | 弱哈希 + 时序侧信道枚举用户名 | login() |
| session.clear() 后再发新 token，token 双存（session + 服务端）并用 hmac.compare_digest 校验 | 会话固定 | login()/require_auth() |
| @require_auth(role='admin') 装饰器统一鉴权 | 各端点自己判、判法不一 | 全部端点 |
| SESSION_COOKIE_SECURE/HTTPONLY/SAMESITE=Strict + 30 分钟生命周期 | 会话 cookie 弱配置 | app.config.update |
| 默认绑定 127.0.0.1，BIND_HOST 显式才对外；可选 ssl_context='adhoc' | 默认 0.0.0.0 暴露 | app.run() |
有一处细节很见功力：登录时对不存在的用户名也执行一次 check_password_hash(dummy_hash, ...)，让”用户存在”与”用户不存在”的响应时间一致，防时序枚举。这在一行注释都没解释为什么的地方默默做了正确的事（好在它写了 SECURITY FIX 注释系列，整体可读性其实相当好）。
它的 README 倒是暴露了生成器套模板的痕迹：声称修复包括 “Parameterized queries (for SQL)”、”Safe subprocess execution (for RCE)”——这个纯认证缺陷的应用里根本没有 SQL 和子进程，是模板文案没裁剪。
ounter(counterh26. 攻击链与渗透测试定位
6.1 这类缺陷在真实杀伤链中的位置
侦察 → [本工具: 版本指纹/管理面探测]
初始访问 → [默认凭据 / 认证绕过 = 切入点, ATT&CK T1078 Valid Accounts / T1190 Exploit Public-Facing App]
权限提升 → [admin 角色即顶格: 用户管理/系统配置/仓库管理]
后渗透 → [持久化: 建后门用户/换锁 API Key; 凭据收割: 仓库配置里的构建凭据、CI 部署 key]
横向 → [用收割的部署凭据打 CI/CD (Jenkins/GitLab Runner), 污染构建产物 → 供应链]
Artifactory 作为制品库的特殊价值在第四、五环：它存的不只是二进制，还有部署凭据和上游仓库代理配置；拿到 admin 后改一个远程仓库指向恶意镜像源，就能对全公司构建管道投毒——这是比”进后台”严重一个量级的后果，也是 CVSS 9.8 的实际含义。
6.2 防守侧检测点（蓝队直接可用）
- WAF/日志告警：URL 含
;jsessionid=、..;/、//artifactory的请求；出现X-JFrog-Override-Base-Url头的请求。 - UA 告警：
AttackWatch-PoC-Scanner/1.0（本 PoC 的指纹，一抓一个准）。 - 行为告警：匿名访问
/artifactory/api/system/configuration、/api/security/users返回 200；短时间内对/api/security/authenticate的多组凭据尝试。 - 资产面：出网方向禁 8081/8082（Artifactory 管理口）直达；
curl -s http://<host>/artifactory/api/system/ping匿名返回 200 即需排查。
6.3 推荐工具组合（授权测试场景）
| 环节 | 工具/命令 |
| — | — |
| 资产发现 | nuclei -tags jfrog 、fofa/hunter 语法 header="X-Artifactory-Id" |
| 指纹+版本 | 本 poc.py --version-only、httpx -title -tech-detect |
| 绕过验证 | Burp 手工重放 6 类 bypass（比脚本更可控）、ffuf -H "X-Forwarded-For: 127.0.0.1" |
| 口令审计 | hydra -L u -P p artifactory-http-post （授权口令审计） |
| 后渗透 | Artifactory REST API（/api/storage、/api/build 枚举构建凭据） |
ounter(counterh27. Cheatsheet：把参数当”功能模块”的命令配方
poc.py 的参数面（python3 poc.py -h）：
-t, --target TARGET 目标 URL（必填）
-c, --check 执行漏洞检测（默认行为）
--version-only 仅被动版本判定，跳过主动测试
--callback URL OOB 回连地址（模板预留，实际未实现）
-v, --verbose 过程输出到 stderr
--timeout N 单请求超时秒数（默认 10）
退出码: 0=未检出/未漏洞, 1=检出漏洞, 2=出错或中断
配方设计的核心思路：-t 是注入点，--timeout 是节流阀，-v 是调试口，退出码是编程接口。把它嵌进脚本时只依赖 exit code 和 stdout 的 [VULNERABLE] 标记，其余全走 stderr。
配方 1：单目标标准检测（人肉值守）
python3 poc.py -t https://artifactory.corp.example -v --timeout 8
配方 2：批量资产 + 退出码分流（机读管道）
cat targets.txt | while read -r t; do
python3 poc.py -t "$t" --timeout 6 >/dev/null 2>&1
case $? in
1) echo "[HIT ] $t" | tee -a hits.txt ;;
0) echo "[MISS] $t" ;;
*) echo "[ERR ] $t" >> errors.txt ;;
esac
done
退出码即状态机，case 三分支正好对应 PoC 的三种结局，errors.txt 留待限速重试。
配方 3：两段式扫描（先被动圈范围，再主动验证）
# 第一遍: 只做版本指纹, 零告警风险
grep -f live_hosts.txt /dev/null | while read -r t; do
python3 poc.py -t "$t" --version-only 2>/dev/null \
| grep -q "POTENTIALLY" && echo "$t" >> maybe.txt
done
# 第二遍: 只对可疑目标做主动测试, 授权窗口内执行
xargs -a maybe.txt -I{} python3 poc.py -t {} -v 2>>active.log
被动/主动分层是实网作业的纪律：版本匹配本身不产生攻击特征，先筛掉 90% 资产再打流量。
配方 4：并发调度 + 速率控制（GNU parallel）
parallel -j 4 --joblog scan.log python3 poc.py -t {} -v --timeout 8 \
'::: $(cat targets.txt)' 2>/dev/null
grep -c "1\b" scan.log # joblog 第 7 列退出码=1 即命中
-j 4 控并发防止打挂目标（这脚本没有内置限速，调度层补）。
配方 5：与 Nmap 联动的资产闭环
nmap -p 80,443,8081,8082 --open -iL net.txt -oG - \
| awk '/open/{print $2}' | sort -u > art_hosts.txt
while read -r h; do
for scheme in https http; do
python3 poc.py -t "$scheme://$h:$( [ $scheme = https ] && echo 443 || echo 80 )" \
--version-only 2>/dev/null | grep -q "JFrog\|Artifactory" && echo "$h" >> candidates.txt
done
done < art_hosts.txt
Nmap 负责开路，PoC 负责定性，中间用文件做契约，两个工具互不感知——这就是”参数模块化”的意义：任何工具都能插进同一条流水线。
配方 6：靶场回归测试（本仓库自带流程 + 修复项）
cd CVE-2026-82329-fankh
# 注意: vulnerable-app/app.py 里 app.run(port=8081) 与 compose 的 8080:5000 映射冲突, 先改端口再起
sed -i 's/port=8081/port=5000/' vulnerable-app/app.py
docker compose up -d --build
sleep 8
./run-tests.sh # 对 8080 应 [VULNERABLE], 对 8081 应 [NOT VULNERABLE]
预期结果：漏洞版命中”默认凭据/未授权管理端点”，修复版全部拒绝。若修复版也报 VULNERABLE，说明你的检测逻辑有恒真假阳性——这就是配修复靶场的全部意义。
配方 7：手工等价 curl（没有 Python 环境时的降级）
# 指纹
curl -sk -D- https://target/artifactory/api/system/ping | grep -i "x-jfrog\|artifactory"
# 版本
curl -sk https://target/artifactory/api/system/version | grep -o '"version":"[^"]*"'
# 绕过探测(路径参数类)
curl -sk -o /dev/null -w "%{http_code}\n" \
"https://target/artifactory/api/security/users;jsessionid=x"
# 头注入类
curl -sk -H "X-Forwarded-For: 127.0.0.1" \
https://target/artifactory/api/system/configuration | head -c 200
ounter(counterh28. 落地到实网攻防环境的建议
红队视角：
- 别直接用这个 poc.py 打实网——UA 是特征、无限速、默认口令爆破会触发锁定。正确用法是抄它的绕过手法清单到 Burp Intruder，UA 随机化、2~5 秒间隔、只打管理端点。
- Artifactory 的管理 API 一旦拿下，第一动作不是改配置，是只读导出：
/api/security/users、/artifactory/api/repositories配置里的远程仓库凭据、/api/build里的构建环境变量——这些才是横向跳板。 - 检出即停，按授权范围上报；这个 CVE 的 CVSS 权重在于制品库沦陷的供应链后果，报告里要把这条链画出来。
蓝队视角：
- 立即自查三件事：admin 是否还是默认口令、管理端口是否对非管理网段开放、
X-JFrog-Override-Base-Url是否可从外部传入（反代层应 strip 全部X-*内部头）。 - 升级到厂商 advisory 列出的修复版本；短期缓解：反代层正则拦截
;与..;/路径、管理路径加 IP 白名单、开启审计日志外发。 - 把本仓库的
run-tests.sh思路搬进 CI：每次升级后跑一遍”检测脚本应对修复版判 NOT”，用回归证明缓解有效。
工程视角（为什么这个仓库值得读）：它展示了一套可复用的 PoC 工程范式——检测脚本（数据化绕过手法 + 证据打分）+ 漏洞靶场 + 修复靶场 + 回归脚本。同时它也展示了自动生成 PoC 的所有毛病：未使用的参数、端口配置三处不一致、模板文案张冠李戴（SQL/RCE 修复项）、SEO 堆砌。用它的骨架，别信它的细节，这是审计此类仓库的正确姿势。
ounter(counterh29. 附：下载物清理声明
审计过程克隆的仓库副本（/tmp/cve_audit_tmp）已在本报告定稿后删除，本机不留任何 GitHub 下载残留。
报告生成：2026-09-01 · 基于 commit 83ed278（main 分支唯一提交）
免责声明：
本文所载程序、技术方法仅面向合法合规的安全研究与教学场景，旨在提升网络安全防护能力，具有明确的技术研究属性。
任何单位或个人未经授权，将本文内容用于攻击、破坏等非法用途的，由此引发的全部法律责任、民事赔偿及连带责任，均由行为人独立承担，本站不承担任何连带责任。
本站内容均为技术交流与知识分享目的发布，若存在版权侵权或其他异议，请通过邮件联系处理，具体联系方式可点击页面上方的联系我。
本文转载自：网安之家-CyberHomestead 《CVE-2026-82329》
版权声明
本站仅做备份收录，仅供研究与教学参考之用。
读者将信息用于其他用途的，全部法律及连带责任由读者自行承担，本站不承担任何责任。
评论