最近一直在学习 SQL 相关知识。
从数据库、SELECT、WHERE、ORDER BY、LIMIT，到最近刚学的 UNION。
原本以为离 SQL 注入已经很近了。
结果真正开始研究 SQL 注入原理时才发现：很多人学不会 SQL 注入。
并不是因为它难。
而是因为从来没有真正理解：SQL 注入到底是怎么产生的
今天就结合自己的学习过程，聊聊我最近最大的收获。
一、我以前对 SQL 注入有个误解
刚开始接触 Web 安全的时候，我一直觉得 SQL 注入特别神秘。
网上经常能看到：
- 联合查询
- 报错注入
- 布尔盲注
- 时间盲注
各种专业名词。
给人的感觉好像是：掌握很多特殊技巧=学会 SQL 注入
后来才发现，这些其实都属于后面的内容。
SQL 注入最核心的问题只有一句话：用户输入改变了 SQL 语句原本的逻辑
二、登录功能让我第一次理解 SQL 注入
先看一个非常常见的场景，用户登录网站。
输入：
用户名：admin
密码：123456
服务器收到之后。
可能会拼接出这样的 SQL：
SELECT * FROM users WHERE username='admin' AND password='123456';
数据库执行这条语句。
如果查到数据 登录成功。
如果查不到 登录失败。
整个流程看起来非常正常。
三、问题出在哪里？
问题其实出在：用户输入
因为：用户名和密码并不是程序自己写死的，而是来自用户。
服务器通常会把用户输入的数据拼接到 SQL 语句中。
于是：
这个过程就产生了风险。
四、我终于理解什么叫“改变 SQL 结构”
以前我总觉得：输入就是输入怎么可能影响数据库？
后来学习过程中突然意识到，数据库看到的并不是：用户名
而是：完整 SQL 语句
例如，开发者原本希望数据库执行：
SELECT *FROM users WHERE username='admin';
但如果用户输入的数据参与了 SQL 拼接。
那么最终数据库执行的内容就可能发生变化。
这时候我第一次意识到：数据库并不关心数据是谁输入的它只负责执行收到的 SQL。
五、我发现 SQL 注入和 XSS 特别像
学到这里的时候。
我突然想起之前学习的 XSS。
两者本质其实很接近。
都是：
用户输入影响了系统原本的执行逻辑只是影响的对象不同。
一个是浏览器。
一个是数据库。
六、为什么开发者容易忽略这个问题？
因为开发者通常会站在正常用户的角度思考。
例如：
用户名应该是：admin
密码应该是：123456
于是写程序的时候，往往会默认：
用户会正常输入
但现实情况是：服务器永远无法保证用户输入什么。
输入框里的内容。
可以是：
- 数字
- 字母
- 特殊符号
- 超长字符串
甚至完全超出开发者预期。
所以安全问题往往就出现在这里。
七、我开始发现漏洞之间其实有共同点
学到这里的时候。
很多以前学过的内容突然串起来了。
| XSS | 文件上传 | 文件包含 | SQL 注入 |
| 用户输入 | 用户上传 | 用户控制路径 | 用户输入 |
| ↓ | ↓ | ↓ | ↓ |
| 浏览器执行 | 服务器处理 | 服务器读取文件 | 数据库执行 |
它们虽然名字不同。
但核心思路其实都差不多：
用户可控数据
影响了系统行为
这也是我最近最大的认知变化。
八、为什么我现在不急着学盲注
以前看到：
- 时间盲注
- 布尔盲注
- 报错注入
特别想直接学，现在反而不着急了。
因为我越来越发现：如果不知道 SQL 注入为什么产生。
后面那些技巧很容易变成：背 payload 而不是理解原理。
真正重要的是先理解：
用户输入
↓
SQL拼接
↓
数据库执行
这个过程。
九、我接下来的学习计划
目前准备继续学习：
- 联合查询原理
- 查询结构分析
- 联合查询注入
- 报错注入
- 布尔盲注
- 时间盲注
希望通过一步一步学习。
真正把 SQL 注入背后的逻辑搞懂。
而不是停留在记命令和记技巧阶段。
十、总结
刚开始学习 SQL 注入的时候。
我一直觉得它是一种很复杂的漏洞。
真正开始研究原理之后才发现。
它最核心的问题其实非常简单：用户输入影响了数据库原本想执行的逻辑而后面各种注入技巧。
本质上都是围绕这个核心问题展开的。
对于新手来说。
比起急着背各种 payload。
更重要的是先弄明白：数据库为什么会执行这些内容
因为只有理解原理，后面的知识才能真正串起来。
