代码审计里的授权与范围:六个检查点
所有测试流量要能按时间与源 IP 从日志里捞出来,这是自证清白的唯一方式
正着读代码容易漏,因为入口太多;反着找危险点,数据流只有那么几条。
先说结论
先列危险点,再回溯入口,最后确认校验与权限。
- 检查点一:所有外部入口是否都过统一校验
- 检查点二:危险函数是否集中封装
- 检查点三:校验是否只做一次、是否白名单
- 检查点四:权限判断是否在服务端
- 检查点五:错误信息是否泄露内部细节
- 检查点六:是否有兜底日志
检查点一:入口
测试窗口与限速要提前约定,扫描把生产库拖垮是这类项目最常见的事故,比漏洞本身更贵,限速要写进文档。
把入口列全:HTTP 参数、请求头、上传、消息队列、定时任务的外部输入。漏一个就白审。
检查点二:危险点
发现真实入侵痕迹时应立即停止并通报,继续测试会破坏现场的取证条件,证据链断掉就说不清,先保住现场。
| 类型 | 关键词 | 关注点 |
|---|---|---|
| 拼接 | SQL/命令/模板拼接 | 是否参数化 |
| 解析 | XML/JSON/反序列化 | 是否禁用外部实体 |
| 执行 | eval/system/exec | 是否可达 |
| 路径 | 文件读写、包含 | 是否规范化后校验 |
检查点三:校验逻辑
第三方托管的系统需要托管方单独授权,客户点头不等于你可以直接测,托管合同是另一回事,这条最常被忽略。
看到「先替换再校验」「只在一个接口校验」这两种写法,基本可以直接标红。

这个问题的几个审计细节
实际代码里最容易漏的几处:
- 所有测试流量要能按时间与源 IP 从日志里捞出来,这是自证清白的唯一方式
检查点四到六
所有测试流量要能按时间与源 IP 从日志里捞出来,这是自证清白的唯一方式。
越权是审计里性价比最高的方向:少一行判断,就是一个中高危。错误信息要统一,日志要记入口摘要。
再补充几点
这几条不改变结论,但会改变你评估风险时的顺序。
- 授权书要写到具体域名与 IP 段,只写「贵公司系统」在出事后没有任何效力
- 范围之外的资产哪怕只访问了一个首页,也已经构成越界,测试前把清单打印出来逐条确认
- 拿着口头同意就开扫,事后没人认这笔账
- 顺手测了同集团另一个域名,被判定为越界
- 把生产数据导出来当测试样本,离开授权范围
审计的产出不是「找到几个洞」,是「知道这类洞在哪个模式里反复出现」。
评论 (3)
补一句:修完要回归,很多人修一半。
终于有人讲清楚「为什么」而不是只给命令。
防御那节写得克制,没有教人打站,这点好评。
发表评论