OWASP CheatSheetSeries 项目实战指南：用 Cheat Sheet 落地 OWASP Top Ten Proactive Controls 2018 十大主动安全控制-平芜编程栈

应用安全

【免费下载链接】CheatSheetSeries

The OWASP Cheat Sheet Series was created to provide a concise collection of high value information on specific application security topics.

项目地址：https://gitcode.com/gh_mirrors/ch/CheatSheetSeries

点击查看免费下载

导读

本文以 OWASP CheatSheetSeries 仓库中的 IndexProactiveControls.md 为核心索引，系统梳理 OWASP Top Ten Proactive Controls 2018 的十个主动安全控制（C1–C10），并逐一映射到本仓库对应的实战 Cheat Sheet 文档。读完本文，你将掌握每个主动控制的核心技术要求、对应的具体防御文档与可复制的代码示例，能够把"定义安全需求、安全访问数据库、校验所有输入、实现数字身份、强制访问控制"等十条主动控制，直接落地到自己的软件开发生命周期（SDLC）中。

什么是 OWASP Top Ten Proactive Controls

OWASP Top Ten Proactive Controls 2018 是一份"应该被纳入每一个软件开发项目"的安全技术清单，按重要性排序，编号 1 的控制最为重要。它的定位与 OWASP Top 10（十大风险）互补：Top 10 描述的是"哪些环节会出问题"，而 Proactive Controls 回答的是"开发阶段应该主动做哪些事情"来避免这些问题。

IndexProactiveControls.md 的核心价值在于：它把每个主动控制映射到本仓库中对应的 Cheat Sheet 文档，让开发者可以按控制逐项查阅详细的防御方案、代码示例与配置清单。该映射关系的来源与背景可参见 OWASP Top Ten Proactive Controls 2018 官方项目。

十个控制整体脉络如下：

编号	主动控制	核心目标
C1	Define Security Requirements	在需求阶段定义可验证的安全需求
C2	Leverage Security Frameworks and Libraries	复用经过验证的安全框架与库
C3	Secure Database Access	安全访问数据库（参数化查询）
C4	Encode and Escape Data	对所有输出做编码与转义
C5	Validate All Inputs	校验一切输入
C6	Implement Digital Identity	正确实现认证、会话与身份管理
C7	Enforce Access Controls	强制访问控制
C8	Protect Data Everywhere	全生命周期保护数据
C9	Implement Security Logging and Monitoring	安全日志与监控
C10	Handle All Errors and Exceptions	安全处理所有错误与异常

C1. Define Security Requirements：从需求源头注入安全

C1 是所有主动控制中最重要的一项，强调安全必须在需求阶段被明确定义，而不是事后补救。本仓库为 C1 提供了三份核心文档：

Abuse Case Cheat Sheet：通过"滥用用例"（Abuse Case）反向推导安全需求。
Attack Surface Analysis Cheat Sheet：通过分析攻击面识别哪些功能需要安全需求。
Threat Modeling Cheat Sheet：通过威胁建模系统化地发现"什么会出错"。

用滥用用例把模糊需求变成可执行的安全要求

Abuse Case Cheat Sheet 指出，需求中常见的"应用必须安全""应用必须防御所有攻击"这类表述过于笼统，对开发团队毫无用处。更务实的做法是识别出应用在其业务与技术上下文中最需要防御的攻击，把每条攻击写成滥用用例——即"一种实现者未预期到的功能使用方式，允许攻击者基于其行为或输入来影响该功能或其使用结果"。

该文档给出了一个非常实用的落地流程（并配有流程总览图）：

准备工作坊：召集业务分析师、风险分析师、渗透测试人员、技术负责人和 QA 分析师，用 Excel/Google Sheets 建立FEATURES（业务功能）、ABUSE CASES（滥用用例）、COUNTERMEASURES（对策）三张表。
工作坊产出：对每个业务功能，由渗透测试人员提出攻击，AppSec 给出对策，并用 CVSS v3 计算器评定风险等级，最终由业务/风险/技术负责人共识筛选出必须处理与可接受风险的用例。
会后落地：把选定用例写入功能规格说明（瀑布）或 User Story 验收标准（敏捷）。
实现期跟踪：为每个用例分配唯一 ID（如ABUSE_CASE_001），在代码中用@AbuseCase(ids={"ABUSE_CASE_001","ABUSE_CASE_002"})之类的注解标记，通过脚本即可定位用例的落地位置。
验证：用 SAST/DAST 自定义审计规则、安全定向的单元/集成/功能测试进行自动化验证，或通过安全代码评审、渗透测试进行人工验证。

用攻击面分析定位高风险的"必须防御区"

Attack Surface Analysis Cheat Sheet 将攻击面定义为四部分的集合：进出应用的数据/命令路径、保护这些路径的代码（资源连接、认证授权、日志、校验与编码）、应用中的高价值数据（密钥、PII、核心业务数据）、以及保护这些数据的代码。实践建议是把攻击点按类型分桶（如登录入口、管理后台、查询搜索、CRUD 表单、业务工作流、事务接口/API、运维接口等），统计各类型数量后抽样评估——不需要理解每个端点也能掌握系统的风险画像。对微服务与云原生应用，应优先评估从互联网可达的组件（可能位于代理、负载均衡与 Ingress 之后并自动伸缩）。

用威胁建模系统回答四个问题

Threat Modeling Cheat Sheet 围绕威胁建模宣言的四个问题展开：我们在做什么？什么会出错？我们打算怎么办？我们做得够好吗？系统建模阶段推荐使用数据流图（DFD）标注信任边界、数据流、数据存储、进程与外部实体；威胁识别阶段常用 STRIDE 模型——Spoofing（破坏认证）、Tampering（破坏完整性）、Repudiation（破坏审计）、Information Disclosure（破坏机密性）、Denial of Service（破坏可用性）、Elevation of Privileges（破坏授权）；之后对每个威胁在 Mitigate（缓解）/Eliminate（消除）/Transfer（转移）/Accept（接受）四种响应中做出选择，并最终由全体利益相关方评审验证。

C2. Leverage Security Frameworks and Libraries：复用安全框架与库

C2 强调不要重复造轮子，应优先使用经过验证的安全框架、库与配置基线。本仓库映射的核心文档包括：

Clickjacking Defense Cheat Sheet
DotNet Security Cheat Sheet（重点见 A3 Cross Site Scripting 小节）
PHP Configuration Cheat Sheet
Ruby on Rails Cheat Sheet（重点见 Tools 与 XSS 小节）
Vulnerable Dependency Management Cheat Sheet

以点击劫持防御为例，Clickjacking Defense Cheat Sheet 给出了三种相互独立、可纵深防御组合的机制：

HTTP 响应头阻止被嵌入框架：优先使用 CSP 的frame-ancestors指令（如Content-Security-Policy: frame-ancestors 'none';禁止任何域嵌入、frame-ancestors 'self';仅允许本站、frame-ancestors 'self' *.somesite.com https://myfriend.site.com;允许白名单域）；也可用X-Frame-Options头（DENY、SAMEORIGIN、ALLOW-FROM uri，注意ALLOW-FROM已过时且浏览器不支持时会失效）。
SameSite Cookie 属性：把会话 Cookie 标记为SameSite=Strict/Lax后，嵌入<iframe>中的请求不会携带该 Cookie，需要登录态的点击劫持攻击将直接失效；但对无需认证的攻击无效，只能作为纵深防御手段。
Frame-buster 脚本：对不支持上述头的旧浏览器，用"先隐藏 body、脚本检测到被嵌入时跳出框架"的方式兜底。

一个常见的错误是使用<meta http-equiv="X-Frame-Options" content="deny">这类 meta 标签——meta 标签不生效，X-Frame-Options与 CSPframe-ancestors都必须作为 HTTP 响应头下发。另外要注意：若资源同时携带frame-ancestors（enforce 处置），按 CSP 规范X-Frame-Options应被忽略，但旧版浏览器（如 Chrome 40、Firefox 35）会优先跟随X-Frame-Options。

C3. Secure Database Access：用参数化查询锁死数据库访问

C3 是防御注入类漏洞的主战场，映射文档包括：

SQL Injection Prevention Cheat Sheet
Query Parameterization Cheat Sheet
DotNet Security Cheat Sheet（Data Access 与 A1 SQL Injection 小节）
Ruby on Rails Cheat Sheet（SQL Injection 小节）

四种主防御方案

SQL Injection Prevention Cheat Sheet 给出了四种按优先级排列的防御方案：

方案 1（首选）：预编译语句（参数化查询）。先定义全部 SQL 骨架，再用占位符把每个参数传入，数据库始终能区分"代码"与"数据"。即便攻击者输入tom' or '1'='1，也只会被当作普通字符串值匹配。
方案 2：安全构造的存储过程。与参数化查询等效，前提是存储过程内部不使用动态拼接 SQL；若在存储过程内动态构造 SQL，同样必须用绑定变量（见下文）。
方案 3：白名单输入校验。仅当参数无法绑定（如表名、列名、排序关键字 ASC/DESC）时才使用，理想情况下这些值应来自代码而非用户参数。
方案 4（强烈不推荐）：转义所有用户输入。容易出错，只作为最后手段。

可直接复制的参数化查询示例

Query Parameterization Cheat Sheet 提供了覆盖主流语言的参数化查询示例，下面节选几种典型写法。

Java（JDBC 内置）——用?占位符绑定参数：

String custname = request.getParameter("customerName"); String query = "SELECT account_balance FROM user_data WHERE user_name = ? "; PreparedStatement pstmt = connection.prepareStatement( query ); pstmt.setString( 1, custname); ResultSet results = pstmt.executeQuery( );

Java + Hibernate（HQL 命名参数）：

Query safeHQLQuery = session.createQuery("from Inventory where productID=:productid"); safeHQLQuery.setParameter("productid", userSuppliedParameter);

PHP（PDO）：

$stmt = $dbh->prepare("INSERT INTO REGISTRY (name, value) VALUES (:name, :value)"); $stmt->bindParam(':name', $name); $stmt->bindParam(':value', $value);

Ruby（ActiveRecord）：

Project.where("name = :name", :name => name)

C# ASP.NET（SqlCommand）：

string sql = "SELECT * FROM Customers WHERE CustomerId = @CustomerId"; SqlCommand command = new SqlCommand(sql); command.Parameters.Add(new SqlParameter("@CustomerId", System.Data.SqlDbType.Int)); command.Parameters["@CustomerId"].Value = 1;

Rust（SQLx）——既支持编译期宏也支持运行时绑定：

let users = sqlx::query_as!( User, "SELECT * FROM users WHERE name = ?", username ) .fetch_all(&pool) .await .unwrap();

该文档还特别提醒：很多前端框架/库的"查询参数化"其实只是先把查询拼好再发给服务器，参数化必须在服务端完成；此外，存储过程内部的动态 SQL 也必须用绑定变量。例如 Oracle PL/SQL 中用EXECUTE IMMEDIATE stmt INTO result USING UserID, Dept;，SQL Server T-SQL 中用EXEC sp_executesql @sql, '@UID VARCHAR(20), @DPT VARCHAR(10)', @UID=@UserID, @DPT=@Dept;来明确告诉数据库"这些输入是数据而非代码"。

C4. Encode and Escape Data：对所有输出做上下文感知编码

C4 的核心思想是：任何进入 HTML、属性、URL、JavaScript 或 CSS 上下文的动态变量，都必须按所在上下文进行编码或转义，防止被解释为代码。映射文档包括：

Cross Site Scripting Prevention Cheat Sheet
DOM based XSS Prevention Cheat Sheet
Injection Prevention Cheat Sheet
Injection Prevention Cheat Sheet in Java
LDAP Injection Prevention Cheat Sheet
Web Frontend Security Cheat Sheet（Client Side JavaScript 小节）

输出编码的三个关键要点

以 XSS 防御为例，Cross Site Scripting Prevention Cheat Sheet 强调没有任何单一技术能解决 XSS，必须组合防御。核心要点如下：

优先使用框架默认的自动转义：现代框架通过模板、自动转义引导开发者走向安全实践。但要警惕框架的"逃生舱"：React 的dangerouslySetInnerHTML、Angular 的bypassSecurityTrustAs*、Lit 的unsafeHTML、Polymer 的inner-h-t-m-l等，一旦使用且未先清洗 HTML，就会重新引入 XSS。
按上下文选择正确的编码函数：浏览器对 HTML、JS、URL、CSS 的解析方式不同，用错编码方法反而会引入弱点。例如把变量插入<div>之间的"HTML 上下文"应做 HTML 实体编码（&→&、<→<、>→>、"→"、'→'）；插入属性值（"HTML 属性上下文"）时必须用引号包裹变量并做属性编码，以缩小需要编码的字符集。
使用安全汇点（Safe Sinks）：例如用 JavaScript 写 HTML 时使用.textContent，它会自动做 HTML 实体编码，是安全汇点。

C5. Validate All Inputs：以白名单为主、纵深防御为辅

C5 要求对来自所有不可信来源的数据（不止面向互联网的 Web 客户端，还包括 extranet 后端数据源、供应商/合作伙伴/监管机构的上游数据）尽早进行校验。映射文档众多，核心包括：

Input Validation Cheat Sheet
Bean Validation Cheat Sheet
Deserialization Cheat Sheet
File Upload Cheat Sheet
Mass Assignment Cheat Sheet
OS Command Injection Defense Cheat Sheet
XML External Entity Prevention Cheat Sheet
Server Side Request Forgery Prevention Cheat Sheet
Unvalidated Redirects and Forwards Cheat Sheet
REST Security Cheat Sheet（Input Validation 小节）

白名单优于黑名单

Input Validation Cheat Sheet 明确指出：用黑名单去拦截'、1=1、<script>这类危险特征是本质有缺陷的做法——攻击者极易绕过过滤器，而且会误伤合法输入（如爱尔兰姓氏O'Brian）。正确姿势是白名单校验：明确定义"什么是允许的"，除此之外一律拒绝。注意，输入校验不应作为防 XSS、SQL 注入的主要手段（那要靠输出编码与参数化查询），但正确实现能显著降低攻击影响。

校验应在语法层（结构化字段格式正确，如 SSN、日期、货币符号）与语义层（业务上下文中的值正确，如开始日期早于结束日期、价格在预期范围内）同时进行。白名单正则示例——美国 ZIP 码^\d{5}(-\d{4})?$，Java 中用Pattern预编译并调用matcher( zipCode ).matches()校验。对于自由格式的 Unicode 文本，则应采用规范化（Normalization）、Unicode 字符类别白名单（如"十进制数字""字母"类别，可覆盖拉丁、阿拉伯、西里尔、CJK 等全球文字）与单字符白名单策略；同时务必防范正则拒绝服务（ReDoS）——不良设计的正则可能让程序长时间占用 CPU。

补充要点

Bean Validation（Java 生态）：用声明式注解（如@NotNull、@Size、@Pattern）在模型层集中执行校验规则，仓库配套的 Bean_Validation_Cheat_Sheet_JSR.png 与 Bean_Validation_Cheat_Sheet_Typical.png 展示了典型校验流程。
反序列化：绝不反序列化不可信数据；若必须，采用白名单类过滤与完整性校验。
文件上传：校验文件类型、大小、内容，将文件存储于应用目录之外并使用随机文件名。
SSRF：对 URL 输入做域名解析校验与目标 IP 白名单/黑名单过滤。

C6. Implement Digital Identity：正确实现认证、会话与身份

C6 覆盖认证（AuthN）、会话管理与数字身份全链路，映射文档包括：

Authentication Cheat Sheet
Session Management Cheat Sheet
Password Storage Cheat Sheet
Forgot Password Cheat Sheet
Choosing and Using Security Questions Cheat Sheet
JSON Web Token Cheat Sheet
SAML Security Cheat Sheet
JAAS Cheat Sheet
Multifactor Authentication Cheat Sheet
REST Security Cheat Sheet（JWT 小节）

认证基础原则

Authentication Cheat Sheet 给出的关键实践包括：

用户 ID 应随机生成，避免可预测/顺序化的 ID 被外部推断利用。
禁止用敏感内部账号（后端/中间件/数据库账号）直接登录前端界面，也不要用内部认证方案（IDP/AD）直接服务不可信的外部访问（如公网/DMZ）。
密码强度策略：若启用 MFA，密码短于 8 字符即视为弱；未启用 MFA 时短于 15 字符视为弱（依据 NIST SP800-63B）；最大长度至少 64 字符以支持口令短语，但注意某些哈希实现可能引发"超长密码 DoS"；不要静默截断密码；允许所有字符（含 Unicode 与空格），不做字符组合规则限制；用强度计（如 zxcvbn-ts）帮助用户、对接 Pwned Passwords 拦截已泄露密码。
密码比较：优先使用框架提供的安全比较函数（如 PHP 的password_verify()）；否则保证比较函数有最大输入长度、显式设定变量类型（防类型混淆，如 PHP Magic Hashes）并以常数时间返回（防时序攻击）。
修改密码功能：必须要求用户处于已认证活动会话、并验证当前密码，防止他人利用遗留在公共电脑上的活动会话篡改密码。

身份与会话管理

会话：会话标识应每个用户唯一且难以预测，详见 Session Management Cheat Sheet。
密码存储：使用自适应、加盐的慢哈希算法（如 Argon2、bcrypt、scrypt、PBKDF2），详见 Password Storage Cheat Sheet（仓库附有 PBKDF2 迭代测试用例可参考其迭代数设定思路）。
找回密码：防止账户枚举与滥用，详见 Forgot Password Cheat Sheet。
多因素认证：强烈建议启用 MFA，详见 Multifactor Authentication Cheat Sheet。
令牌：使用 JWT/SAML 时严格校验签名、alg、过期时间、受众与颁发者，详见 JSON Web Token Cheat Sheet 与 SAML Security Cheat Sheet。

C7. Enforce Access Controls：授权与访问控制的强制落地

C7 关注授权（AuthZ）、越权与 CSRF 防御，映射文档包括：

Access Control Cheat Sheet
Insecure Direct Object Reference Prevention Cheat Sheet
Cross-Site Request Forgery Prevention Cheat Sheet
Authorization Testing Automation Cheat Sheet
Transaction Authorization Cheat Sheet
Credential Stuffing Prevention Cheat Sheet
REST Security Cheat Sheet（Access Control 小节）
DotNet Security Cheat Sheet（A4 不安全直接对象引用、A7 缺失功能级访问控制小节）
Ruby on Rails Cheat Sheet（IDOR/强制浏览与 CSRF 小节）

访问控制要点

以"默认拒绝"为正模型：正向（positive）访问模型中，新角色/用户类型定义错误很容易暴露；负向（negative，默认允许）模型则必须格外谨慎地确保用户不会越权访问数据或功能。
防止 IDOR：不要直接用用户可控的主键访问他人记录，使用间接引用或对象级授权校验，详见 Insecure Direct Object Reference Prevention Cheat Sheet。
防 CSRF：使用同步 Token 模式、双重提交 Cookie、SameSiteCookie 属性等机制，详见 Cross-Site Request Forgery Prevention Cheat Sheet。
授权测试自动化：通过自动化回归测试验证授权逻辑（如对不同角色批量执行端点矩阵测试），详见 Authorization Testing Automation Cheat Sheet。
事务级授权：对高风险交易（支付、转账）执行二次授权/动态确认，详见 Transaction Authorization Cheat Sheet。
凭据填充防护：部署速率限制、验证码、IP 信誉与撞库检测，详见 Credential Stuffing Prevention Cheat Sheet。

C8. Protect Data Everywhere：全生命周期保护数据

C8 要求数据在静态、传输中与使用中都受到保护，映射文档包括：

Cryptographic Storage Cheat Sheet
Key Management Cheat Sheet
Transport Layer Security Cheat Sheet
Transport Layer Protection Cheat Sheet
HTTP Strict Transport Security Cheat Sheet
Pinning Cheat Sheet
User Privacy Protection Cheat Sheet
REST Security Cheat Sheet（HTTPS 小节）

实践要点：静态数据使用经过验证的加密算法（如 AES-256-GCM）并配合严格的密钥生命周期管理（生成、轮换、吊销），详见 Key Management Cheat Sheet；传输数据强制 TLS，配置 HSTS 响应头（Strict-Transport-Security）杜绝降级，详见 HTTP Strict Transport Security Cheat Sheet；高价值端点可配合证书/公钥固定（Pinning）防御中间人，详见 Pinning Cheat Sheet（仓库附带 DotNet 示例与 OpenSSL 示例压缩包）；用户隐私遵循数据最小化、明确同意与脱敏原则，详见 User Privacy Protection Cheat Sheet。

C9. Implement Security Logging and Monitoring：安全日志与监控

C9 强调可审计性：攻击者依赖"日志缺失 + 无监控响应"来掩盖入侵（Logging Cheat Sheet 引用的研究指出，2016 年识别一次入侵平均耗时约 191 天）。映射文档：

Logging Cheat Sheet
Logging Vocabulary Cheat Sheet
REST Security Cheat Sheet（Audit Logs 小节）

关键实践包括：对认证成功/失败、授权决策、数据变更、输入校验失败等安全事件记审计日志；日志内容必须不可篡改（防伪/防删除）；记录来源 IP、用户标识、时间戳与事件结果；日志不应包含敏感明文数据（如密码、完整令牌）；并建立告警与响应机制，使入侵行为可被及时发现。仓库的 Logging_Cheat_Sheet.drawio 提供了日志架构图可辅助理解日志链路设计。

C10. Handle All Errors and Exceptions：安全处理错误与异常

C10 要求错误处理既不泄露内部信息，又能为安全团队提供可用的诊断线索。映射文档：

Error Handling Cheat Sheet
REST Security Cheat Sheet（Error Handling 小节）

核心原则：面向用户的错误信息应通用且克制（如"请求无效"），绝不向客户端暴露堆栈跟踪、SQL 语句、文件路径、依赖版本等内部细节；面向内部的完整错误细节（含异常堆栈）应写入仅授权人员可访问的日志，并与 C9 的日志体系打通；对所有可能失败的路径（文件 IO、网络、数据库、第三方 API、解析与类型转换）统一进行异常捕获与降级处理，避免因未捕获异常导致信息泄露或可用性中断。仓库的 Error_Handling_Cheat_Sheet_Overview.png 提供了错误处理流程总览图，可用于团队培训与评审对照。

如何在本仓库中按控制查阅与维护

本仓库的映射索引 IndexProactiveControls.md 是唯一的"控制 → 文档"总入口。建议的查阅路径：

按 C1–C10 定位当前要落实的主动控制；
点击控制下对应的 Cheat Sheet 文档（全部位于 cheatsheets 目录），获取完整的防御方案、代码示例与配置清单；
对于文档中引用的资产（架构图、drawio 源文件、示例代码、PDF 参考资料），按根目录相对路径在 assets 目录中查找，例如 Error Handling 总览图、Clickjacking 嵌套框架示意图、滥用用例流程总览。

需要说明的适用前提：本文依据的索引面向 OWASP Top Ten Proactive Controls2018版本，各映射文档的具体建议以其各自文档中的版本与适用条件为准；部署与配置前请核对目标语言、框架与数据库的当前版本兼容性。仓库还提供了 GUIDELINE.md 与 CONTRIBUTING.md 说明 Cheat Sheet 的编写规范，若团队要为本项目补充新的安全速查表，可参照 New_CheatSheet 模板起步。

结语

OWASP Top Ten Proactive Controls 2018 的价值在于把"安全"从口号变成十条可执行、可排序、可检查的开发动作；而 IndexProactiveControls.md 则把这些动作与 CheatSheetSeries 仓库中数百页经过社区评审的实战文档一一对接。开发团队可以把 C1–C10 作为安全冲刺的验收清单，把本文列出的各映射文档作为每一项的详细操作手册，从而在 SDLC 的每一个阶段主动构筑防线，而不是等到生产环境被攻击后才被动补救。