安全编码规范与代码审计实战

// ❌ 直接使用用户输入
String path = request.getParameter("file");
Files.readAllBytes(Paths.get("/data/" + path));   // 路径穿越

// ✅ 白名单 + 服务端校验
if (!path.matches("[a-zA-Z0-9_.-]{1,64}")) { throw new BadRequest(); }
// 且用规范化的绝对路径，再检查前缀是否仍在白名单目录内

输入校验原则：
  · 白名单优先（能列举就不正则黑名单）
  · 校验放在服务端（前端校验只是体验）
  · 校验输入「语义」而非仅格式（长度、类型、取值范围、枚举值）
  · 统一用框架的校验注解/中间件，不散落在业务代码

凡是要渲染到 HTML / SQL / 系统命令 / JSON 的数据，
都必须按目标上下文做编码或参数化：

  HTML：  转义 < > & " '（防 XSS）
  SQL：   参数化/预编译（防注入）
  命令：  禁止拼接，用参数数组（防命令注入）
  JSON：  序列化时按框架默认安全转义
  日志：  换行符/敏感字段要处理（防日志注入）

· 进程/服务用最小权限账号跑，不 root
· 数据库账号只给业务库最小授权（见「数据库安全加固」专题）
· 敏感操作二次校验 + 审计留痕
· 防御不止一层：即便输入校验被绕过，下层还有编码/权限兜底

// Go：命令执行
cmd := exec.Command("sh", "-c", "rm "+arg)   // ❌
cmd := exec.Command("rm", arg)               // ✅ 参数数组

// Node：原型污染 / 命令注入
const opts = JSON.parse(userInput);          // ❌ 深合并会污染 __proto__
const out = execSync(`ls ${arg}`);           // ❌
const out = execFileSync('ls', [arg]);       // ✅

优先审计的代码：
  · 接收外部输入的第一层（HTTP handler / 消息消费 / 文件导入）
  · 调用系统命令、操作文件、执行 SQL、发起 HTTP 的代码
  · 处理反序列化 / XML / 模板渲染的代码
  · 鉴权、支付、上传、导出等高风险业务

核心思维：找「不可信数据（Source）」→ 流向「危险函数（Sink）」的路径

Source（不可信数据）：
  HTTP 参数 / 请求体 / Header / Cookie / 上传文件 / 外部 API 响应 / 消息队列

Sink（危险函数）：
  SQL 执行 / 系统命令 / 文件写 / 响应输出 / 反序列化 / 重定向 / 反射

审计动作：
  对每个 Source→Sink 路径，检查路径上是否有「校验/编码/参数化」。
  没有 → 漏洞；有但可绕过 → 漏洞。

① 工具预筛：SAST/SCA 先跑一遍，定位可疑点（减少人工盲扫）
② 人工重点：聚焦「用户输入 → 危险函数」的真实路径（工具误报多、漏报也多）
③ 业务理解：看懂代码的业务意图，才能判断「这个校验是否真的生效」
④ 深挖绕过：对每个校验问「参数化了吗 / 编码覆盖所有输出点了吗 / 校验可否被绕过」
⑤ 修复建议：给出最小改动方案，不只报漏洞

推荐组合：
  提交前：IDE 插件 + 提交钩子（快速拦截明显问题）
  流水线：SAST + SCA 门禁（强制阻断高危）
  重大变更：人工安全评审（merge 前）
  周期：全量人工抽审 + 重点模块深度审计

一份好的安全编码规范应该具备：
  · 按语言/框架给出「危险写法 ❌ / 安全写法 ✅」对照
  · 直接对应可用的 lint 规则（能机检的不靠自觉）
  · 与公司技术栈绑定（如 Spring + MyBatis 的具体写法）
  · 随漏洞复盘持续补充（每次事故 → 新增一条规范）

□ 所有用户输入在服务端做了白名单校验？
□ SQL/命令/模板全部参数化或编码？
□ 没有反序列化不可信数据？有则白名单过滤？
□ 上传文件做了类型/大小/内容校验并隔离存储？
□ 按 ID 查询的接口校验了数据归属？
□ 敏感数据（密码/Token）没有落日志/返前端？
□ 依赖已扫描无高危漏洞？许可证合规？
□ 错误信息没有向用户泄露堆栈/内部路径？