文章目录
-
- 一、注入到底是什么病
- 二、入门前先搭对练习场
- 三、手工注入：你得先会“证明它存在”
-
- 1. 找候选点
- 2. 制造“语法异常”
- 3. 判断是数字型还是字符型
- 4. 布尔盲注：用真假问问题
- 5. 时间盲注：页面完全一样时
- 6. 报错注入：数据库肯说话时
- 7. Union 注入：能拼结果集时
- 8. 别只会 SELECT
- 四、手工阶段的“熟练”标准
- 五、sqlmap：自动化该怎么用才像老手
-
- 1. 使用前的纪律
- 2. 最小而有效的用法思路
- 3. 和代理配合
- 4. 速度与隐蔽
- 5. sqlmap 不是全能神
- 六、进阶：你会在真实项目里撞上的硬骨头
-
- 二阶注入
- 订单字段 / 列名注入
- LIMIT / 翻页 / 排序组合
- 存储过程与动态 SQL
- ORM 并不自动等于安全
- 读写分离与权限
- 七、防御：怎样才算“修好了”
-
- 1. 参数化是主药
- 2. 白名单处理结构型输入
- 3. 最小权限
- 4. WAF 是辅药
- 5. 安全测试要进 CI / 发布清单
- 6. 日志与监控
- 八、给开发的“代码评审口头禅”
- 九、给授权测试同学的报告写法
- 十、一条建议的学习路线（真正能精通的那种）
- 十一、收尾
先说一句扫兴的：如果你是想拿这篇去扫公网捡鱼，停一下。SQL 注入相关技术只适合你拥有授权的系统、自己的靶场、合同范围内的渗透测试。未授权对他人系统做注入，在绝大多数地区都是违法的——这篇按《网络安全实战》的写法，默认读者是开发、测试、蓝队和授权打手。
再说一句更扫兴的：SQL 注入明明“过时”了十几年，怎么还在打穿系统？因为业务总有“临时拼一下”的报表、导出、高级搜索、老项目、存储过程、以及那个“框架能防，所以我这里例外”的人。
我写这篇，不想写成字典式的 payload 大全。更想带你走一条真实学习路径：先看懂注入为什么成立 → 手工把洞证出来 → 再用 sqlmap 加速与减少遗漏 → 最后知道怎么改代码、怎么做回归，让洞真正消失。 “精通”不是背两百条绕过，是看见代码就知道危不危险，看见请求就知道怎么验证，看见修复就知道可不可信。
一、注入到底是什么病
把 SQL 想成你跟数据库说的一句话。正常情况是：
请给我 user_id = 当前登录用户 的订单。
一旦应用这么写（示意）：
"SELECT * FROM orders WHERE id = " + userInput
用户输入就不再只是“数据”，而可能改写这句话的语法。比如输入里带上注释、条件、联合查询，语义就变了。
所以注入的本质就一句：
不可信输入，进入了 SQL 语句的结构，而不是仅仅进入了值的位置。
预编译 / 参数化绑定之所以是解药，是因为它强制“结构”和“值”分离：值再怎么花，也成不了新的 SQL 语法。
二、入门前先搭对练习场
别一上来打真实客户系统练手。建议：
- DVWA、sqli-labs、自建的故意脆弱 Demo；
- 本地 MySQL/PostgreSQL/MSSQL 任一即可；
- 浏览器 + 代理（Burp / 同类）看请求；
- 授权测试时再换成客户环境，并明确范围。
有代理很重要。很多“注入点”藏在 JSON 字段、Cookie、二次提交、HTTP 头里，页面上看不见。
另外请记住数据库方言差异：MySQL、PostgreSQL、MSSQL、Oracle 的报错信息、字符串拼接、布尔盲注函数都不一样。精通的人先认库，再选手法。
三、手工注入：你得先会“证明它存在”
工具会撒谎，也会漏报。手工的价值是建立直觉。
1. 找候选点
优先怀疑：
- 登录框（有时是注入，有时只是弱口令，别混）；
- 列表筛选、排序字段、id=、order=、search=；
- 导出 Excel / 报表；
- 旧接口、移动端 API、管理端“高级查询”。
看请求里哪些参数最终可能进了 SQL。黑盒阶段靠猜与试；白盒阶段直接搜字符串拼接。
2. 制造“语法异常”
最经典的试探仍是加单引号、双引号、括号，让语句变得不完整。若页面从“正常列表”变成“数据库报错”或“异常 500”，你就找到了一根线头。
但现在很多系统关了详细报错，只给你一句“系统繁忙”。于是要会看：
- 响应长度变了吗？
- 响应时间变了吗？
- 结果集条数变了吗？
这就是盲注思维的起点：没有报错，不代表没有注入。
3. 判断是数字型还是字符型
粗线条理解：
- 数字型：原语句可能是 WHERE id = 7，你输入的是数字位置；
- 字符型：原语句可能是 WHERE name = 'admin'，你要考虑引号闭合。
判断准了，后面的闭合方式才不瞎碰。
4. 布尔盲注：用真假问问题
思路是构造永远为真 / 永远为假的条件，观察页面差异。例如（概念上）让条件变成“原条件 AND 1=1”与“AND 1=2”。若两种输入对应两种页面，你就拥有了一位信息的信道——然后可以一位一位问出库名、表名。慢，但稳。
手工做布尔盲注很磨人，所以这一步重在确认洞在、理解回显通道；大规模抠数据留给自动化。
5. 时间盲注：页面完全一样时
若真假页面毫无差别，可借助数据库睡眠类函数（各库名字不同）让“条件为真时更慢”。用时间当信号。 注意：网络抖动会骗人，要多次测，别一次超时就下结论。
6. 报错注入：数据库肯说话时
有些环境会把 SQL 异常直接吐到页面或接口 JSON 里。那是手工的天堂，也是开发的地狱。利用报错把信息“挤”进异常文本——具体函数因库而异，学的时候按你靶场的库去查文档，别死记一套通杀。
7. Union 注入：能拼结果集时
当结果会直接显示在页面上，联合查询可以把其它表的数据拼进结果集。关键步骤通常是：判断列数、找到回显列、再查询元数据（表名列名）与业务表。
列数可用 ORDER BY 递增到报错来估（老手法），或用 UNION 试。现代防护与模板渲染可能让回显很难看，但逻辑仍是那套。
8. 别只会 SELECT
写权限若很宽，注入的危害会从“拖库”变成“改数据、写文件、提权”——取决于数据库账号权限与组件。所以修洞时不要只说“防注入”，还要问：数据库账号是不是权限过大？
四、手工阶段的“熟练”标准
我觉得够格叫“入门到手熟”，至少能做到：
至于把整库导出来——在授权测试里有时需要证明影响，更多时候点到为止 + 出报告更专业。别把客户库当练习册狂拖。
五、sqlmap：自动化该怎么用才像老手
sqlmap 是授权测试里几乎人人会摸的工具。它强在：技巧覆盖面广、指纹识别、取数据流程化。 它也蠢在：参数乱扫、目标乱填时，你会对生产打出一堆睡眠请求，然后业务说数据库怎么卡死了。
1. 使用前的纪律
- 确认书面授权与范围；
- 先 staging / 测试环境；
- 生产若必须测，控制线程、去掉极具破坏性的选项、避开高峰；
- 能手工确认的点，再交给 sqlmap 深挖，减少误伤。
2. 最小而有效的用法思路
把请求交给它：URL、POST 体、Cookie、或从代理导出的 request 文件。 指定参数，而不是一上来全自动乱撞所有参数。
常见能力（概念层面，具体参数以你安装版 sqlmap -h 为准）：
- 探测技术类型（布尔、时间、UNION……）；
- 识别数据库类型与版本；
- 列举库表列；
- 按条件取数；
- 风险与级别开关（越高越激进）。
老手一般这样走：
先低攻击性探测 → 确认可注入
→ 查当前库/当前用户权限
→ 证明可读取敏感表的少量样例
→ 收工写报告
而不是默认“全库 dump”。
3. 和代理配合
复杂请求（多头部、JSON、CSRF token）用“原始请求文件”丢给 sqlmap，比在命令行里一点点拼更少出错。Token 会过期的，要注意刷新。
4. 速度与隐蔽
线程加得很猛，等于给自己报信：DBA 先发现异常，安全部还没出报告。 授权测试里，稳比快重要；需要时再逐步提高。某些环境还有 WAF，工具被拦不等于没洞，可能要回到手工换通道——但绕过 WAF 的细节不应写成“教你偷摸打生产”的菜谱；在授权范围内、以验证风险为目的去做，并优先推动修复与规则调优。
5. sqlmap 不是全能神
它可能漏：
- 很深的二阶注入（先存后触发）；
- 强定制 ORM 下奇特的拼接位置；
- 必须特定业务步骤才拼出的 SQL；
- 权限极低只能看极少视图的场景。
所以我才说：手工负责“发现与理解”，工具负责“加速与减少机械劳动”。两者缺一，都会在某天丢人。
六、进阶：你会在真实项目里撞上的硬骨头
二阶注入
输入时看起来没事，入库后在另一处拼接查询时爆炸。测试要覆盖“写进去再读出来”的路径，比如改昵称后管理端搜索昵称。
订单字段 / 列名注入
ORDER BY 后面跟列名，参数化不好直接套。常见修法是白名单映射：前端传 created / price，后端翻译成真正列名，绝不把用户字符串直接拼进 ORDER BY。
LIMIT / 翻页 / 排序组合
翻页参数也能出问题。一律校验为整数，或白名单。
存储过程与动态 SQL
数据库里用字符串拼 SQL，同样危险。权限上让应用账号不能乱动态拼。
ORM 并不自动等于安全
ORM 大多数 API 安全，但 raw query、字符串拼 fragment、某些 order(userInput) 仍会翻车。代码审计时搜 raw、execute(、字符串加号拼 SQL。
读写分离与权限
即使注入得手，若账号只有单库只读，危害可被限制。这是防御纵深，不是借口不修注入。
七、防御：怎样才算“修好了”
1. 参数化是主药
各语言都有 prepared statement / 参数绑定。原则是：
SQL 模板固定，用户输入只当绑定值。
包括 INSERT/UPDATE/DELETE，不只是 SELECT。
2. 白名单处理结构型输入
表名、列名、排序方向、运算符，这些本来就不是“值”，绑参绑不了，必须用白名单。
3. 最小权限
应用连接库的账号：不要 DBA；不要随意 FILE；不要跨到无关库。出事时少哭一会儿。
4. WAF 是辅药
WAF 能挡一批脚本小子，拦不住细心构造与业务定制注入。被 WAF 挡住 ≠ 代码安全。 真正通关看代码与测试。
5. 安全测试要进 CI / 发布清单
- 代码扫描找拼接；
- 对历史注入点留回归请求包；
- 依赖与框架升级（有时驱动层也有洞）。
6. 日志与监控
短时间大量 SQL 错误、异常长查询、睡眠函数特征（若可在 DB 侧审计）、导出接口疯狂访问——这些能给蓝队线索。别指望只靠 WAF 日志。
八、给开发的“代码评审口头禅”
评审遇到数据库访问，我就问四句：
四句都过得去，注入风险会少一大截。
九、给授权测试同学的报告写法
别只会贴 sqlmap 大截图。甲方开发恨这种报告。
写清楚：
- 漏洞位置（URL、参数、方法）；
- 类型（如布尔盲注）；
- 复现步骤（尽量最小 payload）；
- 证明（当前用户、版本、或样例数据一行，注意脱敏）；
- 影响（可读哪些数据、是否可写）；
- 修复建议（参数化示例、权限收敛）；
- 复测标准。
专业，比“拖了整库”更让人愿意请你第二次。
十、一条建议的学习路线（真正能精通的那种）
第 1 周 靶场上手工：报错、布尔、UNION，各打通一个。写下笔记：你怎么判断库类型的。
第 2 周 同一漏洞用 sqlmap 复现；对比手工与工具的差异；学会控制速度与范围。
第 3 周 读两段真实项目代码（或开源烂代码），找拼接；尝试写修复补丁与回归测试。
第 4 周 做二阶、ORDER BY、JSON 接口各一例；写一份完整测试报告模板。
之后就是积累：不同方言、不同框架、不同 WAF 环境。精通是年限与案例数，不是一篇文章的承诺——但路径可以很清楚。
十一、收尾
SQL 注入从入门到精通，中间那道坎其实不是“会不会用 sqlmap”，而是：
你有没有把问题看成工程缺陷：输入边界、查询构造、账号权限、测试门禁，而不是一串神秘 payload。
手工让你诚实，工具让你高效，修复让你对得起授权你测试的人。三者齐了，才配谈实战。
今晚如果你只做一件事：在靶场里不要开 sqlmap，手工确认一个布尔盲注点，写出“真假输入各自的现象”。 做完这件事，你对注入的理解，会比先跑三天工具扎实得多。
等你手工也能稳定证洞了，再让 sqlmap 替你打工——那时候，它才是工具，而你不是它的搬运工。
