CWE 弱点预防

• CWE Top 25 的定位与来源（NVD/CVE 数据统计）
• 基于 CVSS 评分与可利用性/严重性排序
• 年度更新机制及其意义

CWE Top 25 Most Dangerous Software Weaknesses 是 MITRE 每年基于美国国家漏洞数据库（NVD）的大量 CVE 记录，按漏洞的"出现频率"（数据量）与"可利用性/严重性"（CVSS 评分、可利用性、影响）加权计算，得出最危险的 25 类软件弱点（CWE）排行榜。它通过分析真实世界漏洞统计，把常见的软件弱点（如 CWE-79 XSS、CWE-89 SQL 注入、CWE-78 命令注入、CWE-416 释放后使用等）量化排序，供开发、安全团队优先修复和预防。它每年更新，反映最新威胁趋势与漏洞分布变化，是安全工程中"优先修复什么"的重要参考与依据。它关注的是"弱点（Weakness）"而非具体漏洞，属于"通用弱点枚举"的统计视图。

关键点是"基于真实 CVE 数据统计 + 频率与严重性加权 + 年度更新"。它给安全团队提供优先级指引，而非全新标准。答题可强调它与 CWE 枚举体系的关系：CWE 是分类字典，Top 25 是统计出的排名视图。

• CWE-20 的定义：未正确验证输入导致下游错误
• 白名单验证：只接受合法格式
• 在信任边界处验证、规范化

CWE-20（Improper Input Validation）指软件未对输入做正确验证，导致未经检查的数据被下游处理，从而诱发各种漏洞（注入、越界、逻辑错误等）。预防的核心是"白名单（allowlist）验证"：定义合法输入的预期模式（类型、长度、字符集、格式、取值范围），只接受匹配的输入，其余一律拒绝。相比黑名单（试图列出非法模式）无法穷举且易被编码绕过，白名单默认拒绝、可枚举、易维护，因此更可靠。同时应在"信任边界"处验证（如系统入口、进程边界），在验证前先规范化（canonicalize）去重编码，避免双重编码绕过；并采用"输入校验 + 输出编码"双层防御，因为合法输入在特定输出上下文仍可能危险。

CWE-20 的预防即"结构化输入校验"。记忆点：白名单、信任边界、规范化、与输出编码互补。CWE-20 是众多其他 CWE 的"上游根因"，修复它可消解一系列下游漏洞。

• 路径遍历原理：用 ../、绝对路径等逃逸到目录外
• canonicalization：把路径解析为绝对规范路径
• 防御：规范化后校验前缀、拒绝 ../、不得以用户输入拼路径

CWE-22（Path Traversal）指攻击者利用 ../、..\、绝对路径、URL 编码（%2e%2e/）等技巧，把用户提供的文件名/路径当作文件访问路径，从而读取或写入允许目录之外的文件（如 /etc/passwd、源码、配置文件）。预防的关键是"路径规范化（canonicalization）"：把用户输入解析为不含 ..、符号链接、编码等元素的绝对规范路径（如 Java 的 Path.normalize()、getCanonicalPath()），然后校验该规范路径是否仍位于允许的根目录之下（前缀校验），不满足则拒绝。同时：不要用用户输入直接拼接文件路径，解码并规范化输入，拒绝 .. 与绝对路径，并对文件类型做白名单。防御要"先规范化、再校验、后访问"。

路径遍历的防御是"规范化 + 前缀校验"。注意编码绕过（%2e%2e）和符号链接，因此要先 canonicalize 再比较。答题强调"规范化后必须校验仍在允许目录内"。

• CSRF 攻击原理：借浏览器自动携带 cookie 实现跨站请求
• SameSite 属性：限制 cookie 在跨站请求中携带
• CSRF token：服务端校验请求来源/随机令牌

CSRF（Cross-Site Request Forgery）指攻击者诱导受害者浏览器向已登录的目标站点发起"伪造请求"（如转账、改密），由于浏览器会自动携带该站点的 cookie，服务端无法区分请求是否真实由用户发起。预防手段分两个层面：一是 SameSite cookie 属性——设置 SameSite=Lax（默认，跨站顶级导航外的请求不携带）或 SameSite=Strict，可阻止跨站请求携带 cookie，从而阻断大部分 CSRF；二是 CSRF token——服务端为每个会话生成随机令牌，请求中必须携带该令牌（放在隐藏字段/请求头），服务端校验匹配，令牌对攻击者不可见，因此伪造请求无法携带正确 token。工程上通常两者结合：SameSite 作为默认防线，CSRF token 用于关键操作（状态改变请求）的强校验，并配合校验 Origin/Referer 头。

CSRF 的根因是"浏览器自动携带凭证 + 无法区分请求意图"。SameSite 从"凭证携带"层面防御，CSRF token 从"请求可信性"层面防御，二者互补。Get 请求应做幂等，状态变更用 POST 并加 token。

• CWE-79 的定义与三种类型
• 输出编码按上下文（HTML/Attr/JS/CSS/URL）
• 配合 CSP、HttpOnly、输入校验

CWE-79（XSS）指把不可信数据以未正确编码的方式写入 Web 页面，在浏览器中被当作脚本执行。预防的核心是"上下文感知转义（context-aware escaping）"：在数据被渲染的每个上下文（HTML 元素内容、HTML 属性、JavaScript 字符串、CSS、URL）中，使用与该上下文匹配的编码规则转义特殊字符，使攻击载荷只能作为纯文本显示而无法执行。原因是不同上下文对特殊字符的解析不同，编码必须"因地制宜"。除输出编码外，还需：优先使用框架默认转义（React/JSX、Vue 插值、Thymeleaf 的 th:text），避免 dangerouslySetInnerHTML/v-html/th:utext 等绕过转义的 API；对富文本做白名单 sanitize；配合 CSP 限制脚本执行；cookie 设 HttpOnly 降低 payload 窃取会话的可能；以及输入校验和规范化。

CWE-79 的预防核心是"输出端上下文编码"，而非输入过滤。记忆点：五种上下文 + 框架默认转义 + 避免绕过 API + CSP/HttpOnly 纵深。这是最常考的 XSS 防御题。

• CWE-89 的定义与危害
• 参数化查询/预编译语句的原理
• 结构位置仍需白名单

CWE-89（SQL Injection）指因未正确构造 SQL 查询、把用户输入直接拼入 SQL 语句，导致数据库查询语义被改写。预防的首选是"参数化查询/预编译语句（parameterized queries / prepared statements）"：把 SQL 结构固定为模板，用户输入只作为参数值绑定，数据与语法彻底分离，任何特殊字符都只被当作字面值，无法改变语义。相比转义/过滤，参数化是结构性方案，无绕过空间。同时需注意：ORM 框架（Hibernate、MyBatis、Sequelize）只有在其参数绑定路径下才安全，raw query/字符串拼接会重新暴露注入；表名、列名、ORDER BY 等结构位置无法参数化，须用白名单校验。此外遵循"最小权限"（数据库账号只用必要权限）、对错误信息脱敏、定期扫描审计。

CWE-89 的预防金标准是"参数化"。答题要强调参数化为何可靠（数据/语法分离）、以及结构位置的补充白名单。这是最经典的安全编码问题。

• CWE 的组织方式：分类树（CWE）、视图（View）
• View 是特定视角下的 CWE 子集
• 按语言（如 CWE-658/659 C/C++、CWE-660 Java）、按领域（Web、移动、云）的视图

CWE（Common Weakness Enumeration）是一个通用弱点字典，而"视图（View）"是 CWE 的一种组织方式，它从特定视角选取一组 CWE 条目，便于按维度查找和避免重复。常见的视图包括：分类视图（Categorization View，如 CWE-699 软件开发视图），按软件生命周期/层面对 CWE 分类；按领域视图，如 CWE-1194（硬件设计）、CWE-1335（OWASP Top Ten 2021 映射）、面向 Web 应用、移动应用、云/容器等领域的视图；以及"按语言"的视图，如 CWE-658/659（C/C++）、CWE-660（Java）、CWE-663（Python）等。不同视图服务于不同受众（开发者、审计员、测试者），本质是"同一弱点的不同切面"。CWE Top 25 也是基于数据统计的"视图"之一。

视图是 CWE 的"视角/切面"，用于按语言、领域、生命周期等维度组织和检索弱点。答题要区分"CWE 是字典、View 是视角"，并举例说明按语言/领域的视图用途。

• 文件上传漏洞：恶意文件被上传并在服务器执行
• 防御：扩展名白名单、MIME 校验、内容校验、存储隔离
• 内容嗅探（X-Content-Type-Options）与执行权限

CWE-434（Unrestricted File Upload）指允许用户上传文件但未限制类型/内容，攻击者可上传可执行文件（如 .php、.jsp、.exe、WebShell）并在服务器上执行，导致 RCE。预防措施包括：扩展名白名单（仅允许图片等安全类型）、MIME 类型校验（但 MIME 可伪造，需结合内容校验）、对文件内容做真实校验（如图片解析成真实图片、校验文件头 magic bytes）、文件重命名（随机文件名并去除扩展名控制）、存储到非 Web 可达目录或对象存储、禁止上传目录的执行权限、对上传文件大小限制。内容嗅探角度：响应头 X-Content-Type-Options: nosniff 可防止浏览器忽略 Content-Type 而嗅探内容，降低 HTML/脚本伪装文件被当作页面执行的风险。此外对上传文件做病毒扫描、定期审计。

文件上传的防御是"多因素"：类型白名单 + 内容校验 + 存储/执行隔离 + nosniff。MIME 与扩展名都不可信，须以内容校验和存储控制为准。答题强调"上传不是静态文件，而是潜在可执行代码"的思维。

• 反序列化攻击的风险（RCE）
• 预防：不反序列化不可信数据、签名校验、类白名单、安全格式
• 纵深防御：在隔离环境反序列化、限制对象大小/深度、升级依赖消除已知 gadget

CWE-502（Deserialization of Untrusted Data）指程序反序列化来自不可信来源的数据，攻击者可构造恶意序列化数据，在反序列化时触发任意对象构造、属性设置和 gadget 链，最终导致远程代码执行（RCE）、DoS 或重放。预防措施包括：根本原则是"不对不可信数据反序列化"；若必须反序列化，用 HMAC 签名/完整性校验并验证数据来源；使用反序列化类白名单（allowlist）限制可实例化的类（如 Java 的 ObjectInputFilter、PHP 的 allowed_classes）；优先选用安全格式（如 JSON）并配合强类型校验，避免 Java 原生/unserialize 等带类型载荷的格式；将反序列化放在隔离环境；升级依赖消除已知 gadget；对反序列化输入做大小/深度限制防 DoS。

与 CWE-502 相关的核心是"不信任数据 + 限制类 + 安全格式"。答题要强调"避免原生反序列化格式、加白名单、签名验证"。与 CWE-20 的关联：输入验证是缓解手段之一。

• 开放重定向的利用：钓鱼、配合 OAuth 窃取 token
• 白名单重定向：只允许跳转到已知合法域名
• 相对路径/内部跳转校验

CWE-601（Open Redirect）指应用根据用户可控参数（如 redirect=、next=、url=）进行重定向，却不校验目标地址，攻击者可把用户重定向到恶意站点，用于钓鱼（诱骗用户输入凭证）或配合 OAuth 授权流程窃取授权码/token。预防的核心是"白名单重定向"：只允许重定向到预先定义的可信域名白名单，凡目标不在白名单一律拒绝（或跳转到默认页）；对重定向目标做规范化和校验，拒绝 // 协议相对地址、javascript: 等危险协议；优先使用相对路径或内部映射（用 code 映射到目标 URL），避免直接透传用户输入的 URL；对带协议的绝对 URL 做严格域名校验。工程上还可要求重定向必须携带服务端签名/一次性 token。

开放重定向是"重定向逻辑未校验目标"。白名单是核心防御：只跳已知安全目标。答题强调"白名单 + 拒绝协议相对/危险协议 + 内部映射"。

• XXE 原理：XML 解析器外部实体导致文件读取/SSRF
• 预防：禁用外部实体/DTD、secure parsing
• 现代 XML 解析库的安全配置

CWE-611（XXE，XML External Entity Injection）发生在应用使用支持外部实体（External Entity）的 XML 解析器处理 XML 时，攻击者通过 <!DOCTYPE foo [<!ENTITY xxe SYSTEM "file:///etc/passwd">]> 声明外部实体，使解析器读取本地文件、发起内部网络请求（SSRF）或触发 DoS（Billion Laughs 实体扩展爆炸）。预防的核心是"禁用外部实体/DTD"：在解析器配置中关闭外部通用实体、外部参数实体和 DTD 处理（各类解析器：Java 的 DocumentBuilderFactory/SAXParserFactory 需显式设置 setFeature 禁用外部实体；Python 用 defusedxml；新版默认安全的解析器可优先选择）。同时限制解析器可访问的网络资源、对 XML 做大小限制、尽量使用 JSON 等更安全格式。若确实需要外部实体，则用白名单限定来源并做好超时与权限控制。

XXE 的防御是"关闭外部实体与 DTD"。核心是"解析器安全配置"，而非过滤 XML 内容。答题强调"禁用 DTD/外部实体 + 最小化解析能力 + 防 DoS"。

• 命令注入根因：拼输入进 shell 命令
• 避免 shell：用 argv 数组形式进程调用 API
• 白名单、最小权限

CWE-78（OS Command Injection）指应用把含用户输入的命令字符串交给 shell 执行，攻击者用 ;、|、$()、反引号等元字符注入额外命令，导致任意命令执行。预防的关键是"避免 shell"：使用进程调用 API 直接以参数数组形式执行（Java ProcessBuilder(list)、Python subprocess 以列表传参、Node child_process.spawn 数组形式），此时参数不经 shell 解释，元字符只作为普通参数，无法注入。避免使用 Runtime.exec(字符串)、system()、exec(字符串) 等会调用 shell 的接口。若必须用 shell，则对输入做严格白名单校验并明确处理元字符。同时遵循最小权限（命令以低权限账号运行）、避免把动态命令拼进 shell 脚本、对错误信息脱敏。

命令注入的防御核心是"不让参数进入 shell 的语法解析层"。用 argv 数组避免 shell 是"治本"手段。答题强调"避免 shell + 参数数组 + 最小权限"。

• CWE 的层级分类：视图、分类、条目
• Top 25 是基于统计的排名视图
• 与 CVE、OWASP 的关系

CWE 由 MITRE 维护，是一个"通用弱点字典"，通过层级化分类（分类树/视图）组织上千个弱点条目。分类体系包括：条目（CWE-xxx，如 CWE-79 XSS）、分类视图（Categorization View，如按开发阶段、按技术领域）、按语言/领域/维度的视图（View）。CWE Top 25 Most Dangerous Software Weaknesses 是其中一种"基于真实漏洞数据统计"的排名视图——它根据 NVD 的 CVE 数据，按频率与 CVSS 严重性加权，选出当年度最危险的 25 类弱点，每年更新，用于指导"优先修复什么"。它与 CVE（具体漏洞编号）是不同的层面：CVE 指具体漏洞实例，CWE 指漏洞所属的弱点类型。它与 OWASP Top 10 类似（OWASP 聚焦 Web 应用，CWE 更通用），都是安全工程优先级参考。

答题要区分"CWE 字典 / CVE 实例 / Top 25 排名视图"。Top 25 是统计视图而非独立标准。理解 CWE 与 CVE、OWASP 的关系体现体系化认知。

• 硬编码凭证的风险：源码泄露即凭证泄露
• 预防：环境变量/密钥管理服务/Vault
• 密钥管理：集中存储、轮换、访问控制

CWE-798（Hard-coded Credentials）指在源码中硬编码密码、密钥、令牌等凭证，一旦源码泄露（仓库公开、代码审查、备份泄露），凭证随之泄露，且难以轮换（需改代码重新部署）。预防的核心是把凭证从代码中剥离，改由"密钥管理"体系提供：优先使用环境变量（但仅适用于非敏感、易轮换场景）、专用密钥管理服务（KMS、HashiCorp Vault、AWS Secrets Manager、云厂商 Secrets Manager）集中存储与按需注入，而非静态配置。密钥管理的关键能力包括：集中存储与加密、细粒度访问控制（最小权限）、自动轮换（rotation）、审计日志（谁在何时访问了哪些密钥）、动态/短时凭证（避免长期静态密钥）。工程上配合 git-secrets 等工具拦截硬编码凭证入仓、CI 变量遮蔽（mask）、扫描代码库与历史提交发现已泄露凭证。

硬编码凭证的根因是"凭证与代码耦合"。预防是"凭证与代码分离 + 集中密钥管理"。答题强调"动态获取、轮换、访问控制、审计、扫描"。

• SSRF 原理：服务端请求用户可控 URL
• 预防：URL 白名单、禁止内网地址、DNS 校验、代理控制
• 攻击面：云元数据服务（169.254.169.254）、内网与本地服务、端口扫描

CWE-918（SSRF，Server-Side Request Forgery）指应用根据用户可控的 URL 向目标发起服务端请求，攻击者可利用它访问内网地址、云元数据服务（如 AWS 的 169.254.169.254）、本地服务等不应被外部访问的资源，或用于端口扫描。预防措施包括：对请求目标做严格白名单校验（只允许已授权的域名/IP）；解析并校验最终 IP 地址，拒绝内网、回环、链路本地、云元数据地址（127.0.0.1、10.x、172.16-31.x、192.168.x、169.254.169.254、IPv6 内网等）；注意 DNS 重绑定（TOCTOU）——先解析后请求可能被替换，需二次校验或使用固定 IP；禁止重定向到内网/本地；对请求设置超时、限制响应大小；通过受控的代理/网关出网，隔离应用与内网。对必须访问外部 URL 的场景，用白名单映射而非透传原始 URL。

SSRF 的根因是"服务端信任用户可控 URL 发起请求"。防御核心是"白名单 + 阻止内网/元数据地址 + DNS 校验 + 出网隔离"。答题要覆盖内网地址与 DNS 重绑定这些关键点。

• 缓冲区溢出：C/C++ 等内存不安全语言
• 内存安全语言（Rust/Go/Java）减少此类漏洞
• 工具：ASAN、编译器检查、卫士（canary）

缓冲区溢出（Buffer Overflow）主要出现在 C/C++ 等"内存不安全"语言中，因为这类语言允许直接指针操作且不自动检查边界，对越界读写、栈溢出、堆溢出、use-after-free 缺乏防护，攻击者可覆盖相邻内存实现 RCE。缓解分"语言"与"工具"两个层面：语言层面——优先选用内存安全语言（Rust、Go、Java、Python 等），Rust 通过所有权与借用检查在编译期杜绝大部分内存错误；若必须用 C/C++，用现代安全惯例（如边界检查、智能指针、禁止 strcpy 等危险函数）。工具层面——编译器开启安全特性（栈保护 canary、ASLR、PIE、-fstack-protector）、使用内存检测工具（ASan、Valgrind、MSan）在测试阶段发现越界、启用 fuzzing（模糊测试）与静态分析（Coverity、Clang static analyzer）。此外开启操作系统级防护（NX、DEP、ASLR）也可降低可利用性。

内存安全的核心是"语言保证 + 工具加固"。Rust 从编译期根除，C/C++ 需靠工具与规范。答题强调"内存安全语言 vs 检测/加固工具"两个层面。

• 越权（IDOR/水平垂直越权）：未校验对象属主
• 竞态（TOCTOU）：检查与使用不一致
• 错误处理：错误信息泄露、异常导致状态不一致

逻辑漏洞不依赖注入等语法缺陷，而是"业务逻辑设计缺陷"。越权（如 IDOR、水平/垂直越权）指未校验用户对目标资源的访问权限，攻击者通过修改资源 ID 访问他人数据，防范需在每次访问时做"对象级授权检查"（确认当前用户是该资源属主或具备权限）。竞态（TOCTOU，Time-of-check to Time-of-use）指"检查"与"使用"之间被并发修改，导致检查失效，防范需用原子操作、锁、事务、唯一约束或乐观并发控制。错误处理不当则包括：错误信息泄露内部细节（利于攻击者探测）、异常处理缺失导致功能中断或状态不一致，防范需对外返回通用错误、把内部详情写日志、对异常做统一处理并保证事务/状态一致性。此外还有支付金额篡改、重放、限制绕过等逻辑漏洞，需通过业务规则校验、幂等、防重放等手段防范。

逻辑漏洞防御的核心是"业务语义校验 + 授权检查 + 并发一致性"。答题覆盖越权、竞态、错误处理三类，并给出各自的针对性手段。

• 威胁建模（识别威胁与攻击面）
• 安全设计/编码规范
• 静态分析、SAST/DAST、依赖扫描、人工评审

弱点预防不是单一动作，而是一个"开发周期内嵌"的工程流程，通常包括：1）威胁建模（Threat Modeling）：在设计与需求阶段用 STRIDE 等模型识别威胁、攻击面与信任边界，确定风险优先级；2）安全设计：遵循最小权限、纵深防御、默认拒绝等原则并落地安全编码规范；3）开发阶段预防：白名单输入校验、参数化查询、输出编码、安全配置等；4）工具化验证：SAST（静态分析，如 CodeQL、SonarQube）扫描源码、DAST（动态应用安全测试）扫描运行中应用、依赖与供应链扫描（SCA）、密钥扫描；5）人工评审：安全代码评审、渗透测试；6）验证与回归：安全测试用例、模糊测试、上线后安全监控与日志审计、漏洞响应流程。整个过程强调"安全左移"（Security Shift-left），把验证前置到开发早期，并持续回归。

弱点预防是"流程 + 工具 + 规范"的系统工程。答题按"建模→设计→编码→验证→监控"的流水线展开，突出"安全左移"与"纵深防御"理念。