72 lines
5.2 KiB
Markdown
72 lines
5.2 KiB
Markdown
|
# **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 次）。
|
|||
|
|
* **失败提示模糊化**：
|
|||
|
|
* 登录失败时，无论是因为“账号不存在”还是“密码错误”，**统一定义返回**：“账号或密码错误”。禁止明确告知攻击者账号是否存在，防止黑客进行“撞库”和账号枚举。
|