5.4 KiB
5.4 KiB
4.3 安全编码规范 (防御性编程)
防御性编程的核心思想是：假设所有的外部输入都是恶意的，假设内部的依赖调用随时会失败。安全漏洞一旦在生产环境被利用，对业务和公司声誉的打击往往是毁灭性的。
本规范规定了团队在日常编码中必须遵守的安全底线。
4.3.1 常见 Web 漏洞防护底线
1. SQL 注入 (SQL Injection) 绝对防线
- 红线：绝对禁止使用字符串拼接（如 Python 的 f-string 或 %s，Java 的 +）来构造 SQL 语句。
- 规范：
- 默认必须使用框架提供的 ORM 工具（如 Django ORM, SQLAlchemy, MyBatis 动态标签）。
- 如果极其特殊的复杂查询必须执行原生 SQL，必须使用参数化查询（Parameterized Queries），将变量作为参数安全传递给数据库驱动。
2. 跨站脚本攻击 (XSS - Cross-Site Scripting) 防护
- 输入校验：在后端接口层（如 DRF Serializer 或 Pydantic）必须严格校验输入数据的格式与长度。
- 输出转义：
- 现代前端框架（Vue/React）默认防范了 DOM 型 XSS，但如果后端需要渲染模板（如 Django Template），严禁滥用 |safe 过滤器。
- 富文本处理：如果业务确实需要接收和展示用户提交的 HTML 富文本，后端在入库前必须使用白名单过滤库（如 Python 的 bleach，Java 的 OWASP Java HTML Sanitizer）对危险标签（如 <script>, <iframe>, onload）进行清洗。
3. 跨站请求伪造 (CSRF) 防护
- 无状态 Token 场景（如 JWT）：客户端将 Token 存放在 localStorage 并通过 Header (如 Authorization: Bearer) 发送时，天然免疫 CSRF，无需额外配置。
- Cookie 鉴权场景：如果项目使用 Cookie 存放 Session ID 或 Token：
- 必须为 Cookie 设置 HttpOnly=True（防止 XSS 窃取）和 SameSite=Lax 或 Strict（防止 CSRF 跨站携带）。
- 涉及状态修改的接口（POST/PUT/DELETE），必须开启并验证 CSRF Token。
4.3.2 敏感数据处理规范 (数据安全红线)
敏感数据（如用户密码、手机号、身份证号、银行卡号、支付凭证）的生命周期必须受到极其严格的管控。
1. 传输层加密
- 规范：生产环境的所有 API 请求、后台管理系统访问，强制使用 HTTPS (TLS 1.2 及以上版本)。绝对禁止敏感数据在公网明文传输。
2. 密码存储红线
- 红线：任何情况下，绝对禁止以明文形式存储用户密码。
- 规范：
- 密码必须使用强单向哈希算法（如 Bcrypt, Argon2，或 Django 默认的 PBKDF2）进行加密存储。
- 禁止使用 MD5 或 SHA1 作为密码的哈希算法（极其容易被彩虹表破解）。
- 加密过程必须加盐（Salt），且每个用户的盐值必须随机且唯一。
3. PII (个人身份信息) 的存储与加密
- 需解密还原的数据（如业务人员需要查看真实手机号、发货地址）：必须使用强大的对称加密算法（如 AES-256-GCM）进行落地加密（Encryption at Rest），且加密密钥（KMS）必须与数据库物理隔离。
- 无需解密的数据（如仅用于用户登录匹配的手机号）：建议直接使用带盐哈希存储，业务逻辑只做哈希比对。
4. 数据展示与脱敏 (Data Masking)
- 红线：前端展示所需的数据脱敏，必须在后端完成！绝对禁止后端返回完整明文数据，依靠前端代码去隐藏或打星号。
- 规范：通过 API 返回给用户终端的敏感信息，必须提前进行掩码截断。
- 手机号：138****1234
- 身份证：110105********1234
- 银行卡：**** **** **** 1234
- 姓名：张*三 或 *三
5. 日志安全红线
- 红线：日志中绝对禁止打印明文密码、鉴权 Token、完整的银行卡号/CVV 码、加密密钥。
- 规范：在全局中间件或切面（AOP）记录请求和响应日志时，必须配置敏感字段过滤规则。如果请求体中包含 "password": "xxx"，写入日志时必须替换为 "password": "***"。
4.3.3 业务安全与防暴破机制
- 水平越权防护 (IDOR/BOLA)：
- 永远不要相信用户提交的资源 ID。在修改或删除任何记录（如 POST /orders/123/cancel）时，除了判断 ID 存在，必须在数据库查询层面加上归属校验（如 WHERE order_id=123 AND user_id={当前登录用户ID}）。(详见 3.2.7 数据隔离规范)。
- 接口防刷与限流 (Rate Limiting)：
- 对于发送短信验证码、注册、登录等极易被黑客利用进行暴力破解或“薅羊毛”的接口，必须在网关层或应用层配置频次限制（如同一 IP 每分钟最多 5 次，同一手机号每天最多 10 次）。
- 失败提示模糊化：
- 登录失败时，无论是因为“账号不存在”还是“密码错误”，统一定义返回：“账号或密码错误”。禁止明确告知攻击者账号是否存在，防止黑客进行“撞库”和账号枚举。
🤖 [附加] AI 助手执行协议 (AI Output Schema)
绝对红线：提供安全漏洞与架构越权的排查 Checklist。规定 AI 必须逐项回复检查结果（True/False），一旦发现违规必须输出重构后的安全代码。