security-protocol

安全协议

概述

安全不是事后附加的一个阶段。每一行代码都是一项安全决策。

**核心原则：**绝不信任信任边界之外的数据。每次跨越边界时都要进行验证。

没有例外。没有变通方法。没有捷径。

首要原则

NO EXTERNAL DATA REACHES A SYSTEM CALL, QUERY, OR OUTPUT WITHOUT VALIDATION AND SANITIZATION

数据跨越信任边界时，必须先经过验证才能使用。这是绝对原则。

适用场景

编写以下代码时必须遵守：

• 接受用户输入（表单、URL、标头、上传的文件）
• 构造数据库查询
• 渲染用户提供的内容
• 管理身份验证或授权
• 处理机密信息或凭据
• 调用外部 API
• 操作文件路径
• 执行系统命令
• 设置 HTTP 响应标头
• 处理文件上传

**这不是可自行决定的。**安全意识应融入开发过程，而不是事后才应用。

入口协议

BEFORE shipping ANY code that handles external data:

1. IDENTIFY: Where does data enter the system? (Trust boundary)
2. VALIDATE: Is input validated at the boundary?
3. SANITIZE: Is output encoded for its target context?
4. AUTHORIZE: Is access control verified before the action?
5. PROTECT: Are secrets, tokens, and keys managed safely?

Omit any step = vulnerability shipped

OWASP Top 10 精简指南

A01：访问控制失效

每个端点都必须验证：这个用户能否对这个资源执行这个操作？

# VULNERABLE: Checks authentication but not authorization
GET /api/accounts/456/profile  # User 123 views user 456's private data

# SECURE: Verify resource ownership
if resource.owner_id != authenticated_user.id:
    return 403 Forbidden

验证项	方法
身份验证	用户是否确实是其声称的身份？
授权	是否允许此用户执行此操作？
资源所有权	此用户是否拥有此特定资源？
角色执行	在服务端检查角色；绝不信任客户端提供的角色声明

**默认策略：拒绝。**如果没有明确规则授予访问权限，则拒绝访问。

A02：加密失效

必须采用的做法	禁止的做法
使用 bcrypt/scrypt/argon2 哈希密码	使用 MD5、SHA1、SHA256 处理密码
全程使用 TLS（HTTPS）	对任何敏感内容使用 HTTP
使用密码学安全的随机数生成器生成令牌	使用 Math.random() 生成安全令牌
对静态存储的敏感数据进行加密	以明文存储敏感数据
使用成熟的加密库	自行实现加密算法

A03：注入

绝不将外部输入拼接到查询、命令或模板中。

注入类型	防范方法
SQL 注入	使用参数化查询／预处理语句。务必如此。
NoSQL 注入	检查输入类型；使用 ODM 查询构造器
命令注入	避免执行 shell 命令。如果无法避免：使用允许列表限制参数，绝不进行插值
LDAP 注入	转义特殊字符；使用参数化查询
模板注入	使用自动转义的模板引擎

-- VULNERABLE: String concatenation
SELECT * FROM users WHERE email = '" + userInput + "'

-- SECURE: Parameterized query
SELECT * FROM users WHERE email = $1

这是不可妥协的。任何情况下，都不能接受在查询中使用字符串拼接。

A04：不安全设计

• 对身份验证端点实施速率限制
• 创建账户时使用 CAPTCHA 或工作量证明
• 在服务端验证业务逻辑约束（绝不能仅在客户端验证）
• 针对滥用情形进行设计，而不只是针对预期用法

A05：安全配置错误

检查项	操作
默认凭据	部署前替换所有默认凭据
调试功能	在生产环境中禁用调试模式、管理控制台和详细错误信息
错误信息详细程度	绝不向用户暴露堆栈跟踪、SQL 错误或内部路径
目录列表	在所有 Web 服务器上禁用
安全标头	设置安全标头（参见“安全标头”部分）
CORS 策略	限定为特定来源；对于携带凭据的请求，绝不使用 *

A06：易受攻击的组件

BEFORE adding any dependency:

1. Is it actively maintained? (Last commit within 6 months)
2. Are known vulnerabilities published? (npm audit, snyk, dependabot)
3. Is it widely adopted? (Download counts and stars are signals, not guarantees)
4. Is it actually necessary? (Do not add a dependency for a single utility function)

定期执行 npm audit / pip audit / cargo audit。立即修复严重和高危问题。

A07：身份验证失败

要求	实现
密码存储	使用 bcrypt/scrypt/argon2，并为每个密码生成唯一盐值
会话令牌	使用经过加密安全处理的随机值，并设置 httpOnly、secure、sameSite 标志
暴力破解防护	连续失败 5-10 次后锁定账户
多因素身份验证	敏感应用至少支持 TOTP
密码策略	至少 8 个字符；与泄露数据库交叉比对
会话生命周期	设置会话过期时间；密码更改时使会话失效

A08：数据完整性失败

• 验证软件更新和 CI/CD 流水线的完整性
• 使用签名工件和校验和
• 切勿自动反序列化不可信数据（不要对用户输入使用 eval() 或 pickle.loads()）

A09：日志记录和监控失败

记录	切勿记录
身份验证尝试（成功和失败）	密码或身份验证令牌
授权拒绝	完整的信用卡号码
输入验证失败	未出于特定目的而记录的个人身份信息
系统错误	加密密钥或机密

A10：服务器端请求伪造（SSRF）

• 在发起服务器端请求前验证 URL 并将其加入允许列表
• 切勿允许用户控制服务器端抓取所用的 URL
• 阻止对内部网络的请求（169.254.x.x、10.x.x.x、127.x.x.x、192.168.x.x）

安全标头

在每个 HTTP 响应中设置以下标头：

Content-Security-Policy: default-src 'self'; script-src 'self'
X-Content-Type-Options: nosniff
X-Frame-Options: DENY
Strict-Transport-Security: max-age=31536000; includeSubDomains
Referrer-Policy: strict-origin-when-cross-origin
Permissions-Policy: camera=(), microphone=(), geolocation=()

先采用严格限制，仅在特定需求要求时才放宽。

机密管理

NEVER:
- Embed secrets in source code
- Commit .env files to version control
- Write secrets to log output
- Transmit secrets in URL query parameters
- Store secrets in client-side code

ALWAYS:
- Use environment variables or dedicated secret managers
- Add .env to .gitignore BEFORE the first commit
- Rotate secrets on a defined schedule
- Use distinct secrets per environment
- Audit secret access

输入验证检查清单

对于每个输入字段：

• 验证类型（字符串、数字、电子邮件、URL）
• 限制长度（最小值和最大值）
• 验证格式（对结构化数据使用正则表达式）
• 检查范围（数字、日期）
• 尽可能使用允许列表（枚举值、已知选项）
• 针对输出上下文进行净化（HTML、SQL、shell）
• 文件上传：通过检查内容而非扩展名来验证类型，并限制大小

认知陷阱

自我安慰	事实
“这是内部工具，没有攻击者”	内部工具也会遭到入侵。内部用户也会犯错。内部威胁确实存在。
“我们以后再加安全措施”	安全不是一项功能。事后补上安全措施的成本是从一开始就做好安全措施的 10 倍。
“框架会处理这些问题”	框架也有可绕过的机制。要确切了解框架会保护什么、不会保护什么。
“输入验证太过了”	历史上的每一次注入攻击都始于未经验证的输入。
“这只是一个原型”	原型会变成生产系统。从一开始就做好安全措施。
“太复杂了，会拖慢开发”	数据泄露会永久拖慢开发。
“没人会那么做”	攻击者恰恰会那么做。假设所有输入都带有恶意。

防护措施 -- 立即停止并修复

• 在 SQL 查询中拼接字符串
• 对用户提供的数据使用 eval() 或 exec()
• 在源代码或已提交的配置文件中存放机密
• 端点缺少授权检查
• 未经编码就呈现用户输入
• 在携带凭据时使用通配符 * CORS 策略
• 对涉及身份验证或敏感数据的任何内容使用 HTTP
• 仅进行客户端验证，没有对应的服务器端验证
• 禁用 CSRF 防护
• 在已部署的环境中使用默认凭据

此列表中的每一项都是安全漏洞。上线前必须修复。

集成

互补技能：

• godmode:system-design -- 身份验证策略和数据流设计
• godmode:quality-enforcement -- 将安全检查设为自动化质量门禁
• godmode:completion-gate -- 上线前进行安全验证
• godmode:test-first -- 编写以安全为重点的测试用例

总结

Trust boundary crossed -> validate input, sanitize output, verify authorization

没有例外。不要说“我们以后再加”。安全措施必须随代码一同交付，否则代码就不能交付。