misonl 漏洞扫描与分析
像攻击者一样思考，像专家一样防守。保持对 2025 威胁态势的感知。
运行时脚本
用于自动化验证：
| 脚本 | 用途 | 用法 |
|---|---|---|
scripts/security_scan.py |
验证安全原则是否已落地 | python scripts/security_scan.py <project_path> |
参考文件
| 文件 | 用途 |
|---|---|
| checklists.md | OWASP Top 10、认证、API、数据保护检查清单 |
1. 安全专家思维
核心原则
| 原则 | 应用 |
|---|---|
| Assume Breach（假设已失陷） | 按“攻击者已在内网”来设计 |
| Zero Trust（零信任） | 永不默认信任，始终验证 |
| Defense in Depth（纵深防御） | 多层防护，避免单点失败 |
| Least Privilege（最小权限） | 仅授予必要访问权限 |
| Fail Secure（安全失败） | 出错时默认拒绝访问 |
威胁建模问题
开始扫描前先问：
- 我们要保护什么？（Assets 资产）
- 谁会攻击我们？（Threat Actors 威胁主体）
- 他们会如何攻击？（Attack Vectors 攻击向量）
- 影响是什么？（Business Risk 业务风险）
2. OWASP Top 10:2025
风险类别
| 编号 | 类别 | 关注点 |
|---|---|---|
| A01 | 访问控制失效（Broken Access Control） | 谁能访问什么？IDOR、SSRF |
| A02 | 安全配置错误（Security Misconfiguration） | 默认配置、Header（响应头）、暴露服务 |
| A03 | 软件供应链安全 🆕（Software Supply Chain） | 依赖、CI/CD、构建完整性 |
| A04 | 密码学失效（Cryptographic Failures） | 弱加密、密钥暴露 |
| A05 | 注入（Injection） | 用户输入是否可进入系统命令 |
| A06 | 不安全设计（Insecure Design） | 架构层缺陷 |
| A07 | 认证失效（Authentication Failures） | 会话与凭据管理 |
| A08 | 完整性失效（Integrity Failures） | 未签名更新、数据篡改 |
| A09 | 日志与告警缺失（Logging & Alerting） | 监控盲区、缺少告警 |
| A10 | 异常条件处理失效 🆕（Exceptional Conditions） | 错误处理、Fail-open（失效即放行）状态 |
2025 关键变化
2021 -> 2025 变化：
+-- SSRF 并入 A01（访问控制）
+-- A02 权重提升（云/容器配置）
+-- A03 新增：供应链（重点）
+-- A10 新增：异常条件
+-- 重心迁移：根因优先于症状
3. 供应链安全（A03）
攻击面
| 向量 | 风险 | 需要确认的问题 |
|---|---|---|
| 依赖（Dependencies） | 恶意包投毒 | 新依赖是否审计？ |
| 锁文件（Lock files） | 完整性攻击 | 是否已提交并受保护？ |
| 构建流水线（Build pipeline） | CI/CD 被入侵 | 谁有修改权限？ |
| 包仓库（Registry） | Typosquatting | 来源是否可信可验证？ |
防御原则
- 校验包完整性（checksum）
- 锁定版本并审计升级
- 关键依赖使用私有仓库
- 对构建产物签名并校验
4. 攻击面建模
需要建模的对象
| 类别 | 内容 |
|---|---|
| 入口点（Entry Points） | API、表单、文件上传 |
| 数据流（Data Flows） | 输入 -> 处理 -> 输出 |
| 信任边界（Trust Boundaries） | 鉴权/授权校验位置 |
| 资产（Assets） | 密钥、PII、业务数据 |
优先级矩阵
风险 = 可能性 × 影响
高影响 + 高可能性 -> CRITICAL（严重）
高影响 + 低可能性 -> HIGH（高）
低影响 + 高可能性 -> MEDIUM（中）
低影响 + 低可能性 -> LOW（低）
5. 风险优先级排序
CVSS + 业务上下文
| 因素 | 权重 | 问题 |
|---|---|---|
| CVSS Score（评分） | 基础严重度 | 漏洞本身多严重？ |
| EPSS Score（利用概率） | 被利用概率 | 是否正在被利用？ |
| Asset Value（资产价值） | 业务权重 | 风险资产价值多高？ |
| Exposure（暴露面） | 暴露面 | 是否公网可达？ |
优先级决策树
是否正在被利用（EPSS > 0.5）？
+-- 是 -> CRITICAL：立即处理
+-- 否 -> 检查 CVSS
+-- CVSS ≥ 9.0 -> HIGH
+-- CVSS 7.0-8.9 -> 结合资产价值评估
+-- CVSS < 7.0 -> 排期处理
6. 异常条件处理（A10 - New）
Fail-Open 与 Fail-Closed
| 场景 | Fail-Open（不安全） | Fail-Closed（安全） |
|---|---|---|
| 鉴权异常 | 允许访问 | 拒绝访问 |
| 解析失败 | 继续接受输入 | 拒绝输入 |
| 超时处理 | 无限重试 | 限次后中止 |
重点检查项
- 全量捕获并吞掉异常的处理器
- 安全关键操作缺失错误处理
- 鉴权/授权中的竞态条件（Race Condition）
- 资源耗尽场景
7. 扫描方法论
分阶段方法
1. RECONNAISSANCE（侦察）
+-- 理解目标系统
+-- 技术栈
+-- 入口点
+-- 数据流
2. DISCOVERY（发现）
+-- 识别潜在问题
+-- 配置审查
+-- 依赖分析
+-- 代码模式检索
3. ANALYSIS（分析）
+-- 验证与优先级排序
+-- 排除误报
+-- 风险评分
+-- 攻击链映射
4. REPORTING（报告）
+-- 输出可执行结论
+-- 清晰复现步骤
+-- 业务影响
+-- 修复建议
8. 代码模式分析
高风险模式
| 模式 | 风险 | 关注点 |
|---|---|---|
| 查询拼接字符串 | 注入风险（Injection） | "SELECT * FROM " + user_input |
| 动态执行代码 | RCE | eval(), exec(), Function() |
| 不安全反序列化 | RCE | pickle.loads(), unserialize() |
| 路径拼接可控 | 路径穿越（Traversal） | 用户输入参与文件路径 |
| 关闭安全校验 | 多类风险 | verify=False, --insecure |
密钥泄露模式
| 类型 | 指标 |
|---|---|
| API Keys（密钥） | api_key、apikey、高熵字符串 |
| Tokens（令牌） | token、bearer、jwt |
| Credentials（凭据） | password、secret、key |
| Cloud（云平台） | AWS_、AZURE_、GCP_ 前缀 |
9. 云安全考量
责任共担模型
| 层级 | 你负责 | 云厂商负责 |
|---|---|---|
| 数据（Data） | [OK] | [FAIL] |
| 应用（Application） | [OK] | [FAIL] |
| 系统/运行时（OS/Runtime） | 视情况而定 | 视情况而定 |
| 基础设施（Infrastructure） | [FAIL] | [OK] |
云侧专项检查
- IAM：是否落实最小权限？
- 存储：是否存在公开桶？
- 网络：安全组是否收敛？
- 密钥：是否使用 secrets manager（密钥管理服务）？
10. 反模式
| [FAIL] 禁止（Don't） | [OK] 推荐（Do） |
|---|---|
| 不理解系统就开始扫描 | 先做攻击面建模 |
| 对每个 CVE 都同级告警 | 按可利用性 + 资产价值排序 |
| 忽略误报管理 | 维护经验证的基线 |
| 只修症状不修根因 | 追到根因并修复 |
| 仅在上线前扫描一次 | 持续扫描 |
| 盲目信任第三方依赖 | 校验完整性并审计代码 |
11. 报告编写原则
漏洞项结构
每条发现都应回答：
- What?（是什么） - 清晰漏洞描述
- Where?（在哪里） - 精确位置（文件、行号、端点）
- Why?（为什么） - 根因解释
- Impact?（影响） - 业务后果
- How to fix?（怎么修） - 明确修复方案
严重性分级
| 严重性 | 标准 |
|---|---|
| Critical（严重） | RCE、认证绕过、大规模数据泄露 |
| High（高） | 数据暴露、权限提升 |
| Medium（中） | 影响范围有限且需特定条件 |
| Low（低） | 信息提示/最佳实践类问题 |
牢记： 漏洞扫描负责“发现问题”，专家思维负责“优先级决策”。始终追问：“攻击者会怎样利用它？”