网络安全实战第21期：一次完整的注入风险验证与记录

Week 3 收尾：一次完整的注入风险验证该怎么做、怎么记

网络安全实战 90 天 · Week 3 注入风险　|　难度 ★★★ 进阶　|　关键词：验证流程　只读判断　风险定级　修复建议　复现记录

这一周从原理讲到了绕过，最后要回答一个工程问题：给你一个接口，你按什么顺序查、查完怎么写、写的东西别人能不能照着复现。这篇是一次完整的走查记录，全程只读，目标是自己搭的靶场。

不是练 payload。payload 会过期，库版本一升就换写法。练的是判断链条：看到一个参数，能推出现在处在链条的哪一环、下一环需要什么证据、拿不到证据时该怎么记录。

说明本文所有操作均为自建靶场（本机容器中的 DVWA 与 SQLi-Labs）上的只读验证，用于练习判断与记录方法，不涉及任何真实业务系统。授权范围内的真实验证同样遵守「只读、最小影响」原则。

先找到一个确定会走数据库的查询入口，然后拿真假两个条件去撞，确认响应可区分。这一步一旦成立，后面的都是流水线。

bash

text 复制代码

id=1 AND 1=1      # 返回正常列表
id=1 AND 1=2      # 返回空

两条响应不同，说明条件被代入执行了。接着确定结构：先数有几列，再确认哪几列的内容会被打回页面，然后才能把查询结果拼进去。

bash

text 复制代码

id=1 UNION SELECT version(),database()
id=1 UNION SELECT user(),2
id=1 UNION SELECT schema_name,2 FROM information_schema.schemata

三条请求分别取到了数据库版本、当前库、数据库账号标识和库名列表。这些是「摸结构」阶段的产出，属于只读信息，不涉及任何业务数据。

定量是定级的依据，也是最容易越界的地方。做法是先把范围收窄到一张表，确认能读到列名，再取一行样本说明字段含义------不需要、也不应该把整表拉下来。

只读原则 整个过程没有写入、更新、删除任何记录，也没有在服务器上生成文件。验证到「能读到不应读到的数据」这一点就足够定级；继续扩大范围只会增加风险，不会增加结论。

记录的价值等于它的可复现性。一份合格的记录至少回答五个问题：在哪、什么条件、怎么判断的、影响多大、有没有被挡住。

定级之后最容易敷衍的一步是修复建议。写「请加强输入校验」等于没写。有效的建议必须指明改哪里、怎么改、为什么这样改有效。

优先级	改什么	怎么改	为什么有效
P0	查询构造方式	参数化预编译，变量走绑定	语法与数据分离，输入无法改变语句结构
P0	参数类型	入参强制转换并校验范围	数字型入口不接受表达式
P1	数据库账号	只授予该业务必需的读权限	即使注入成立，影响半径也被压缩
P1	错误与文件能力	关闭详细报错，禁用文件读写能力	减少回显位，掐断写入落地路径
P2	检测与告警	对高频同源相似请求设阈值	盲注类行为必然高频，可被识别

注入这一层过了之后，下一周进入文件相关的风险面：上传、包含、以及「上传成功之后它到底落在哪」这个最容易被忽略的问题。

全部验证均在本机自建靶场完成，遵循只读与最小影响原则。真实环境中的任何验证都必须先获得书面授权，并严格控制在授权范围内。