SQLMap基础回顾:安装、基本用法与常用参数
说实话,很多人在SQL注入这条路上,都是从SQLMap开始的。我也不例外。
记得我第一次接触SQLMap,是在一个渗透测试项目里。客户给了个黑盒测试,我手动测了半天,头都大了。后来同事甩过来一句:「你试试SQLMap啊。」嗯,从那以后,我的渗透工具箱里就再也没缺过它。
这一章,咱们就把SQLMap的基础过一遍。别嫌简单,基础打不牢,后面绕WAF的时候你会哭的。
1. SQLMap的安装
SQLMap的安装其实没什么技术含量。它是个Python写的工具,所以前提是你得有Python环境。我个人习惯用Python 3.8以上版本,兼容性最好。
Windows下安装
# 下载SQLMap
git clone https://github.com/sqlmapproject/sqlmap.git
# 或者直接下载zip包解压
# 运行
python sqlmap.py -h
这里有个坑——我曾经在Windows上遇到过路径带中文导致报错的问题。所以建议你把SQLMap放在纯英文路径下,比如 C:\tools\sqlmap\。
Linux/Mac下安装
# 同样用git
git clone --depth 1 https://github.com/sqlmapproject/sqlmap.git sqlmap-dev
# 进入目录
cd sqlmap-dev
# 运行
python sqlmap.py -h
为什么用 --depth 1?因为只拉取最新版本,省时间省空间。你想想看,我们又不是要研究它的提交历史,对吧?
2. 基本用法
SQLMap的基本用法,说白了就是一句话:告诉它目标在哪,然后让它自己去跑。
最简单的命令长这样:
python sqlmap.py -u "http://example.com/page?id=1"
这条命令的意思是:对 http://example.com/page?id=1 这个URL进行注入检测。SQLMap会自动判断参数 id 是否存在注入点。
但实际项目中,哪有这么简单?
3. 常用参数详解
下面这几个参数,是我在实战中用得最多的。每一个都踩过坑,所以我会把经验一起告诉你。
-u 参数:指定目标URL
这是最基础的参数,指定你要测试的URL。注意,URL里必须包含一个可测试的参数,比如 ?id=1 或者 ?page=2&cat=3。
我曾经遇到过一个新手,他给了个 -u "http://example.com",然后问我为什么跑不出来。嗯,没有参数,SQLMap都不知道该测哪里。
--data 参数:POST请求的数据
很多网站用POST方式提交数据,这时候就需要 --data 了。
python sqlmap.py -u "http://example.com/login" --data "username=admin&password=123"
这里要注意:--data 里的参数名要和实际表单里的完全一致,大小写都不能错。我吃过这个亏,有一次因为参数名大小写不对,浪费了半小时。
--cookie 参数:带上身份认证
很多页面需要登录才能访问。这时候你得带上Cookie,不然SQLMap连页面都打不开。
python sqlmap.py -u "http://example.com/admin?id=1" --cookie "PHPSESSID=abc123; security_level=0"
--level 参数:检测深度
这个参数控制SQLMap的检测深度,取值范围是1到5。默认是1。
| level值 | 检测范围 | 适用场景 |
|---|---|---|
| 1 | GET和POST参数 | 快速扫描,日常使用 |
| 2 | 增加Cookie和User-Agent | 需要检测HTTP头注入时 |
| 3 | 增加Referer等头部 | 更全面的检测 |
| 4-5 | 几乎覆盖所有可能的注入点 | 深度测试,但速度很慢 |
我个人习惯:日常用 --level 2,因为很多WAF会在Cookie里做手脚。如果时间充裕,再上 --level 3。至于4和5,说实话,除非是特别重要的项目,否则我很少用——太慢了。
--risk 参数:风险等级
这个参数控制测试的「激进程度」,取值范围是1到3。默认是1。
- risk=1:只做最安全的测试,比如基于布尔的盲注和时间盲注。
- risk=2:增加一些中等风险的测试,比如报错注入。
- risk=3:使用更激进的注入方式,比如基于时间的
sleep()函数。
为什么要有这个参数?因为有些注入操作可能会对数据库造成影响,比如 DROP TABLE 之类的。你想想看,如果生产环境被你搞挂了,那后果...
--level 2 --risk 2 是日常标配。--level 3 --risk 1 是遇到WAF时的保守方案。--level 5 --risk 3 是最后的手段,而且我建议只在测试环境用。
4. 组合使用示例
光说参数没意思,咱们来一个实际点的例子。假设你要测试一个需要登录的POST接口:
python sqlmap.py -u "http://example.com/search" \
--data "keyword=test&page=1" \
--cookie "session=xyz789" \
--level 2 \
--risk 2
这条命令的意思是:
- 目标URL是
/search - 用POST方式提交
keyword和page两个参数 - 带上Cookie保持登录状态
- 检测深度为2,风险等级为2
嗯,这样配置,基本能覆盖90%的日常场景了。
5. 知识体系结构图
下面这张图,是我自己总结的SQLMap基础使用逻辑。你可以把它当作一个快速参考:
6. 避坑指南
最后,分享几个我踩过的坑,希望能帮你省点时间:
- 参数顺序不重要:SQLMap不关心你参数的顺序,但建议把
-u放在最前面,方便阅读。 - 不要同时跑多个实例:我曾经同时开了5个SQLMap窗口,结果网络被占满,一个都没跑出来。一个一个来,稳一点。
- 先确认目标可达:跑之前先用浏览器或者curl确认一下目标能正常访问。别像我一样,对着一个404页面跑了半小时。
- 日志要保存:加个
--output-dir=./result参数,把结果保存下来。方便复盘,也方便写报告。
好了,SQLMap的基础就这些。别看内容不多,但这些都是我实战中反复验证过的。下一章,咱们开始聊怎么用SQLMap绕过WAF,那才是真正有意思的部分。