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?因为只拉取最新版本,省时间省空间。你想想看,我们又不是要研究它的提交历史,对吧?

小提示: 我建议你把SQLMap加到环境变量里。这样在任何目录下都能直接调用,不用每次都cd到安装目录。

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"
警告: Cookie是有时效性的。我曾经在测试一个后台系统时,Cookie过期了,SQLMap跑出来的结果全是「目标不可达」。检查了半天才发现是Cookie失效了。所以,建议你在跑之前先确认Cookie是否有效。

--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方式提交 keywordpage 两个参数
  • 带上Cookie保持登录状态
  • 检测深度为2,风险等级为2

嗯,这样配置,基本能覆盖90%的日常场景了。

5. 知识体系结构图

下面这张图,是我自己总结的SQLMap基础使用逻辑。你可以把它当作一个快速参考:

SQLMap基础使用知识体系 安装 Windows / Linux / Mac 基本用法 -u 指定目标URL 常用参数 --data / --cookie 参数详解 --data POST数据提交 参数名需完全匹配 --cookie 身份认证 注意时效性 --level 检测深度 1-5 日常用 level 2 --risk 风险等级 1-3 生产环境慎用 risk 3 推荐组合:--level 2 --risk 2

6. 避坑指南

最后,分享几个我踩过的坑,希望能帮你省点时间:

  • 参数顺序不重要:SQLMap不关心你参数的顺序,但建议把 -u 放在最前面,方便阅读。
  • 不要同时跑多个实例:我曾经同时开了5个SQLMap窗口,结果网络被占满,一个都没跑出来。一个一个来,稳一点。
  • 先确认目标可达:跑之前先用浏览器或者curl确认一下目标能正常访问。别像我一样,对着一个404页面跑了半小时。
  • 日志要保存:加个 --output-dir=./result 参数,把结果保存下来。方便复盘,也方便写报告。

好了,SQLMap的基础就这些。别看内容不多,但这些都是我实战中反复验证过的。下一章,咱们开始聊怎么用SQLMap绕过WAF,那才是真正有意思的部分。


专注资料整理