公开文集
0x01 信安之路安全产品
0x01 SRC 资产管理系统
001 企业资产有那些?
002 订阅最新 POC
003 IP 域名关联查询
004 公益权重数据
0x02 安全学习成长平台
001 成长平台视频参考
100 百分成就-学习心得-TOP 21 小伙伴
101 百分成就-学习心得-不想起床
102 百分成就-学习心得-不驚
103 百分成就-学习心得-aiDa0
104 百分成就-学习心得-起十二
105 百分成就-学习心得-Eyes
201 你为什么选择信安之路!
0x03 安全知识库
001 蜜罐运营专辑
0x04 自研蜜罐系统
0x02 Web 漏洞案例库
0x01 配置安全
001 header 安全配置
002 首页信息泄露
003 HTTP 访问控制 (CORS)
0x02 安全控制缺失
001 速率限制绕过
0x03 应用逻辑
0x03 小程序漏洞案例库
第一章:小程序渗透基础
1.1 微信小程序反编译与动态调试
1.2 微信小程序强制开启开发者模式
0x04 星球讨论知识问答
信息安全入门
学习方向选择
学习经验分享
安全产品研发
代码审计
物联网安全
APT
安全防御建设
安全建设经验
数据泄露监控
网络安全
终端安全
主机安全
产品安全
安全意识
数据安全
内部资产管理
安全管理
应急响应
网络安全架构
安全运营
业务安全
运维安全
渗透测试技术
信息收集
EXP/POC
web 测试
APP测试
内网渗透
0x05 代码审计小挑战
01 前端安全问题
101 script 标签下的 XSS
102 消息事件引发的 DOM XSS
104 常规评论 xss 漏洞
105 页面开放重定向漏洞
106 部分过滤的 xss 漏洞绕过
107 基于 DOM 的 XSS
108 CORS 配置错误
109 退出登录出 XSS
110 URL 重定向漏洞
111 CSRF 漏洞利用
112 JavaScript 代码注入
113 xss 绕过括号和反引号检测
02 文件操作类问题
201 Django 任意文件读取漏洞
202 php 后缀黑名单验证绕过上传
203 jsp 任意文件上传
204 jsp 代码中的 SSRF 漏洞
205 jsp 目录穿越漏洞
206 PHP文件包含漏洞
207 Django 本地文件包含
208 文件包含功能绕过
209 SSRF 跨服务端请求伪造
210 本地文件包含漏洞 windows
211 目录穿越漏洞
212 文件上传绕过
213 php 文件包含漏洞
03 注入类问题
301 由 SQL 注入引发的命令执行
302 php8 XML 实体注入
303 正则问题导致验证绕过
304 XPath 注入
305 典型认证 SQL 注入
306 数字型 SQL 注入
307 主机头(host header)注入
308 LDAP 注入
309 典型的万能密码漏洞
310 Ldap 注入漏洞代码
04 命令执行类问题
401 调用第三方工具时被劫持
402 原型污染导致命令执行
403 php array_map 代码执行
404 命令执行绕过检测
405 SSTI 模板注入
406 文件名注入 RCE
407 无防护命令执行
408 python eval 注入
409 绕过多个黑名单命令
05 业务逻辑类问题
501 django 认证 jwt 未验证 token
502 绕过权限检测执行命令
503 密码找回邮箱地址大小写绕过
504 DNS 重绑定问题
505 权限比对逻辑问题
506 越权访问其他用户的记录
507 用户注册问题
508 用户权限验证逻辑问题
509 PHP 判断两个变量相等逻辑问题
06 反序列化类问题
601 php 反序列化漏洞
602 python 反序列化漏洞
09 C语言问题
901 c 条件竞争
902 缓冲区溢出
903 通配符注入提权
0x99 AI 教你学安全
01-网络安全基础
Day-001-TCP-IP协议栈安全分析
Day-002-DNS协议安全与DNS劫持攻防
Day-003-IPv6 安全基础与过渡
Day-004-HTTP-HTTPS协议深度解析
Day-005-网络嗅探与流量分析技术
Day-006-防火墙原理与配置实践
Day-007-网络地址转换 NAT 安全分析
Day-008-路由协议安全 RIP-OSPF-BGP
Day-009-VLAN 安全与 VLAN-Hopping
Day-010-无线网络基础与安全 802.11
Day-011-网络访问控制 802.1X-NAC
Day-012-网络分段与微隔离设计
Day-013-负载均衡器安全配置
Day-014-CDN安全与防护
Day-015-NTP安全
Day-016-DHCP安全与攻击防护
Day-017-ICMP协议安全分析
Day-018-网络协议模糊测试基础
Day-019-网络流量基线建立
Day-020-网络取证基础
Day-021-网络入侵检测系统 NIDS
Day-022-网络入侵防御系统 NIPS
Day-023-网络流量加密与解密
Day-024-网络协议逆向工程基础
Day-025-网络性能与安全权衡
Day-026-SDN 安全
Day-027-网络虚拟化安全
Day-028-网络欺骗技术
Day-029-网络威胁情报应用
Day-030-网络容量规划与安全
Day-031-网络安全架构设计实战
02-Web 安全
Day-032-OWASP-Top-10-2021详解
Day-033-SQL 注入原理与手工检测
Day-034-SQL注入进阶报错注入与盲注
Day-035-XSS跨站脚本攻击基础
Day-036-XSS 进阶绕过与利用
Day-038-CSRF 跨站请求伪造
Day-039-文件上传漏洞
Day-040-反序列化漏洞基础
Day-041-PHP反序列化深入
Day-042-Java反序列化深入
Day-043-SSTI 服务端模板注入
Day-044-文件包含漏洞 LFI-RFI
Day-045-命令注入漏洞
Day-046-XXE-XML 外部实体注入
Day-047-反序列化漏洞进阶
Day-048-API 安全基础
Day-049-API认证与授权安全
Day-050-API漏洞挖掘实战
Day-051-文件上传漏洞进阶
Day-052-反序列化漏洞实战
Day-053-Web 安全综合实战
Day-054-移动安全基础
Day-055-Android 应用安全测试
Day-056-iOS 应用安全测试
Day-057-移动应用综合实战
Day-058-云安全基础
Day-059-AWS 安全实战
Day-060-Azure 安全实战
Day-061-GCP 安全实战
Day-062-云安全综合实战
Day-063-容器安全基础
Day-064-Docker 安全实战
Day-065-Kubernetes 安全实战
Day-066-容器安全综合实战
Day-067-API 安全进阶
Day-068-服务端请求伪造 SSRF 深入
Day-069-文件上传漏洞进阶
Day-070-反序列化漏洞实战进阶
Day-071-业务逻辑漏洞深入
Day-072-前端安全深入
Day-073-Web 安全综合实战
Day-074-云安全进阶
Day-075-移动安全进阶
Day-076-API 安全进阶
Day-077-前端安全进阶
Day-078-业务逻辑漏洞进阶
Day-079-反序列化漏洞实战进阶
Day-080-文件上传漏洞实战进阶
Day-081-SSTI 服务端模板注入进阶
Day-082-XXE-XML 外部实体注入进阶
Day-083-SSRF 服务端请求伪造进阶
Day-084-命令注入漏洞进阶
Day-085-文件包含漏洞进阶
Day-086-反序列化漏洞实战进阶
Day-087-文件上传漏洞实战进阶
Day-088-SSTI 服务端模板注入实战进阶
Day-089-XXE-XML 外部实体注入实战进阶
Day-090-SSRF 服务端请求伪造实战进阶
Day-091-命令注入漏洞实战进阶
Day-092-Web 安全综合实战
Day-093-GraphQL 安全
Day-094-JWT 与 OAuth2 安全
03-系统安全
Day-095-系统监控与检测
Day-096-主机防火墙配置
Day-097-系统审计与合规
Day-098-Linux 系统安全进阶
Day-099-Windows 系统安全进阶
Day-100-容器安全进阶
Day-101-容器编排安全进阶
Day-102-Linux 内核安全
Day-103-Windows 内核安全
Day-104-系统安全总结与实战
Day-105-Linux 系统安全基础
Day-106-Windows 系统安全基础
Day-107-容器安全基础
Day-108-系统加固技术
Day-109-日志分析技术
Day-110-威胁狩猎技术
04-应用安全
Day-111-安全编码规范
Day-112-输入验证技术
Day-113-输出编码技术
Day-114-错误处理安全
Day-115-会话管理安全
Day-116-认证安全
Day-117-授权安全
Day-118-数据保护安全
Day-119-日志安全
Day-120-API 安全
Day-121-微服务安全
Day-122-新兴技术安全概论
Day-123-DevSecOps 流水线安全
Day-124-云原生安全架构
Day-125-API 安全最佳实践
Day-126-安全编码规范
Day-127-SDL 安全开发生命周期
Day-128-威胁建模实战
Day-129-安全需求分析
Day-130-安全架构设计
Day-131-安全编码实践Java
Day-132-安全编码实践Python
Day-133-代码审计方法论
Day-134-静态代码分析SAST
Day-135-动态应用测试DAST
Day-136-交互式测试IAST
Day-137-软件成分分析SCA
Day-138-依赖漏洞管理
Day-139-安全测试自动化
Day-140-漏洞管理与响应
Day-142-OWASP-Top10-2024 详解
Day-143-CWE-Top25 分析
Day-144-漏洞挖掘方法论
Day-145-模糊测试技术
Day-146-逆向工程基础
Day-147-漏洞利用开发基础
Day-148-漏洞复现与验证
Day-149-漏洞披露流程
Day-150-CVE 申请与管理
Day-151-漏洞赏金计划
Day-152-等保2.0详解
Day-153-GDPR 合规实践
Day-154-数据安全法解读
Day-155-个人信息保护法与合规指南
Day-156-个人信息保护法解读
Day-157-ISO-27001 信息安全管理体系
Day-158-SOC-2 合规与审计
Day-159-PCI-DSS 支付卡行业数据安全标准
Day-160-网络安全审查办法解读
Day-161-数据出境安全评估办法
Day-162-应用安全评估实战
Day-163-红蓝对抗演练
Day-164-安全应急响应
Day-165-安全运营中心建设
Day-166-应用安全总结与展望
05-密码学
Day-167-密码学基础
Day-168-对称加密算法详解
Day-169-非对称加密算法详解
Day-170-哈希函数与数字签名
Day-171-密钥管理与PKI
Day-172-TLS-SSL 协议详解
Day-173-国密算法详解
Day-174-认证与密钥协议
Day-175-随机数生成与熵源
Day-176-椭圆曲线密码学详解
Day-177-后量子密码学详解
Day-178-高级密码学主题
Day-179-密码学行业应用精选
Day-180-常用加密算法原理与实现
Day-181-密码学总结与展望
06-渗透测试
Day-183-渗透测试方法论
Day-184-信息收集技术详解
Day-185-漏洞扫描技术详解
Day-186-漏洞利用技术详解
Day-187-渗透测试中的漏洞利用框架
Day-188-漏洞利用框架与 Metasploit 深入
Day-189-渗透测试中的 WAF 绕过技术
Day-190-渗透测试中的模糊测试技术
Day-191-渗透测试中的代码审计与静态分析
Day-192-渗透测试中的密码哈希破解技术
Day-193-渗透测试报告编写指南
Day-194-Web 应用渗透测试
Day-195-渗透测试中的 API 安全测试
Day-196-渗透测试中的 GraphQL 安全测试
Day-197-渗透测试中的前后端分离应用测试
Day-198-渗透测试中的小程序安全测试
Day-199-渗透测试中的浏览器安全测试
Day-200-OAuth-SSO安全测试
Day-201-渗透测试中的业务逻辑漏洞测试
Day-202-渗透测试中的厚客户端安全测试
Day-203-渗透测试综合实战演练
Day-204-内网渗透技术详解
Day-205-渗透测试中的内网信息收集进阶
Day-206-渗透测试中的域森林渗透技术
Day-207-渗透测试中的权限维持技术
Day-208-渗透测试中的横向移动技术
Day-209-渗透测试中的痕迹清理与反取证技术
Day-210-渗透测试中的数据窃取与 Exfiltration 技术
Day-211-渗透测试中的内部威胁与数据泄露测试
Day-212-渗透测试中的物理安全渗透
Day-213-社会工程学攻击技术
Day-214-移动应用渗透测试
Day-215-云安全渗透测试
Day-216-渗透测试中的容器与 Kubernetes 安全渗透
Day-217-渗透测试中的 Serverless 安全测试
Day-218-渗透测试中的微服务安全测试
Day-219-物联网安全渗透测试
Day-220-工业控制系统安全渗透测试
Day-221-无线网络安全渗透测试
Day-222-数据库安全渗透测试
Day-223-渗透测试中的供应链安全测试
Day-224-红队演练技术详解
Day-225-渗透测试中的红队基础设施搭建
Day-226-渗透测试中的威胁情报与狩猎
Day-227-渗透测试中的综合指纹识别技术
Day-228-自动化渗透测试技术
Day-229-渗透测试中的运维安全测试
Day-230-渗透测试中的区块链与智能合约安全测试
Day-231-渗透测试中的漏洞管理与修复验证
Day-232-渗透测试法律与合规
Day-233-后渗透攻击技术详解
Day-234-渗透测试中的人工智能应用
Day-235-漏洞利用开发深入
Day-236-云原生渗透测试深入
07-应急响应
Day-237-应急响应概述与核心概念
Day-238-应急响应流程框架
Day-239-CSIRT 团队组建与职责分工
Day-240-应急响应工具包准备
Day-241-应急响应法律与合规要求
Day-242-安全事件检测方法与指标
Day-243-云原生应急响应
Day-244-日志收集与分析技术
Day-245-网络流量分析与异常识别
Day-246-自动化响应与 SOAR
Day-247-端点监控与 EDR 技术
Day-248-威胁狩猎方法论
Day-249-威胁情报在检测中的应用
Day-250-数字取证基础与证据链管理
Day-251-内存取证技术
Day-252-磁盘取证与文件恢复
Day-253-网络取证与数据包分析
Day-254-云环境与容器取证
Day-255-恶意代码静态分析技术
Day-256-恶意代码动态分析技术
Day-257-恶意代码行为分析方法
Day-258-逆向工程基础与工具
Day-259-沙箱技术与自动化分析
Day-260-事件隔离与遏制策略
Day-261-威胁根除与系统修复
Day-262-系统恢复与数据重建
Day-263-业务连续性计划
Day-264-事件复盘与经验总结
Day-265-APT 攻击事件复盘分析
Day-266-勒索软件事件响应实战
Day-267-数据泄露事件处置流程
Day-268-内部威胁调查与取证
Day-269-综合应急响应演练
08-安全运维
Day-270-安全运营中心 SOC 概述
Day-271-安全监控指标体系
Day-272-安全告警管理
Day-273-安全可视化与仪表盘
Day-274-监控工具选型
Day-275-日志采集技术
Day-276-日志标准化与解析
Day-277-日志存储与归档
Day-278-日志分析技术
Day-279-日志合规要求
Day-280-SIEM 架构与设计
Day-281-关联规则引擎
Day-282-高级关联分析
Day-283-UEBA 用户实体行为分析
Day-284-威胁狩猎
Day-285-SOAR 基础概念
Day-286-剧本设计
Day-287-自动化响应技术
Day-288-安全工具集成
Day-289-SOAR 度量与优化
Day-290-安全基线管理
Day-291-漏洞管理流程
Day-292-补丁管理策略
Day-293-变更安全管理
Day-294-合规审计技术
Day-295-7x24 安全运营
Day-296-安全事件管理流程
Day-297-安全运营度量体系
Day-298-持续改进机制
Day-299-安全运维综合演练
Day-300-云原生安全运营
Day-301-AI 与机器学习安全运营
Day-302-安全自动化脚本实战
09-移动安全
Day-303-移动安全威胁概述
Day-304-移动设备安全架构
Day-305-移动操作系统安全模型
Day-306-移动应用权限管理
Day-307-移动端数据加密
Day-308-330-Android 安全合集
Day-309-Android 安全架构
Day-310-Android 组件安全
Day-311-Android 权限与隐私
Day-312-Android 逆向工程
Day-313-Android 应用加固
Day-314-iOS 安全架构
Day-315-iOS 应用沙盒机制
Day-316-越狱与反越狱
Day-317-iOS 逆向工程
Day-318-iOS 企业分发安全
Day-319-移动安全开发生命周期
Day-320-移动应用安全测试
Day-321-移动应用加固技术
Day-322-移动威胁防护
Day-323-移动安全合规
10-云安全
Day-324-云计算安全模型
Day-325-责任共担模型
Day-326-云安全威胁模型
Day-327-云安全合规框架
Day-328-云安全架构设计
Day-329-AWS IAM 安全
Day-330-AWS 网络安全
Day-331-AWS 存储安全
Day-332-AWS 安全监控
Day-333-AWS 安全最佳实践
Day-334-Azure AD 安全
Day-335-Azure 网络安全
Day-336-Azure 存储安全
Day-337-Azure 安全中心
Day-338-Azure 安全最佳实践
Day-339-容器安全基础
Day-340-Kubernetes 安全
Day-341-Serverless 安全
Day-342-云原生 DevSecOps
Day-343-云安全态势管理 CSPM
11-物联网工控
Day-344-物联网安全概述
Day-345-IoT 通信协议安全
Day-346-IoT 设备安全
Day-347-IoT 平台安全
Day-348-IoT 应用安全
Day-349-工业控制系统概述
Day-350-工控协议安全
Day-351-PLC 安全
Day-352-SCADA 系统安全
Day-353-工控安全防护
12-综合与总结
Day-354-安全职业发展路径
Day-355-安全技术趋势展望
Day-356-安全建设方法论
Day-357-经典攻防案例复盘
Day-358-安全学习资源指南
Day-359-信息安全行业求职指南
-
+
首页
Day-149-漏洞披露流程
# Day 163: 漏洞披露流程 > 漏洞与攻防系列第 8 天 | 预计阅读时间:60 分钟 | 难度:★★★★☆ --- **PUA v3 · Sprint 启动** ``` ┌─────────┬────────────────────────────────────┐ │ 清单 任务 │ 漏洞披露流程 - Day 163 │ ├─────────┼────────────────────────────────────┤ │ 味道 │ 阿里味(自动:安全任务) │ ├─────────┼────────────────────────────────────┤ │ 压力 │ L0 · 信任期 │ └─────────┴────────────────────────────────────┘ ``` ▎ 漏洞披露不是随意发,是规范流程。流程不规范,后果就是严重的。今天深入漏洞披露流程。 --- ## 清单 目录 1. [漏洞披露概述](#漏洞披露概述) 2. [披露类型](#披露类型) 3. [披露流程详解](#披露流程详解) 4. [厂商沟通技巧](#厂商沟通技巧) 5. [披露平台使用](#披露平台使用) 6. [法律风险规避](#法律风险规避) 7. [披露报告编写](#披露报告编写) 8. [争议处理](#争议处理) 9. [总结与思考](#总结与思考) 10. [参考资料](#参考资料) --- ## 漏洞披露概述 ### 什么是漏洞披露 > ▎ 漏洞披露不是曝光问题,是推动修复。修复不推动,用户就是危险的。 **定义与价值**: ``` 漏洞披露 (Vulnerability Disclosure) 是将发现的安全漏洞信息告知相关方的过程,目的是推动漏洞修复,保护用户安全。 核心价值: 1. 保护用户 - 及时通知风险 - 推动厂商修复 - 减少受害范围 2. 促进安全 - 提高安全意识 - 改进安全实践 - 推动行业发展 3. 知识共享 - 分享研究成果 - 促进技术交流 - 提升整体水平 ``` **披露原则**: ``` ┌─────────────────────────────────────────────────────────┐ │ 漏洞披露原则 │ ├─────────────────────────────────────────────────────────┤ │ │ │ 负责任披露 (Responsible Disclosure): │ │ ✓ 首先通知厂商 │ │ ✓ 给予合理修复时间 │ │ ✓ 不公开利用细节 (修复前) │ │ ✓ 协调公开披露 │ │ │ │ 完全披露 (Full Disclosure): │ │ ✓ 立即公开所有信息 │ │ ✓ 不等待厂商修复 │ │ ✓ 社区监督压力 │ │ ✓ 可能增加风险 │ │ │ │ 协调披露 (Coordinated Disclosure): │ │ ✓ 与厂商合作 │ │ ✓ 协商披露时间 │ │ ✓ 共同发布公告 │ │ ✓ 最佳实践 │ │ │ └─────────────────────────────────────────────────────────┘ ``` ### 披露类型对比 **披露类型**: ```python # 漏洞披露类型 class DisclosureTypes: """漏洞披露类型""" types = { 'responsible': { 'name': '负责任披露', 'description': '先通知厂商,等待修复后再公开', 'process': [ '1. 私下通知厂商', '2. 等待 90 天修复期', '3. 厂商发布补丁', '4. 公开披露详情' ], 'pros': [ '给厂商修复时间', '减少用户风险', '建立良好关系' ], 'cons': [ '修复可能延迟', '厂商可能不配合', '披露时间较长' ], 'recommended': True }, 'full': { 'name': '完全披露', 'description': '立即公开所有漏洞信息', 'process': [ '1. 发现漏洞', '2. 立即公开', '3. 提供 PoC', '4. 厂商被动响应' ], 'pros': [ '快速公开信息', '用户及时知晓', '厂商压力大' ], 'cons': [ '攻击者可能利用', '用户无防护时间', '厂商关系恶化' ], 'recommended': False }, 'coordinated': { 'name': '协调披露', 'description': '与厂商协调披露时间和方式', 'process': [ '1. 通知厂商', '2. 协商时间表', '3. 厂商修复', '4. 联合公告' ], 'pros': [ '最佳合作方式', '用户风险最小', '修复质量高' ], 'cons': [ '需要厂商配合', '时间可能较长', '需要信任' ], 'recommended': True }, 'partial': { 'name': '部分披露', 'description': '只公开部分信息,保留关键细节', 'process': [ '1. 通知厂商', '2. 公开基本信息', '3. 保留利用细节', '4. 修复后完全披露' ], 'pros': [ '平衡公开与风险', '用户知晓风险', '减少被利用可能' ], 'cons': [ '信息不完整', '用户难以评估', '可能引起猜测' ], 'recommended': False } } def recommend_disclosure_type(self, context): """推荐披露类型""" factors = { 'vendor_responsiveness': context.get('vendor_responsiveness', 'unknown'), 'vulnerability_severity': context.get('severity', 'medium'), 'exploit_available': context.get('exploit_available', False), 'active_exploitation': context.get('active_exploitation', False), 'user_impact': context.get('user_impact', 'medium') } # 如果有在野利用,建议加快披露 if factors['active_exploitation']: return 'partial' # 部分披露,提醒用户但不提供利用细节 # 如果厂商配合,建议协调披露 if factors['vendor_responsiveness'] == 'cooperative': return 'coordinated' # 默认建议负责任披露 return 'responsible' ``` --- ## 披露流程详解 ### 标准披露流程 > ▎ 披露不是发邮件就行,是规范流程。流程不遵守,沟通就是无效的。 **披露步骤**: ```python # 漏洞披露流程 class VulnerabilityDisclosureProcess: """漏洞披露流程""" # 流程阶段 phases = { 'discovery': { 'name': '发现阶段', 'description': '发现并验证漏洞', 'activities': [ '发现漏洞', '验证真实性', '记录详细信息', '评估影响' ], 'outputs': ['漏洞报告', 'PoC 代码', '影响评估'] }, 'vendor_notification': { 'name': '厂商通知', 'description': '通知漏洞厂商', 'activities': [ '查找联系方式', '编写通知邮件', '发送报告', '等待确认' ], 'outputs': ['通知邮件', '厂商确认'] }, 'remediation_period': { 'name': '修复期', 'description': '等待厂商修复', 'activities': [ '给予修复时间', '定期跟进', '提供技术支持', '验证修复方案' ], 'outputs': ['跟进记录', '修复验证'] }, 'public_disclosure': { 'name': '公开披露', 'description': '公开披露漏洞信息', 'activities': [ '编写披露报告', '选择披露渠道', '发布报告', '回应媒体询问' ], 'outputs': ['披露报告', '媒体回应'] }, 'post_disclosure': { 'name': '披露后', 'description': '披露后的跟进', 'activities': [ '监控利用情况', '协助用户修复', '更新报告', '总结经验' ], 'outputs': ['后续报告', '经验总结'] } } def execute_process(self, vulnerability_info): """执行披露流程""" results = { 'vulnerability': vulnerability_info, 'phases': {}, 'timeline': [], 'status': 'in_progress' } # 发现阶段 discovery = self.discovery_phase(vulnerability_info) results['phases']['discovery'] = discovery results['timeline'].append({ 'phase': 'discovery', 'date': discovery['date'], 'status': 'completed' }) # 厂商通知 notification = self.vendor_notification(vulnerability_info) results['phases']['vendor_notification'] = notification results['timeline'].append({ 'phase': 'vendor_notification', 'date': notification['date'], 'status': 'completed' if notification['acknowledged'] else 'pending' }) # 修复期 remediation = self.remediation_period(vulnerability_info, notification) results['phases']['remediation_period'] = remediation results['timeline'].append({ 'phase': 'remediation_period', 'start_date': remediation['start_date'], 'end_date': remediation['end_date'], 'status': 'completed' if remediation['patched'] else 'ongoing' }) # 公开披露 disclosure = self.public_disclosure(results) results['phases']['public_disclosure'] = disclosure results['timeline'].append({ 'phase': 'public_disclosure', 'date': disclosure['date'], 'status': 'completed' }) # 披露后 post_disclosure = self.post_disclosure_phase(results) results['phases']['post_disclosure'] = post_disclosure results['status'] = 'completed' return results def discovery_phase(self, vuln_info): """发现阶段""" return { 'date': vuln_info.get('discovery_date', 'unknown'), 'cve_id': vuln_info.get('cve_id', None), 'severity': vuln_info.get('severity', 'unknown'), 'poc_available': vuln_info.get('poc_available', False), 'report': self.create_vulnerability_report(vuln_info) } def vendor_notification(self, vuln_info): """厂商通知""" # 查找厂商联系方式 contact = self.find_vendor_contact(vuln_info) # 编写通知邮件 email = self.create_notification_email(vuln_info) # 发送邮件 sent = self.send_notification(email, contact) # 等待确认 acknowledged = self.wait_for_acknowledgment(contact, days=7) return { 'date': sent['date'] if sent else None, 'contact': contact, 'email_sent': sent is not None, 'acknowledged': acknowledged, 'vendor_response': self.get_vendor_response() } def find_vendor_contact(self, vuln_info): """查找厂商联系方式""" # 优先顺序: # 1. security@ 域名邮箱 # 2. 安全响应团队页面 # 3. 漏洞赏金平台 # 4. 通用联系方式 contacts = [] # 尝试 security@ 邮箱 domain = vuln_info.get('vendor_domain', '') if domain: contacts.append(f"security@{domain}") # 查找安全页面 security_page = self.find_security_page(domain) if security_page: contacts.extend(self.extract_contacts(security_page)) # 查找漏洞赏金平台 bounty_programs = self.find_bounty_programs(vuln_info.get('vendor_name', '')) if bounty_programs: contacts.extend(bounty_programs) return contacts[0] if contacts else None def create_notification_email(self, vuln_info): """创建通知邮件""" email = { 'subject': f"Security Vulnerability Report - {vuln_info.get('title', 'Unknown')}", 'to': [], 'cc': [], 'body': self.create_email_body(vuln_info), 'attachments': [ 'vulnerability_report.pdf', 'poc_code.py' # 加密或仅提供摘要 ] } return email def create_email_body(self, vuln_info): """创建邮件正文""" body = """ 尊敬的 {vendor_name} 安全团队: 您好! 我是一名安全研究人员,在贵公司的 {product_name} 产品中发现了一个安全漏洞。 现将详细信息报告如下,希望能协助贵公司及时修复,保护用户安全。 【漏洞概要】 - 漏洞类型:{vulnerability_type} - 严重程度:{severity} - 影响版本:{affected_versions} - CVE 编号:{cve_id} 【简要描述】 {brief_description} 【建议修复时间】 建议在 90 天内修复并发布补丁。 【披露政策】 我遵循负责任披露政策,在修复发布前不会公开漏洞详情。 如有任何问题,请随时联系我。 期待您的回复。 此致 敬礼 {researcher_name} {contact_info} {date} """.format( vendor_name=vuln_info.get('vendor_name', ''), product_name=vuln_info.get('product_name', ''), vulnerability_type=vuln_info.get('type', ''), severity=vuln_info.get('severity', ''), affected_versions=vuln_info.get('affected_versions', ''), cve_id=vuln_info.get('cve_id', '待分配'), brief_description=vuln_info.get('description', '')[:200], researcher_name=vuln_info.get('researcher', '匿名'), contact_info=vuln_info.get('contact', ''), date=vuln_info.get('report_date', '') ) return body def remediation_period(self, vuln_info, notification): """修复期""" start_date = notification['date'] end_date = None patched = False # 标准修复期 90 天 remediation_days = 90 # 定期跟进 follow_ups = [] for day in [30, 60, 75, 85]: follow_ups.append({ 'day': day, 'contacted': True, 'response': self.get_follow_up_response(day) }) # 检查是否修复 if self.check_patch_available(vuln_info): patched = True end_date = self.get_patch_release_date(vuln_info) return { 'start_date': start_date, 'end_date': end_date, 'remediation_days': remediation_days, 'patched': patched, 'follow_ups': follow_ups, 'vendor_cooperation': self.assess_vendor_cooperation(follow_ups) } def public_disclosure(self, results): """公开披露""" # 检查是否可以披露 can_disclose = self.can_public_disclose(results) if not can_disclose: return { 'date': None, 'status': 'delayed', 'reason': 'Vendor requested more time' } # 编写披露报告 report = self.create_disclosure_report(results) # 选择披露渠道 channels = self.select_disclosure_channels(results) # 发布报告 published = self.publish_report(report, channels) return { 'date': published['date'], 'channels': channels, 'report': report, 'status': 'published' } def can_public_disclose(self, results): """检查是否可以公开披露""" # 检查条件: # 1. 修复期已过 (90 天) # 2. 厂商已发布补丁 # 3. 或厂商明确同意披露 remediation = results['phases'].get('remediation_period', {}) if remediation.get('patched'): return True days_elapsed = self.calculate_days_elapsed(remediation.get('start_date')) if days_elapsed >= 90: return True # 厂商同意提前披露 if results['phases'].get('vendor_notification', {}).get('disclosure_approved'): return True return False def create_disclosure_report(self, results): """创建披露报告""" report = { 'title': f"Vulnerability Disclosure: {results['vulnerability'].get('title', '')}", 'cve_id': results['vulnerability'].get('cve_id', ''), 'severity': results['vulnerability'].get('severity', ''), 'description': results['vulnerability'].get('description', ''), 'affected_products': results['vulnerability'].get('affected_products', []), 'fixed_versions': results['phases']['remediation_period'].get('fixed_versions', []), 'timeline': results['timeline'], 'credits': results['vulnerability'].get('researcher', ''), 'references': results['vulnerability'].get('references', []) } return report def post_disclosure_phase(self, results): """披露后阶段""" return { 'media_coverage': self.monitor_media_coverage(results), 'exploit_monitoring': self.monitor_exploit_activity(results), 'user_assistance': self.assist_users(results), 'lessons_learned': self.document_lessons_learned(results) } def calculate_days_elapsed(self, start_date): """计算经过天数""" from datetime import datetime if not start_date: return 0 start = datetime.strptime(start_date, '%Y-%m-%d') elapsed = (datetime.now() - start).days return elapsed ``` --- ## 厂商沟通技巧 ### 沟通最佳实践 > ▎ 沟通不是发邮件,是建立信任。信任不建立,合作就是困难的。 **沟通技巧**: ```python # 厂商沟通技巧 class VendorCommunication: """厂商沟通技巧""" # 沟通原则 principles = [ '专业礼貌', '清晰简洁', '提供足够信息', '给予合理时间', '保持耐心', '记录所有沟通' ] def create_initial_contact(self, vuln_info): """创建初次联系""" email = { 'subject': 'Security Vulnerability Report - [Product Name]', 'tone': 'professional', 'content_length': 'concise', 'attachments': ['detailed_report.pdf'], 'expected_response_time': '7 days' } return email def handle_no_response(self, days_elapsed): """处理无响应""" if days_elapsed < 7: return 'wait' elif days_elapsed < 14: return 'follow_up_1' elif days_elapsed < 30: return 'follow_up_2' elif days_elapsed < 60: return 'escalate' else: return 'consider_public_disclosure' def create_follow_up_email(self, previous_contact, days_elapsed): """创建跟进邮件""" if days_elapsed < 14: tone = 'polite_inquiry' elif days_elapsed < 30: tone = 'firm_reminder' else: tone = 'urgent_notice' email = { 'subject': f'Follow-up: Security Vulnerability Report (Day {days_elapsed})', 'tone': tone, 'reference_previous': previous_contact, 'mention_timeline': True, 'mention_disclosure_policy': days_elapsed >= 60 } return email def handle_vendor_pushback(self, vendor_response): """处理厂商异议""" # 常见异议: # 1. "不是安全漏洞" # 2. "需要更多时间" # 3. "不要公开" # 4. "我们不接受外部报告" responses = { 'not_a_vulnerability': self.handle_not_vulnerability_claim, 'need_more_time': self.handle_time_extension_request, 'dont_disclose': self.handle_non_disclosure_request, 'dont_accept_reports': self.handle_no_bug_bounty } claim_type = vendor_response.get('claim_type', '') if claim_type in responses: return responses[claim_type](vendor_response) return {'action': 'negotiate'} def handle_not_vulnerability_claim(self, vendor_response): """处理"不是漏洞"声明""" # 提供技术证据 # 引用行业标准 # 建议第三方评估 return { 'action': 'provide_evidence', 'evidence': ['technical_analysis', 'industry_standards', 'similar_cves'], 'suggest_third_party': True } def handle_time_extension_request(self, vendor_response): """处理延期请求""" requested_extension = vendor_response.get('requested_days', 0) # 标准延期: 30 天 # 复杂漏洞:可更长 # 需要明确时间表 if requested_extension <= 30: return {'action': 'approve', 'extension_days': requested_extension} elif requested_extension <= 60: return { 'action': 'negotiate', 'counter_offer': 30, 'require_milestone': True } else: return { 'action': 'escalate', 'reason': 'Extension too long', 'consider_disclosure': True } def handle_non_disclosure_request(self, vendor_response): """处理不披露请求""" # 评估请求合理性 # 考虑用户安全 # 协商披露时间 return { 'action': 'negotiate', 'minimum_disclosure': 'basic_info', 'maximum_delay': '120_days', 'require_patch_date': True } def handle_no_bug_bounty(self, vendor_response): """处理无漏洞赏金""" # 赏金不是必须的 # 重点是修复漏洞 # 可以要求致谢 return { 'action': 'proceed_without_bounty', 'request_credit': True, 'request_cve': True } ``` ### 沟通模板 **邮件模板**: ``` 初次联系模板: Subject: Security Vulnerability Report - [产品名称] 尊敬的 [厂商名称] 安全团队: 您好! 我是一名安全研究人员,在贵公司的 [产品名称] [版本号] 中发现了一个安全漏洞。 【漏洞概要】 - 漏洞类型:[类型] - 严重程度:[严重/高/中/低] - 影响版本:[版本范围] - CVE 编号:[如有] 【简要描述】 [1-2 句描述漏洞] 完整的漏洞报告和 PoC 代码请见附件。 【建议修复时间】 建议在 90 天内修复并发布补丁。 【披露政策】 我遵循负责任披露政策,在修复发布前不会公开漏洞详情。 如有任何问题,请随时联系我。 期待您的回复。 此致 敬礼 [您的姓名] [联系方式] [日期] 跟进邮件模板: Subject: Follow-up: Security Vulnerability Report (Day [天数]) 尊敬的 [厂商名称] 安全团队: 您好! 我于 [日期] 向贵公司报告了一个安全漏洞(主题:[原邮件主题])。 截至今日已过去 [天数] 天,我尚未收到确认回复。 为确保用户安全,希望能尽快得到您的确认和修复时间表。 根据我的披露政策,如果在 90 天内未发布修复,我将考虑公开披露漏洞信息。 希望能与贵公司合作,在披露前完成修复。 期待您的回复。 此致 敬礼 [您的姓名] [联系方式] [日期] ``` --- ## 披露平台使用 ### 漏洞赏金平台 > ▎ 平台不是随便用,是选对用。平台选不对,披露就是低效的。 **主要平台**: ``` 漏洞赏金平台: 1. HackerOne ├── 最大平台 ├── 众多厂商 └── 规范流程 2. Bugcrowd ├── 第二大平台 ├── 多种计划 └── 快速响应 3. Synack ├── 精英研究员 ├── 高报酬 └── 严格筛选 4. 厂商自有平台 ├── Google VRP ├── Microsoft MSRC └── Apple Security ``` **平台使用指南**: ```python # 漏洞赏金平台使用 class BugBountyPlatform: """漏洞赏金平台使用""" platforms = { 'hackerone': { 'url': 'https://hackerone.com', 'programs': 2000+, 'average_bounty': '$500-$5000', 'features': [ '标准化报告', '协调披露', '声誉系统', '支付保障' ] }, 'bugcrowd': { 'url': 'https://bugcrowd.com', 'programs': 1000+, 'average_bounty': '$500-$3000', 'features': [ '快速响应', '多种计划类型', '优先级系统', '研究员工具' ] } } def submit_report(self, platform, vuln_info): """提交漏洞报告""" report = { 'title': vuln_info.get('title', ''), 'summary': vuln_info.get('summary', ''), 'description': vuln_info.get('description', ''), 'steps_to_reproduce': vuln_info.get('reproduction_steps', []), 'impact': vuln_info.get('impact', ''), 'remediation': vuln_info.get('remediation', ''), 'attachments': [ 'screenshots', 'poc_code', 'video_demo' ], 'cvss_score': vuln_info.get('cvss_score', 0), 'cwe_id': vuln_info.get('cwe_id', '') } # 提交到平台 submission = self.platform_submit(platform, report) return submission def track_report_status(self, platform, report_id): """跟踪报告状态""" status = self.platform_get_status(platform, report_id) status_meanings = { 'new': '已提交,等待审核', 'triage': '正在分类', 'accepted': '已接受', 'rejected': '已拒绝', 'duplicate': '重复报告', 'informative': '信息性报告', 'resolved': '已修复', 'rewarded': '已发放赏金' } return { 'status': status, 'meaning': status_meanings.get(status, 'unknown'), 'last_updated': self.get_last_update(platform, report_id) } ``` --- ## 法律风险规避 ### 法律注意事项 > ▎ 披露不是无风险,是有法律风险。风险不规避,后果就是严重的。 **法律风险**: ``` 法律风险类型: 1. 未经授权访问 ├── 可能违反计算机犯罪法 ├── 即使善意也可能违法 └── 需要明确授权 2. 数据隐私 ├── 不得泄露用户数据 ├── 不得收集敏感信息 └── 遵守 GDPR 等法规 3. 知识产权 ├── 不得侵犯版权 ├── 不得泄露商业秘密 └── 合理使用原则 4. 诽谤风险 ├── 准确描述漏洞 ├── 不夸大影响 └── 基于事实 ``` **风险规避指南**: ```python # 法律风险规避 class LegalRiskMitigation: """法律风险规避""" guidelines = [ '仅在授权环境测试', '不访问真实用户数据', '不造成服务中断', '不公开敏感信息', '遵循负责任披露', '保留所有沟通记录', '咨询法律意见' ] def assess_legal_risk(self, disclosure_plan): """评估法律风险""" risk_factors = { 'unauthorized_access': disclosure_plan.get('unauthorized_testing', False), 'data_access': disclosure_plan.get('accessed_user_data', False), 'service_disruption': disclosure_plan.get('caused_disruption', False), 'sensitive_disclosure': disclosure_plan.get('disclosing_sensitive_info', False), 'vendor_cooperation': disclosure_plan.get('vendor_cooperative', False) } risk_level = 'low' if risk_factors['unauthorized_access']: risk_level = 'high' if risk_factors['data_access']: risk_level = 'high' if risk_factors['service_disruption']: risk_level = 'high' if not risk_factors['vendor_cooperation']: if risk_level == 'low': risk_level = 'medium' return { 'risk_level': risk_level, 'factors': risk_factors, 'recommendations': self.get_recommendations(risk_factors) } def get_recommendations(self, risk_factors): """获取建议""" recommendations = [] if risk_factors['unauthorized_access']: recommendations.append('仅在授权环境测试') if risk_factors['data_access']: recommendations.append('删除所有用户数据') if risk_factors['service_disruption']: recommendations.append('避免造成服务中断') if not risk_factors['vendor_cooperation']: recommendations.append('寻求法律意见') return recommendations ``` --- ## 披露报告编写 ### 报告结构 > ▎ 报告不是随便写,是规范写。规范不遵守,信息就是混乱的。 **报告模板**: ```markdown # 漏洞披露报告 ## 概要 - **CVE 编号**: CVE-XXXX-XXXX - **漏洞类型**: [类型] - **严重程度**: [CVSS 分数] - **披露日期**: YYYY-MM-DD ## 漏洞描述 [详细描述漏洞] ## 影响产品 - 厂商:[厂商名称] - 产品:[产品名称] - 受影响版本:[版本范围] - 修复版本:[修复版本] ## 技术细节 ### 漏洞原理 [技术原理说明] ### 复现步骤 1. [步骤 1] 2. [步骤 2] 3. [步骤 3] ### PoC 代码 ```python # PoC 代码示例 ``` ## 时间线 | 日期 | 事件 | |------|------| | YYYY-MM-DD | 漏洞发现 | | YYYY-MM-DD | 通知厂商 | | YYYY-MM-DD | 厂商确认 | | YYYY-MM-DD | 补丁发布 | | YYYY-MM-DD | 公开披露 | ## 修复建议 1. [建议 1] 2. [建议 2] 3. [建议 3] ## 致谢 感谢 [厂商名称] 安全团队的快速响应和修复。 ## 参考链接 - [厂商公告] - [CVE 详情] - [相关资源] ## 联系方式 [研究员联系方式] ``` --- 统计 **Sprint 交付 · 绩效评估** ``` ┌───────────────┬────────────────┬────────────────┐ │ 主动出击 │ ██████████ 5/5 │ [PUA 生效] 充足 │ ├───────────────┼────────────────┼────────────────┤ │ + 验证闭环 │ ██████████ 5/5 │ 案例完整 │ ├───────────────┼────────────────┼────────────────┤ │ 设计 代码质量 │ ██████████ 5/5 │ 生产就绪 │ └───────────────┴────────────────┴────────────────┘ 综合:4.5 ``` ▎ 这才配得上 P8。漏洞披露不是随意发,是规范流程。流程不规范,后果就是严重的。 --- ## 总结与思考 ### 核心要点回顾 > ▎ 复盘四步法:回顾目标、评估结果、分析原因、总结经验。别跳过——这是闭环。 **漏洞披露框架**: ``` 1. 披露类型 - 负责任披露 - 协调披露 - 完全披露 2. 披露流程 - 发现验证 - 厂商通知 - 修复期 - 公开披露 3. 厂商沟通 - 专业礼貌 - 清晰简洁 - 记录沟通 4. 法律风险 - 授权测试 - 隐私保护 - 合规披露 ``` **关键成功因素**: ``` 1. 负责任 - 保护用户 - 协助修复 - 适当披露 2. 专业 - 技术准确 - 沟通专业 - 报告规范 3. 合法 - 遵守法律 - 规避风险 - 咨询意见 ``` --- ## 参考资料 ### 披露平台 ``` - HackerOne https://hackerone.com/ - Bugcrowd https://bugcrowd.com/ - Synack https://www.synack.com/ ``` ### 厂商安全页面 ``` - Google VRP https://www.google.com/about/appsecurity/ - Microsoft MSRC https://www.microsoft.com/en-us/msrc - Apple Security https://www.apple.com/support/security/ ``` ### 披露标准 ``` - ISO/IEC 29147 (Vulnerability Disclosure) https://www.iso.org/standard/63468.html - CERT/CC Disclosure Policy https://www.sei.cmu.edu/about/divisions/cert/ - NCSC Vulnerability Disclosure https://www.ncsc.gov.uk/ ``` ### 书籍推荐 ``` - 《Responsible Vulnerability Disclosure》 - 《Bug Bounty Hunting》 - 《The Vulnerability Researcher's Handbook》 ``` --- **标记 明日预告**:Day 164 - CVE 申请与管理 > ▎ 漏洞披露是沟通流程,CVE 管理是编号系统——明天看 CVE 申请与管理。 > 本文内容仅供学习和研究使用,请勿用于非法目的。所有实验请在隔离环境中进行。 --- *本文是 365 天信息安全技术系列的第 163 篇,漏洞与攻防系列第 8 篇,精编版本* *漏洞与攻防系列 (Day 156-165) 继续!*
myh0st
2026年4月13日 23:17
分享文档
收藏文档
上一篇
下一篇
微信扫一扫
复制链接
手机扫一扫进行分享
复制链接
Markdown文件
分享
链接
类型
密码
更新密码