企业官网建设流程全解析

• 应用安全

导读

本文基于 OWASP Top10 官方文档仓库中的 A02:2021 – Kegagalan Kriptografi（Cryptographic Failures） 原文及其英文母版 A02_2021-Cryptographic_Failures.md，系统讲解 2021 版排名第 2 的「加密机制失效」风险：它为何从 2017 年的「敏感数据泄漏（Sensitive Data Exposure）」改名聚焦于根因，官方风险因素表中的各项数据如何解读，如何用一份自查清单评估应用是否脆弱，以及按官方「How to Prevent」基线落地数据分类、传输/静态加密、密钥管理、口令哈希等防护措施。读完本文，你将掌握 OWASP 2021 对加密失效类问题的完整风险模型、检测要点与 29 个映射 CWE 的排查方向，可直接用于安全评审、渗透测试与修复方案设计。

概述：从「症状」到「根因」的分类变迁

在 OWASP Top 10 2021 中，A02:2021 – Cryptographic Failures 较 2017 年上升一位至第 2 名。它此前的名称是 A3:2017 – Sensitive Data Exposure（敏感数据泄漏），官方在 2021 版引言 与本文档中明确指出：Sensitive Data Exposure更多是一种宽泛的「症状（symptom）」而非「根因（root cause）」，而 2021 版刻意将分类聚焦于与密码学相关的失效（或加密缺失）本身，因为正是这些根因导致敏感数据被暴露。

这一改名延续了 2021 版整体的分类哲学：尽可能按根因而非症状归类 CWE，以便给出更符合逻辑的识别与修复指引。仓库 2017 年版的对应文档 0xa3-sensitive-data-disclosure.md 仍保留了旧分类的完整描述，可以对照查看两年的口径差异。

该类别最典型的 CWE 包括：

• CWE-259: Use of Hard-coded Password（硬编码口令的使用）
• CWE-327: Broken or Risky Crypto Algorithm（破损或有风险的加密算法）
• CWE-331: Insufficient Entropy（熵不足）

风险因素数据表

官方文档给出的 A02:2021 数据因素如下（来自 2017 年起各组织贡献的 50 万+ 应用测试数据）：

各项指标的含义（依据 2021 版引言 的 Data Factors 说明）：

• CWEs Mapped（映射 CWE 数）：Top 10 团队映射到该分类的 CWE 数量，本分类为 29 个。
• Incidence Rate（发生率）：在当年被测试的应用总体中，存在至少一个该 CWE 实例的应用占比。A02 的平均发生率为 4.49%，最大达到 46.44%。
• Coverage（测试覆盖率）：所有组织对某一 CWE 实际执行过测试的应用比例，本分类平均 34.85%、最大 79.33%。
• Weighted Exploit / Weighted Impact（加权可利用性 / 加权影响）：由映射到这些 CWE 的 CVE 的 CVSSv2/CVSSv3 子分数归一化到 10 分制后加权平均得到，A02 分别为 7.29 与 6.81——在 Top 10 中属于可利用性高、影响重的组合。
• Total Occurrences / Total CVEs：累计 233,788 次出现、3,075 个相关 CVE。

一个值得注意的统计口径：2021 版使用发生率而非频次来合并工具（Tooling）、人辅工具（HaT）与人测工具（TaH）三类数据，避免高频漏洞（如 XSS）淹没真实风险分布。攻击者只需一个可利用实例即可攻破应用，因此发生率视角更贴近风险。

描述：第一步是确定数据的保护需求

官方文档强调，评估 A02 的第一步是确定**传输中（in transit）与静态（at rest）**数据的保护需求。需要额外保护的数据包括口令、信用卡卡号、健康记录、个人信息、商业秘密等，尤其当其受隐私法律（如欧盟 GDPR）或行业法规（如支付卡行业数据安全标准 PCI DSS）约束时。

针对所有此类数据，应按以下清单逐一核查（英文母版文档比印尼语版列出了更完整的检查项，此处合并呈现）：

• 是否有数据以明文传输？涉及 HTTP、SMTP、FTP 等协议（含 STARTTLS 之类的 TLS 升级路径）。外部互联网流量尤其危险，但必须同样验证所有内部流量，例如负载均衡器、Web 服务器、后端系统之间的链路。
• 是否默认或在旧代码中使用了老旧或脆弱的密码算法/协议？
• 是否在使用默认加密密钥、生成了弱密钥或重复使用密钥、缺乏密钥管理与轮换？加密密钥是否被提交进了源代码仓库？
• 是否未强制实施加密？例如浏览器安全指令或 HTTP 头缺失。
• 是否对收到的服务器证书与信任链进行了正确校验？
• 初始化向量（IV）是否被忽略、重用，或未按加密工作模式生成足够安全？是否使用了不安全的 ECB 模式？在应使用认证加密（authenticated encryption）的场合是否只用了普通加密？
• 是否在没有基于口令的密钥派生函数（PBKDF）的情况下把口令直接当密钥使用？
• 用于密码学目的的随机性是否并非为满足密码学要求而设计？即使选对了函数，是否需要开发者自行播种（seed）？若无需播种，开发者是否用熵不足/可预测的种子覆盖了内置的强播种功能？
• 是否在使用 MD5、SHA1 等已废弃哈希函数，或在需要密码学哈希函数时误用了非密码学哈希？
• 是否在使用 PKCS #1 v1.5 等已废弃的填充方案？
• 密码学错误信息或侧信道信息是否可利用？例如填充预言（padding oracle）攻击。

官方文档同时建议对照 OWASP ASVS（应用安全验证标准）的加密（V7）、数据保护（V9）与 SSL/TLS（V10）章节做交叉验证。仓库 2017 年版文档 0xa3-sensitive-data-disclosure.md 中对应章节可作为延续参考；而 2025 版 A04_2025-Cryptographic_Failures.md 将对应 ASVS 章节升级为 V11（密码学）、V12（安全通信）与 V14（数据保护），可见该检查体系的演进脉络。

如何预防：官方基线防护清单

官方给出的最小防护要求（How to Prevent）是安全评审时应逐条核对的核心基线：

1. 对应用处理、存储或传输的数据进行分类，依据隐私法律、监管要求或业务需求识别敏感数据。
2. 按数据分类落实对应的安全控制（Apply required security controls as per the data classification）。
3. 不无谓存储敏感数据，尽快丢弃，或使用符合 PCI DSS 的 tokenization（令牌化）甚至截断（truncation）。没有被保存的数据不会被窃取。
4. 确保所有静态敏感数据均已加密（encrypt at rest）。
5. 确保使用最新且强健的标准算法、协议与密钥，并采用恰当的密钥管理。
6. 使用安全协议加密所有传输中数据，例如带前向保密（forward secrecy / PFS）密码套件、由服务器主导密码套件优先级（cipher prioritization by the server）、安全参数的 TLS；并通过 HTTP Strict Transport Security（HSTS）等指令强制启用加密。
7. 对包含敏感数据的响应禁用缓存。
8. 不使用 FTP、SMTP 等遗留协议传输敏感数据（英文母版新增项）。
9. 口令存储使用强自适应加盐哈希函数，并设置工作因子（work factor / delay factor），如Argon2、scrypt、bcrypt 或 PBKDF2。
10. IV 必须适配加密工作模式：多数模式要求使用 CSPRNG（密码学安全伪随机数生成器）生成；需要 nonce 的模式则不必使用 CSPRNG。任何情况下，固定密钥下 IV 绝不重复使用（英文母版新增项）。
11. 始终优先使用认证加密（authenticated encryption），而非仅加密（英文母版新增项）。
12. 密钥应以密码学随机方式生成，并在内存中以字节数组形式保存；若使用口令，则必须经恰当的基于口令的密钥派生函数转换为密钥（英文母版新增项）。
13. 确保在适当场合使用密码学随机性，且不以可预测方式或低熵种子播种；现代多数 API 无需开发者手动播种 CSPRNG 即可获得安全性（英文母版新增项）。
14. 避免使用已废弃的密码函数与填充方案，如 MD5、SHA1、PKCS #1 v1.5（英文母版新增项）。
15. 独立验证配置与设置的有效性（Verify independently the effectiveness of configuration and settings）。

2025 版文档在此基础上还补充了「将最敏感的密钥存放于硬件或云端 HSM」「尽量采用被广泛信赖的密码实现」「仅使用 TLS 1.2+、放弃 CBC 密码套件、用工具全面核查」等演进建议，可作为后续版本差异的观察点。

实战落地要点：从清单到代码

清单中的多项内容直接对应具体工程实践，例如：

• 口令存储：优先选用 Argon2id（高内存/时间成本参数），或 scrypt、bcrypt（work factor 通常取 10–12）、PBKDF2（迭代次数应足够高，如 600k+ 次 SHA-256）。选择依据是 CWE-916: Use of Password Hash With Insufficient Computational Effort 所指——计算成本不足的哈希极易被 GPU 暴力破解。
• 传输安全：启用 HSTS 响应头并配置足够长的 max-age，配合证书透明、正确校验证书链（对应 CWE-296），避免算法降级（对应 CWE-757）。
• 静态加密：使用 AEAD 类算法（如 AES-GCM、ChaCha20-Poly1305），避免 ECB（对应 CWE-329 的 CBC IV 问题、CWE-780 的 RSA 无 OAEP 问题）。
• 随机性：统一使用语言运行时的 CSPRNG（如 Java 的SecureRandom、Python 的secrets、Node.js 的crypto.randomBytes），不要自造 PRNG 或用手工 seed 覆盖内置强播种（对应 CWE-330/331/335/336/337/338）。

攻击场景示例

官方文档给出了三个典型攻击场景，说明该分类的实际危害路径：

场景 #1：数据库自动加密形同虚设。应用使用数据库自动加密存储信用卡卡号，但数据在检索时被自动解密，导致一次 SQL 注入漏洞即可直接取回明文卡号。要点：静态加密必须覆盖「被检索后的处理路径」，仅靠数据库层透明加密不足以形成端到端保护。

场景 #2：TLS 缺失/弱化导致会话劫持。站点未对所有页面强制 TLS 或支持弱加密。攻击者在不安全无线网络监听流量，将连接从 HTTPS 降级为 HTTP，截获请求并窃取用户会话 Cookie，随后重放 Cookie 劫持已认证会话，读取或篡改用户隐私数据；亦可篡改传输数据（例如篡改转账收款人）。要点：明文传输与协议降级是传输层最常见的突破口（对应 CWE-319、CWE-757、CWE-523）。

场景 #3：口令哈希无盐或使用简单哈希。口令数据库以无盐或简单哈希存储口令；一个文件上传漏洞使攻击者拿到整个口令库。所有无盐哈希可被预计算彩虹表直接命中；即便加了盐，由简单或快速哈希（如 MD5、SHA1、快速哈希）生成的哈希仍可被 GPU 暴力破解。要点：必须使用带工作因子的自适应慢哈希（对应 CWE-759、CWE-916）。

映射的 CWE 清单（29 个）

该分类共映射 29 个 CWE，是排查与修复时的重要索引（列表源自印尼语/英文母版文档）：

与 2017 版及后续版本的对照

• 2017 版（A3:2017 Sensitive Data Exposure）：仓库中的 0xa3-sensitive-data-disclosure.md 展示了旧版的风险矩阵与检查清单。对比可见，2021 版主要变化有三：一是分类更名、聚焦密码学根因；二是检查清单大幅扩充（新增 IV/nonce 使用、口令派生函数、密码学随机性、认证加密、废弃填充方案、侧信道/填充预言等条目）；三是防护清单新增了禁用遗留协议、认证加密优先、密钥字节数组存储、IV 不重用等硬性要求。
• 2025 版（A04:2025 Cryptographic Failures）：仓库中的 A04_2025-Cryptographic_Failures.md 显示该分类在 2025 版降至第 4 位，映射 CWE 增至 32 个，并新增了 HSM 存储密钥、仅 TLS 1.2+、PQC（后量子密码）迁移准备等建议，可帮助读者理解该主题的持续演进方向。

仓库资源与进一步阅读

本文主题对应 OWASP Top10 官方文档仓库，以下是可直接查阅的原始材料：

• 本文档母版：A02_2021-Cryptographic_Failures.md（英文，信息最完整）
• 繁体中文版：A02_2021-Cryptographic_Failures.md
• 印尼语版（任务关联文档）：2021/docs/id/A02_2021-Cryptographic_Failures.md
• 2021 版整体方法论与数据因素说明：A00_2021_Introduction.md、index.md
• 2017 版旧分类对照：0xa3-sensitive-data-disclosure.md
• 2025 版后续演进：A04_2025-Cryptographic_Failures.md
• 数据收集与 CWE 映射辅助材料：2021/Data/README.md、CWE-Guidance.md
• 文档构建配置（多语言 i18n 与导航）：2021/mkdocs.yml、2021/README.md

官方在文档末尾给出的参考资料还包括 OWASP Proactive Controls（Protect Data Everywhere）、ASVS V7/V9/V10、Transport Layer Protection / User Privacy Protection / Password Storage / Cryptographic Storage / HSTS 等 Cheat Sheet，以及 Testing Guide 中关于弱密码学测试的章节——这些均可在 owasp.org 与 cheatsheetseries.owasp.org 检索获取，用于在落地时逐项深挖。

结语

A02:2021 – Cryptographic Failures 的核心教训在于：敏感数据暴露几乎总是密码学使用不当的「果」，而非独立的「因」。从明文传输、弱算法、默认/复用密钥、无盐快哈希，到 IV 重用、错误随机性、废弃填充方案，29 个映射 CWE 勾勒出一份完整的技术排查地图。将本文的检查清单与防护基线（数据分类、传输/静态加密、密钥管理、口令自适应哈希、认证加密、CSPRNG）嵌入日常安全评审与代码审查流程，即可系统性地降低此类风险。

• 应用安全