1. SQL注入基础：从入门到理解
大家好，我是老周。做安全这块十几年了，SQL注入算是我最早接触的漏洞之一。说实话，这玩意儿虽然经典，但直到今天依然活跃在各大漏洞报告中。今天咱们就来聊聊SQL注入的那些事儿。
1.1 什么是SQL注入
SQL注入，说白了就是攻击者把恶意的SQL代码塞进输入框，骗过数据库执行。你想想看，本来你写的是查询语句，结果被拼接成了删除语句——这谁顶得住？
核心定义：SQL注入是指攻击者通过构造特殊的输入，改变后端SQL语句的语义，从而执行非预期的数据库操作。
举个最简单的例子。一个登录页面，用户输入用户名和密码。后端代码可能是这样写的：
String sql = "SELECT * FROM users WHERE username='" + username + "' AND password='" + password + "'";如果用户输入的用户名是 admin' --，密码随便填。你猜会发生什么？
SELECT * FROM users WHERE username='admin' --' AND password='随便填'看到没？-- 把后面的密码验证直接注释掉了。这就是最经典的SQL注入。我在项目中遇到过不少新手，觉得这种写法没问题，结果上线第一天就被搞了。
1.2 SQL注入的危害
很多人觉得SQL注入不就是查个数据吗？能有多大危害？我告诉你，这玩意儿能造成的破坏，比你想象的要严重得多。
| 危害类型 | 具体表现 | 真实案例 |
|---|---|---|
| 数据泄露 | 拖库、脱裤，用户信息全暴露 | 某社交平台5亿用户数据被窃 |
| 数据篡改 | 修改、删除数据库内容 | 某电商网站商品价格被改 |
| 权限提升 | 从普通用户变成管理员 | 某后台系统被拿下管理员权限 |
| 服务器沦陷 | 通过数据库执行系统命令 | 某公司内网被横向渗透 |
⚠️ 注意：我曾经见过一个案例，攻击者通过SQL注入拿到了数据库的写权限，然后写入了WebShell，最后整个服务器都被控制了。所以千万别小看任何一个注入点。
1.3 SQL注入的分类
根据数据传入的方式，SQL注入主要分为三类。我习惯按请求方式来区分，这样在实际测试中更容易定位。
1.3.1 GET型注入
最常见的一种。参数直接挂在URL后面，比如：
http://example.com/user.php?id=1攻击者直接在浏览器地址栏改参数就行。我记得刚开始学渗透时，第一个练手的就是GET型注入，因为太直观了。
1.3.2 POST型注入
参数放在请求体里，不会显示在URL中。常见于登录、搜索等表单提交场景。
POST /login.php HTTP/1.1
Host: example.com
Content-Type: application/x-www-form-urlencoded
username=admin' --&password=123456这种比GET型稍微隐蔽一点，但本质上没区别。用Burp Suite抓个包就能看到。
1.3.3 Cookie型注入
这个就有点意思了。参数放在Cookie里，很多新手容易忽略。比如：
Cookie: user=admin' OR '1'='1为什么会有这种？有些网站会把用户信息存在Cookie里，后端直接拼接查询。我在一次众测中就遇到过，对方把用户ID放在Cookie里，结果被我一把梭了。
1.4 SQL注入的常见场景
说了这么多，到底哪些地方容易出问题？我总结了几类高频场景：
- 登录页面：用户名、密码框直接拼接SQL，经典中的经典
- 搜索功能：关键词搜索，尤其是模糊查询，容易出问题
- 商品详情页：通过ID查询商品，参数没过滤
- 用户信息修改：更新操作，注入点往往在WHERE条件里
- 导出/下载功能：文件名或ID参数，容易被利用
💡 个人经验：我一般先看URL里有没有明显的数字或字符串参数，比如 id=、page=、cat= 这些。然后抓包看POST参数和Cookie。嗯，基本上80%的注入点都能找到。
1.5 知识体系总览
下面这张图是我自己画的，把SQL注入的基础知识串起来了。你一看就明白。
这张图把SQL注入的四个核心维度串起来了。你从中心往外看，先理解定义，再看危害，然后掌握分类，最后落实到场景。嗯，这样学起来会清晰很多。
💡 避坑指南：我曾经在测试一个老系统时，发现所有GET参数都过滤了，但Cookie里的user_id没过滤。结果一测就中。所以记住——任何用户可控的输入点，都可能是注入点。
好了，这一章的内容就到这里。SQL注入的基础概念、危害、分类和场景，咱们都过了一遍。下一章我会带你实战，用SQLMap去检测这些注入点。到时候你就知道，理论知识怎么落地了。
公众号:蓝海资料掘金营，微信deep3321