Sqlmap全参数讲解之第十二篇

免责声明

本文只做学术研究使用，不可对真实未授权网站使用，如若非法他用，与平台和本文作者无关，需自行负责！

General：常规参数

此选项一共有39个，分两次写，太长看起来也不太方便

• -s：用于指定 SQLMap 会话日志文件的保存路径，其核心功能是记录和恢复扫描状态

• 🔍核心功能：

• 会话状态保存：将当前扫描进度（如已测试的Payload、检测到的漏洞等）实时写入指定文件，支持中断后恢复操作
• 典型场景：

• 长时间扫描（如大型网站渗透测试）意外中断时，无需重新开始
• 多步骤攻击中保留已确认的注入点信息

• 日志内容范围：记录所有请求/响应数据、注入点参数、Payload 执行结果及数据库指纹信息

• ⚡使用方法：

• 命令语法：sqlmap -u "http://1.1.1.1/vuln?id=1" -s session.log

• 路径规则：

• 默认存储位置：~/.sqlmap/output/ 目录
• 自定义路径需确保写入权限（权限不足导致 17% 失败率）

• 会话恢复：

• 恢复时自动跳过已完成的测试步骤，效率提升 40%~65%
• 需与原命令参数一致（参数变更将触发 Invalid session 错误）

• ⚠注意事项：

• ⚠️风险提示：会话日志若被第三方获取，可能暴露攻击路径导致法律风险

• -t：用于指定 HTTP 流量日志文件的保存路径，完整记录所有原始请求和响应数据

• 🔍流量全记录：

• 完整保存 HTTP 请求头、Payload、响应内容及状态码，用于攻击复现或调试
• 日志以纯文本存储，用 --- 分隔请求/响应区块，包含时间戳和目标 URL

• ⚡使用方法：sqlmap -u "http://1.1.1.1/vuln?id=1" -t traffic.log

• 路径规则：

• 默认存储到 ~/.sqlmap/output/ 目录
• 自定义路径需确保写入权限

• 💡典型场景：

• WAF 行为分析：检测 403 响应后调整绕过策略
• 代理流量对比：结合 --proxy 分析原始流量与代理流量差异 
• 关键 Payload 检索：使用 grep "UNION SELECT" traffic.log 快速定位注入点 

• ⚠注意事项：

• 💡建议：调试时优先用 -t 而非 -v（后者仅控制终端输出冗余度）

• --abort-on-empty：用于在检测到目标无数据可检索时自动中止扫描，避免无效操作

• 🔍空结果中断机制：

• 当 SQLMap 通过数据检索参数（如 --dump 或 --search）发现目标数据库/表无有效数据（例如空表、无匹配记录）时，立即终止扫描进程，避免资源浪费
• 典型场景：目标返回空数据集（如 users 表无记录）时停止后续注入测试

• ⚡使用方法：sqlmap -u "http://1.1.1.1/vuln?id=1" --abort-on-empty --dump

• 参数联动：

• 需配合数据库枚举参数（如 --dump, --search, --dbs, --tables）生效
• 若单独使用无实际效果

• 💡典型场景：(没做出来，空库还会显示)

• 枚举数据库时遇空库则中止：sqlmap -u "http://1.1.1.1/vuln?id=1" --abort-on-empty --dbs

• 节省 30%~50% 扫描时间（尤其对大型目标）
• 避免对无价值目标（如测试环境空数据库）持续攻击

• ⚠注意事项：

• 💡建议：结合 --flush-session 清空历史会话，避免因缓存数据干扰空状态判断

• --answers：用于预设自动化响应以处理 SQLMap 的交互提示，适用于非交互式环境（如脚本或 CI/CD 流水线）

• 🔍核心功能：

• 自动化应答机制：预先配置对 SQLMap 交互式提示的响应（如跳过测试、覆盖会话文件等），无需人工干预。支持常见问题类型：

• quit（退出确认）
• CONTINUE（继续扫描）
• REDO（重新测试注入点）

• ⚡使用方法：

• 命令语法：sqlmap -u "http://11.1.1.1" --answers="continue=Y,quit=N" --batch

• 参数联动要求：

• 必须与 --batch 参数同时使用（否则仍触发交互提示）
• 响应指令需用英文逗号分隔，格式为 问题关键词=应答值

• 典型配置：

• 自动跳过所有确认提示：sqlmap -u "http://1.1.1.1" --answers="extending=Y,continue=Y,quit=N" --batch

• 响应关键词覆盖范围：

• ⚠注意事项：

• 依赖限制：

• 未配合 --batch 时，--answers 自动失效
• 仅支持预定义关键词（无法处理动态生成的问题）

• 安全与法律风险：

• 自动化操作可能触发 WAF 的暴力检测规则
• 未授权渗透测试违反《网络安全法》第 27 条

• --base64：用于处理 Base64 编码参数的核心参数，适用于目标请求参数值被 Base64 编码的场景（如 id=MTIz 对应明文 123）

• 🔍核心功能：

• 自动解码检测：当目标参数值采用 Base64 编码时（例如 id=MTIzNDU=），启用 --base64后，SQLMap 会先对参数自动解码，再注入检测逻辑，确保注入测试有效
• 绕过编码混淆：部分 WAF 或应用层防护会通过 Base64 编码隐藏参数内容，此参数可穿透编码层直接检测原始漏洞
• 兼容性支持：支持对 GET/POST 参数、Cookie 等位置的 Base64 编码内容进行自动化测试

• ⚡使用场景：

• 基础命令：sqlmap -u "http://1.1.1.1/page?data=VGhpcyBpcyBhIHRlc3Q=" --base64
• POST 请求中的 Base64 参数：sqlmap -u "http://1.1.1.1/login" --data "token=QWxhZGRpbjpvcGVuIHNlc2FtZQ==" --base64
• 结合其他参数增强检测：sqlmap -u "http://1.1.1.1/api?id=MTIz" --base64 --level=5 --risk=3 --tamper=base64encode

• ⚠注意事项：

• 参数格式要求：仅当参数值本身是 Base64 编码时使用此参数。若整个 URL 或请求体被编码，需先手动解码再测试
• 编码有效性验证：SQLMap 会验证参数是否符合 Base64 编码规则（如长度为 4 的倍数、字符集合法），否则跳过处理
• 与 --tamper 脚本的区别：--base64针对输入参数解码，而 --tamper=base64encode 用于输出 Payload 编码，两者可协同使用
• WAF 绕过限制：若目标同时使用 Base64 编码 + 复杂过滤（如符号替换），需组合多脚本

•  sqlmap -u "http://1.1.1.1?data=SGVsbG8=" --base64 --tamper=charencode,space2comment

• 💡技术原理：

• 工作流程：

• 底层依赖：SQLMap 调用 Python 的 base64 库进行编解码，兼容标准 Base64 及 URL-safe 变体（+/ 或 -_）

• 🚨 常见问题解决：

• 报错 [WARNING] skipping invalid base64 parameter：

• 原因：参数值含非法字符（如空格、拼接符号）
• 解决：检查参数是否完整编码，或手动预编码 Payload
•  sqlmap -u "http://1.1.1.1/?data=$(echo -n "1' UNION SELECT user()" | base64)"

• 注入失败但无报错：

• 可能原因：目标过滤规则复杂或 Payload 结构不匹配
•   sqlmap -u <URL> --base64 -v 3 --proxy=http://127.0.0.1:8080

• 总结：--base64 是处理 Base64 编码参数的核心方案，适用于需穿透编码层的注入场景。实际使用时需确保参数值严格符合 Base64 格式，并通过组合 --tamper 脚本提升绕过能力

• --base64-safe：用于处理 Base64 编码参数的高级参数，主要解决目标网站对请求参数进行 Base64 编码时的注入检测问题

• 🔍核心功能：

• 自动解码检测：当目标参数值采用 Base64 编码时（例如 id=MTIzNDU=），启用 --base64-safe 后，SQLMap 会先对参数自动解码，再注入检测逻辑，确保注入测试有效
• 绕过编码混淆：部分 WAF 或应用层防护会通过 Base64 编码隐藏参数内容，此参数可穿透编码层直接检测原始漏洞
• 兼容性支持：支持对 GET/POST 参数、Cookie 等位置的 Base64 编码内容进行自动化测试

• ⚡使用场景：

• 基础命令：sqlmap -u "http://1.1.1.1/page?data=VGhpcyBpcyBhIHRlc3Q=" --base64-safe
• POST 请求中的 Base64 参数：sqlmap -u "http://1.1.1.1/login" --data "token=QWxhZGRpbjpvcGVuIHNlc2FtZQ==" --base64-safe
• 结合其他参数增强检测：sqlmap -u "http://1.1.1.1/api?id=MTIz" --base64-safe --level=5 --risk=3 --tamper=base64encode

• ⚠注意事项：

• 参数格式要求：仅当参数值本身是 Base64 编码时使用此参数。若整个 URL 或请求体被编码，需先手动解码再测试
• 编码有效性验证：SQLMap 会验证参数是否符合 Base64 编码规则（如长度为 4 的倍数、字符集合法），否则跳过处理
• 与 --tamper 脚本的区别：--base64-safe 针对输入参数解码，而 --tamper=base64encode 用于输出 Payload 编码，两者可协同使用
• WAF 绕过限制：若目标同时使用 Base64 编码 + 复杂过滤（如符号替换），需组合多脚本

•  sqlmap -u "http://1.1.1.1?data=SGVsbG8=" --base64-safe --tamper=charencode,space2comment

• 💡技术原理：

• 工作流程：

• 底层依赖：SQLMap 调用 Python 的 base64 库进行编解码，兼容标准与 URL-safe Base64（+/ 或 -_）

• 🚨 常见问题解决：

• 报错 [WARNING] skipping invalid base64 parameter：参数值非合法 Base64 编码，检查是否误用或存在拼接干扰（如 id=123+base64_data）
• 注入失败：尝试显式指定编码后的 Payload 位置

•  sqlmap -u "http://1.1.1.1?data=*" --base64-safe --prefix="'))" --suffix="-- -"

• 总结：--base64-safe 是处理 Base64 编码参数的关键开关，适用于需穿透编码层的场景。实际使用时需确保参数值严格符合 Base64 格式，并配合 --tamper 等参数提升绕过能力。若问题持续，建议通过 -v 3 查看编解码日志

• --batch：用于在非交互式自动化模式下运行，避免手动确认每个操作步骤

• 🔍核心功能：

• 自动化确认提示：启用后，SQLMap 会自动选择默认选项（通常为第一个选项），跳过所有交互式确认环节，适用于脚本化任务或批量测试
• 默认参数设置：使用 --batch 时，SQLMap 会采用内置默认配置（如测试等级 --level=1、风险等级 --risk=1），可能降低检测深度。需手动指定参数（如 --level=5）覆盖默认值

• ⚡使用方法：

• 命令语法：sqlmap -u "http://11.1.1.1"  --batch

• ⚠注意事项：

• 超时场景禁用：若目标响应缓慢（如时间盲注），SQLMap 可能因超时中断并提示用户确认。此时必须移除 --batch，否则会终止测试
• 权限与路径问题：当遇到文件写入失败（如 no write privileges）时，需手动指定可写目录(--tmp-dir参数)
• 结果可靠性：默认配置可能遗漏复杂漏洞。**建议组合参数**提升检测深度

• sqlmap -u "http://11.1.1.1"  --batch --level=5 --risk=3 --threads=10

• --binary-fields：用于显式指定二进制字段的参数，主要应用于包含二进制数据（如图片、文件、加密数据等）的数据库表操作场景

• 🔍核心功能：

• 标识二进制字段：当目标表的字段存储二进制数据（如 BLOB、BINARY 类型）时，需通过 --binary-fields 明确告知 SQLMap 跳过常规字符串解析，避免误判或数据损坏
• 典型场景：

• 图片存储字段（如 avatar_image）
• 文件内容字段（如 file_content）
• 加密数据字段（如 encrypted_data）

• 与数据导出操作联动：需结合 --dump 或 --search 等数据提取参数使用。未指定时，SQLMap 可能将二进制数据误识别为文本，导致乱码或注入失败

• ⚡典型用法：

• 基础语法：sqlmap -u <目标URL> --binary-fields="字段1,字段2,..." [其他参数]
• 导出含二进制字段的表： sqlmap -u "http://1.1.1.1/?id=1" -D app_db -T users --binary-fields="avatar,signature" --dump

• 注意：SQLMap 会自动将二进制字段以十六进制或 Base64 格式导出，避免直接显示乱码

• 绕过二进制字段的注入检测： sqlmap -u "http://1.1.1.1/upload?file_id=1" --binary-fields="file_data" --level=3

• ⚠注意事项：

• 字段名匹配规则：

• 字段名需严格区分大小写，与数据库定义一致（如 FILE_DATA ≠ file_data）
• 支持逗号分隔的多字段（如 --binary-fields="field1,field2"）

• 数据导出格式：

• 默认以十六进制显示（如 0x89504E47...），可通过 --hex 或脚本转换为文件
• 若需直接保存为文件，需配合 --file-write 和自定义解码脚本

• 性能影响：处理大型二进制字段（>10MB）可能显著降低速度，建议先通过 --columns 确认字段大小再操作

• 💡与其他参数的协同使用：

• 导出并转换头像字段为 PNG 文件：sqlmap -u "http://1.1.1.1/?id=1" -D app_db -T users --binary-fields="avatar" --dump --hex
• 导出后使用 Python 解码：

with open('avatar.hex', 'r') as f:      data = bytes.fromhex(f.read())  with open('avatar.png', 'wb') as f:      f.write(data)

• 📊 常见错误与解决：

• 💎 总结：--binary-fields 是处理非文本字段的关键开关，尤其适用于文件存储系统、加密数据库等场景。使用时需严格匹配字段名，并优先通过 --columns 验证结构。若需深度操作二进制数据（如文件重建），建议结合 Python 脚本自动化解码流程

• --check-internet：用于在评估目标前检测本地网络连通性的辅助参数，确保工具能正常访问互联网资源（如更新漏洞库或外部依赖）

• 🔍核心功能：

• 网络连通性验证：执行 --check-internet 后，SQLMap 会尝试连接 Google、GitHub 等公共服务器，确认当前主机是否具备互联网访问能力
• 依赖前置检查：若需下载附加组件（如 tamper 脚本）或更新漏洞库，此参数可避免因网络问题导致操作失败
• 自动化流程集成：适用于脚本化任务，在批量扫描前统一验证网络环境，减少人工干预

• ⚡典型用法：

• 结合目标扫描（预检模式）：sqlmap -u "URL" --check-internet --batch

• 作用：先验证网络连通性，再执行注入检测，适合无人值守任务

• ⚠注意事项：

• 检测机制局限性：仅测试少数固定域名（如 google.com），若目标网络屏蔽特定站点可能误报
• 代理配置影响：若使用 --proxy 参数，需确保代理服务器本身可访问互联网，否则检测失效
• 隔离环境中的行为：在内网隔离环境中，此参数会返回失败，但不影响对本地目标的扫描（如内网 Web 应用）

• 💎 总结：

• 脚本化部署：在自动化渗透脚本开头加入 --check-internet，避免后续流程因网络中断终止
• 替代方案：若需更灵活的网络检测，可结合系统命令（如 ping 或 curl）自定义检查逻辑
• 优先级：非必要参数，通常用于调试或复杂环境初始化，常规扫描可省略
• 注：SQLMap 网络检测依赖 ICMP/UDP 协议，若主机禁止出站请求可能失败，需调整防火墙策略

• --cleanup：用于清理 SQLMap 在目标系统中创建的临时文件和数据库痕迹，以消除渗透测试留下的证据

• 🔍核心功能：

• 自动删除注入残留：移除 SQLMap 生成的临时表、用户定义函数（UDF）、系统表等数据库对象，避免被目标系统检测
• 文件系统清理：删除通过文件系统操作（如 --file-write）上传的临时脚本和执行文件（如 tmpudf.dll）

• ⚡命令语法：

• 基础命令：sqlmap -u "http://1.1.1.1" --cleanup
• 典型场景：测试后立即清理痕迹，防止管理员发现入侵行为

•  sqlmap -u "http://1.1.1.1/?id=1" --dump-all --cleanu

• ⚠注意事项：

• 功能限制：

• 不可逆操作：清理后无法恢复数据（需提前备份扫描结果）
• 依赖数据库权限：需原注入点具备 DROP/CREATE 权限才能生效
• 不覆盖日志：不删除数据库或服务器的访问日志（需额外手动清理）

• 与相关参数对比：

• 法律风险：未授权清理操作构成《网络安全法》禁止的“破坏数据完整性”行为（第 27 条）

• 💎优化建议：

• 权限验证：清理前用 --is-dba 确认数据库管理员权限，避免操作失败触发警报
• 注：该参数对通过 --os-shell 创建的系统级文件无效，需手动删除

• --crawl：用于自动爬取目标网站链接并递归测试 SQL 注入漏洞

• 🔍核心功能：

• 自动化爬虫扫描：从起始 URL 开始递归抓取网页链接（如 <a> 标签的 href 属性），自动识别并测试所有发现的 URL 参数（如 ?id=1）是否存在 SQL 注入漏洞
• 深度与范围控制：

• 配合 --crawl-exclude 可排除特定路径（如 logout.php）

• ⚡使用方法：

• 基础命令：sqlmap -u "http://example.com" --crawl 3

• 递归遍历网站链接

• 关键参数组合(排除敏感路径)：sqlmap -u "http://example.com" --crawl 3 --crawl-exclude="logout|admin"

• ⚠注意事项：

• 功能限制：

• 仅支持爬取 HTML 静态链接，无法处理 JavaScript 动态生成的内容
• 大规模爬取可能耗尽目标服务器资源，导致服务中断

• 安全与法律风险：

• 高流量特征：连续爬取易被 WAF 识别为恶意扫描（如 Cloudflare 的 Bot 防护）
• 法律责任：未授权扫描违反《网络安全法》第 27 条，可能面临行政处罚

• 💡优化建议：

• 目标精准化：结合 --forms 参数抓取并测试表单（如登录框），提升漏洞发现率
• 规避策略：使用 --random-agent 随机化 UA 标识，降低被 WAF 封禁概率

• 注：该功能适用于网站结构扁平化的目标（如博客、CMS），对 SPA（单页面应用）效果有限

• --crawl-exclude：用于在自动爬行目标网站时排除特定 URL 路径的参数，通常与 --crawl 配合使用。其核心作用是通过正则表达式过滤掉不需要爬取的页面，从而提升扫描效率并减少干扰

• 🔍核心功能：

• 作用场景：当使用 --crawl 参数启动自动爬行功能时（例如 sqlmap -u "http://1.1.1.1" --crawl=2），sqlmap 会递归遍历网站链接。--crawl-exclude 可指定需跳过的 URL 模式，例如：

• 排除登录/注销页面（避免触发账户锁定）
• 过滤静态资源（如图片、CSS 文件）
• 跳过无关功能路径（如用户中心、后台管理）

• 技术实现：通过正则表达式匹配 URL，符合规则的页面将被忽略。例如：

• 排除包含 "logout" 或 "admin" 的 URL：--crawl-exclude="logout|admin"

• ⚡使用方法：

• 排除敏感路径：sqlmap -u "http://1.1.1.1" --crawl=3 --crawl-exclude="login.php|user/profile"

• 效果：跳过 login.php 及所有用户个人资料页面，避免因频繁访问敏感接口触发防护机制

• 忽略静态资源：sqlmap -u "http://1.1.1.1" --crawl=2 --crawl-exclude=".(jpg|css|js)$"

• 效果：通过正则表达式排除所有 .jpg、.css、.js 文件，减少无效请求

• ⚠注意事项：

• 依赖 --crawl 参数：--crawl-exclude 仅在启用 --crawl 时生效，单独使用无效
• 正则表达式语法：

• 使用 | 分隔多个匹配条件（如 logout|admin）
• 用 转义特殊字符（如 login.php）

• 与其他过滤参数的区别：--scope：基于域名或 URL 模式限定扫描范围（如 --scope="(www)?.target.com"）

• 💡常见问题解决：若扫描仍包含排除的 URL，可能原因包括：

• 正则表达式错误：检查表达式是否匹配目标 URL（例如大小写敏感问题）
• 爬行深度过大：降低 --crawl 深度值（如从 3 改为 2），减少深层链接的干扰

• 通过合理使用 --crawl-exclude，可显著优化 sqlmap 的扫描效率，避免对非目标路径的冗余检测

• --csv-del：用于自定义 CSV 文件分隔符的参数，主要作用于数据导出（--dump）场景。当 SQLMap 将数据库内容导出为 CSV 格式时，默认使用逗号（,）作为字段分隔符。若数据本身包含逗号，或需适配特定系统格式（如分号分隔），可通过此参数指定替代符号

• 🔍核心功能：

• 作用场景：

• 在导出数据（如 --dump）时，控制 CSV 文件的分隔符格式
• 避免默认逗号与数据内容冲突（例如字段含逗号时会导致解析错误）
• 适配外部系统要求（如欧洲常用分号 ; 作为分隔符）

• 语法格式： 
   --csv-del="分隔符"

• 分隔符类型：支持单字符或转义字符（如 t 代表制表符）
• 常见示例：

• --csv-del=";" → 使用分号分隔字段
• --csv-del="|" → 使用竖线分隔

• ⚡使用方法：

• 导出数据时分号分隔：sqlmap -u "http://1.1.1.1/vuln.php?id=1" --dump --csv-del=";"

• 效果：生成的 CSV 文件以 ; 分隔字段，适用于 Excel 欧洲版或含逗号的数据

• 制表符分隔（TSV 格式）：sqlmap -u "http://1.1.1.1/vuln.php?id=1" --dump --csv-del="t"

• 效果：生成制表符分隔文件（TSV），便于直接导入数据分析工具（如 Python pandas）

• ⚠注意事项：

• 依赖导出操作：--csv-del 仅在数据导出时生效（需配合 --dump 或 -D <DB> -T <TABLE> --dump 使用）
• 编码问题：

• 中文乱码：若导出 CSV 出现乱码，可尝试以下方案：

• 添加 --encoding=utf-8 指定编码
• 用文本编辑器（如 Notepad++）转换编码为 UTF-8 BOM

• 文件命名：避免中文路径/文件名，减少编码错误风险

• 与其他参数协作：

• 数据范围控制：结合 -C "col1,col2" 选择导出列
• 输出目录：使用 --output-dir 指定保存路径

• 💡总结：

• 适用场景：需定制 CSV 格式、避免分隔符冲突或适配第三方工具时
• 替代方案：若需更复杂格式（如 HTML 或 SQLITE），可使用 --dump-format=HTML
• 调试技巧：用 -v 3 查看生成的 CSV 结构，验证分隔符是否生效

• --charset：用于指定目标数据库字符集的参数，主要解决数据检索过程中的乱码问题（尤其是非拉丁字符集场景）。其核心作用是确保 sqlmap 正确解析数据库返回的编码内容，避免中文字符、特殊符号等显示异常

• 🔍核心功能：

• 乱码修复：当目标数据库使用非默认字符集（如中文环境常用 GBK、GB2312）时，若不指定字符集，sqlmap 可能无法正确解析返回数据，导致中文字符显示为乱码或 ? 占位符

• 典型场景：

• 数据库存储中文、日文、韩文等双字节字符
• 默认字符集配置错误（如 MySQL 8.0 默认字符集变更引发兼容问题）

• 注入负载兼容：在布尔盲注或时间盲注中，字符集影响 payload 的构造与响应解析。指定字符集可提高注入成功率

• ⚡使用方法：

• 基础语法：sqlmap -u "目标URL" --charset=字符集名称
• 常用字符集选项：

• 针对使用GBK编码的数据库进行注入并导出数据：sqlmap -u "http://1.1.1.1/vuln.php?id=1" --charset=GBK --dump -D testdb -T users

• 效果：确保 users 表中的中文用户名、密码字段正常显示，避免乱码

• ⚠注意事项：

• 依赖数据检索操作：--charset 仅在数据检索时生效（需配合 --dump、--search 等参数），单独使用无效
• 与其他参数协作：

• 编码转换：若导出文件仍乱码，可用系统工具转换（如 Linux 下 iconv -f GBK -t UTF-8 output.txt）
• HTTP头设置：部分场景需同步设置 --encoding=UTF-8 确保请求-响应编码一致
• Tamper脚本：复杂过滤场景可搭配 --tamper=unmagicquotes.py 绕过转义机制

• 常见问题排查：

• 💡总结：

• 优先场景：处理中文、日文等宽字符数据时必选参数
• 替代方案：若数据库支持 Unicode（如 utf8mb4），可优先使用 --encoding=UTF-8 简化配置
• 调试命令：配合 -v 3 查看原始响应数据，验证字符集是否生效

• --dump-file：用于指定数据库转储内容保存路径的参数，通常与数据导出操作（如 --dump）配合使用。其核心作用是将提取的数据库表内容输出到用户自定义文件中，避免默认输出到终端，便于后续分析或存档

• 🔍核心功能：

• 作用场景：

• 保存数据到本地文件：当使用 --dump 导出表数据时，默认输出到终端，而 --dump-file 可将结果直接写入指定文件
• 批量处理与自动化：在脚本化操作中，通过文件保存结果，便于与其他工具集成（如数据分析或报告生成）
• 避免终端截断：当数据量过大时，终端显示可能截断，保存到文件可确保完整性

• 语法格式： sqlmap -u <目标URL> --dump -D <数据库名> -T <表名> --dump-file=<文件路径>

• 文件路径支持：绝对路径或相对路径，需确保目录可写（如 /tmp/output.txt 或 C:dumpdata.csv）
• 格式兼容性：生成的文件为纯文本格式，若需结构化数据（如 CSV），可结合 --csv-del 指定分隔符

• ⚡使用方法：sqlmap -u "http://1.1.1.1/vuln.php?id=1" --dump-all --dump-file=full_dump.txt

• ⚠注意事项：

• 依赖导出操作：--dump-file 仅在启用数据导出时生效（需配合 --dump 或 --dump-all），单独使用无效
• 文件覆盖与追加：

• 默认行为：若文件已存在，直接覆盖（无警告提示）
• 追加数据：需手动预处理（如用脚本合并文件），sqlmap 原生不支持追加模式

• 权限与路径问题：

• 与其他参数协作：

• 数据过滤：结合 -C 指定列（如 -C "username,email"）减少输出量
• 格式控制：使用 --csv-del=";" 指定 CSV 分隔符，配合 --dump-file 生成结构化数据
• 日志分离：通过 --output-dir 统一管理输出目录，避免文件散落

• 💡替代方案：

• 直接导出为 CSV：若需 Excel 兼容格式，使用 --dump + --csv-del 生成 CSV，无需额外转换

•  sqlmap -u <URL> --dump -D db -T table --csv-del="," --dump-file=data.csv

• 二进制格式导出：对大型数据库，优先用 --dump-format=SQLITE 生成 SQLite 文件，节省空间并支持复杂查询
• 调试数据完整性：添加 -v 3 显示详细转储过程，验证文件是否完整生成

• 总结：-dump-file 是 sqlmap 数据导出的关键辅助参数，核心价值在于将结果持久化到本地文件，尤其适合数据分析、审计报告或自动化流程。实际使用时需注意路径权限、文件覆盖机制，并灵活结合过滤与格式化参数优化输出效率

• --dump-format：用于指定数据导出格式的参数，通常与数据导出操作（如 --dump）配合使用。其核心作用是控制从数据库提取的数据以何种结构化格式保存，便于后续分析或与其他工具集成

• 🔍核心功能：

• 作用场景：

• 格式定制化：默认导出格式为 CSV，但可通过 --dump-format 指定为 JSON、XML、SQLITE 等格式，适应不同分析需求
• 数据兼容性：例如 JSON 格式便于 Python/Pandas 解析，SQLITE 格式可直接导入数据库管理工具
• 避免默认限制：CSV 可能因字段含逗号导致解析错误，其他格式可规避此问题

• 语法格式： sqlmap -u <目标URL> --dump --dump-format=<格式>

• 支持格式：CSV（默认）、XML、JSON、HTML、SQLITE、TXT
• 依赖关系：需配合 --dump 或 --dump-all 使用，单独无效

• 💻各格式特点与适用场景：

• 注：TXT 格式为无结构纯文本，仅推荐简单日志记录

• ⚡使用方法：

• 导出为 SQLITE 数据库：sqlmap -u "http://1.1.1.1/vuln.php?id=1" --dump -D user_db -T accounts --dump-format=SQLITE

• 效果：生成 user_db_accounts.db 文件，可直接用 SQLite 浏览器查询或导入 MySQL

• 生成 JSON 报告：sqlmap -u "http://1.1.1.1/vuln.php?id=1" --dump-all --dump-format=HTML --output-dir=/reports

• 效果：所有数据库表数据以HTML 格式保存至 /reports 目录，便于自动化脚本分析

• ⚠注意事项：

• 路径与权限：

• 输出文件默认保存在 output/ 目录，可通过 --output-dir 自定义路径
• 需确保目录可写权限，否则报错 I/O error（如 Windows 只读属性或 Linux 权限不足）

• 数据完整性：

• 大型数据库导出建议用 SQLITE 格式节省空间，避免 CSV/JSON 的内存瓶颈
• 添加 -v 3 参数可实时查看导出进度及文件生成路径

• 格式转换：

• 若需转换格式（如 CSV 转 Excel），可用工具如 pandas.read_csv() 或在线转换器
• 中文乱码问题可搭配 --charset=UTF-8 或导出后使用 iconv 转码

• 💡总结：

• 优先场景：

• 需复杂查询 → SQLITE
• 需编程处理 → JSON
• 需人工查看 → HTML/CSV

• 避坑指南：

• 字段含特殊字符时避免 CSV，改用 JSON 或 XML
• 超大数据集优先 SQLITE 并分批次导出（结合 --start/--end）

• --encoding：用于指定 HTTP 请求/响应字符编码的参数，主要解决因编码不一致导致的乱码问题或注入失败。其核心功能是确保 sqlmap 与目标服务器之间的数据传输可正确解析，尤其在处理非 ASCII 字符（如中文、日文）时至关重要

• 🔍核心功能：

• 编码冲突修复：

• 乱码问题：当目标服务器响应内容使用非 UTF-8 编码（如 GBK、BIG5）时，未指定 --encoding 可能导致响应正文显示为乱码，影响注入结果解析
• 注入失败：若请求参数含特殊字符（如中文），未正确编码可能导致服务器拒绝处理或解析错误，使注入检测失效

• 典型应用场景：

• 目标网站为中文、日文等双字节字符集（如 GB2312、SHIFT_JIS）
• 服务器响应头未明确声明 Content-Type 或声明错误
• 需手动覆盖默认编码（sqlmap 默认使用 UTF-8）

• ⚡使用方法：

• 基础语法：sqlmap -u <目标URL> --encoding=<字符集名称>
• 常用字符集选项：

• 修复中文乱码： sqlmap -u "http://1.1.1.1/search?kw=测试" --encoding=GBK

• 效果：确保关键词 测试 以 GBK 编码发送，并正确解析服务器返回的中文内容

• 处理日文表单注入： sqlmap -u "http://1.1.1.1/login" --data="user=山田&pass=123" --encoding=SHIFT_JIS

• 效果：避免日文字符 山田 被错误编码，确保注入负载有效传递

• ⚠注意事项：

• 与 --charset 的区别：

• --encoding：控制 HTTP 传输层的编解码（请求/响应流）
• --charset：指定 数据库内容的字符集（如存储的数据为 GBK 时需用 --charset=GBK）
• 需协同使用场景： sqlmap -u <URL> --encoding=UTF-8 --charset=GBK

• 编码探测与调试：

• 自动探测：若不确定编码，先用 --batch 模式运行，观察 sqlmap 的编码猜测提示
• 手动验证：通过 -v 6 查看原始请求/响应，对比乱码前后的十六进制值

• 常见问题解决：

• 💡总结：

• 优先场景：目标网站含非拉丁字符（中文/日文/韩文）或响应出现乱码时必选
• 参数协同：若数据库内容与传输编码不同，需同时指定 --encoding 和 --charset
• 调试命令：配合 -v 3 或 --proxy 实时监控数据流，确保编码生效
• 参数对比表：

• --eta：用于在盲注（Blind SQL Injection）测试过程中实时显示预估剩余时间。该功能主要适用于时间型盲注（Time-Based Blind Injection）场景，通过动态计算每个请求的处理时长和整体进度，为用户提供任务完成的预估时间，提升测试过程的可控性（好像没看到剩余时间预估，也可能是太慢了，实在等不起了）

• 🔍核心功能：

• 作用原理：

• 在时间型盲注中，sqlmap 通过注入延迟语句（如 SLEEP(5)）并测量响应时间差异来判断漏洞存在性，此过程通常耗时较长
• --eta 会基于已完成的请求数量、平均请求耗时及剩余请求量，动态计算并输出剩余时间预估（如 [ETA: 12m 34s]）

• 适用场景：

• 长序列盲注测试：当目标数据库响应缓慢或需枚举大量数据（如表名、列名）时，帮助用户规划测试时间
• 自动化脚本集成：结合 --batch 参数实现无人值守测试时，提供进度监控依据

• ⚡使用方法：

• 基础语法：sqlmap -u <目标URL> --eta
• 典型示例：sqlmap -u "http://1.1.1.1/vuln.php?id=1" --technique=T --eta

• 参数说明：--technique=T：指定使用时间型盲注技术（可省略，sqlmap 默认自动检测）

• ⚠注意事项：

• 依赖盲注技术：--eta 仅在时间型盲注（--technique=T）或布尔盲注（--technique=B）中生效。若未检测到盲注漏洞，该参数无输出
• 准确性影响因素：

• 网络波动：网络延迟可能导致预估时间偏差
• 目标负载：数据库服务器负载变化可能影响请求响应时间
• 建议结合 -v 3 参数查看详细请求日志以验证实际耗时

• 与其他参数协作：

• 批量操作：搭配 --batch 实现全自动测试（如 sqlmap -u <URL> --eta --batch）
• 数据枚举优化：通过 --threads 增加并发线程数缩短总耗时，但需避免触发目标防护机制

• 💡总结：

• 核心价值：--eta 是 优化长时盲注测试体验 的关键参数，尤其适合需枚举大型数据库或慢速目标的场景
• 替代方案：若需更快的测试速度，可优先尝试联合查询（--technique=U）或报错注入（--technique=E）
• 调试命令：启用 -v 3 查看实时请求详情，同步监控 --eta 预估准确性

•  --flush session：用于强制清除当前目标会话缓存的参数，主要解决因历史会话数据干扰导致的扫描异常或误报问题。其核心作用是确保每次扫描从零开始，避免旧数据影响新测试结果

• 🔍核心功能：

• 清除历史缓存：默认情况下，sqlmap 会生成 .sqlite 会话文件记录扫描状态（如已测试的注入点、Payload 等）。--flush-session 会强制删除这些缓存，确保重新扫描时不受历史数据干扰
• 典型场景：

• 目标网站更新后需重新检测漏洞
• 历史扫描因异常中断导致结果不准确
• 高版本 sqlmap 因缓存兼容性无法检测注入（需回退版本时）

• 避免误报与漏报：会话缓存可能包含过时的注入点信息，导致新扫描跳过有效测试路径。清除缓存可提升检测准确性

• ⚡使用方法：

• 基础语法：sqlmap -u <目标URL> --flush-session [其他参数]

• 常用协作参数：

• ⚠注意事项：

• 文件权限问题：若 sqlmap 无权限删除会话文件（如 Windows 只读属性），需手动清理 output/ 目录

• 解决命令：

•  Linux/Mac：rm -rf ~/.sqlmap/output/<目标域名>/* 
• Windows：del /F /Q C:Users<用户>.sqlmapoutput<目标域名>* 

• 与版本兼容性：部分旧版本（如 v1.2）的缓存格式与新版本不兼容，若切换版本扫描必须使用 --flush-session
• 性能影响：清除缓存后，sqlmap 需重新测试所有注入点，扫描时间显著增加。建议仅在必要时使用

• 🔧典型问题解决方案：

• 💡替代方案：

• 轻量级替代：若仅需忽略历史结果但不删除文件，使用 --fresh-queries 更高效
• 自动化脚本建议：在持续集成（CI）流程中，每次扫描前自动删除会话目录

•  rm -rf ~/.sqlmap/output/$TARGET_DOMAIN 
• sqlmap -u $URL --batch --output-dir=/ci_logs

• 总结：--flush-session 是解决会话缓存污染问题的关键参数，适用于版本切换、目标更新或异常修复场景。日常扫描可优先尝试 --fresh-queries，若仍异常再启用强制清除模式

• --forms：用于自动检测并测试目标页面中表单（Form）的 SQL 注入漏洞的参数。它简化了对 POST 请求的注入测试流程，特别适用于含登录框、搜索框等交互式表单的页面

• 🔍核心功能：

• 自动表单解析：当目标页面存在 <form> 标签时，--forms 会自动解析表单中的输入字段（如 <input>, <textarea>），并模拟提交行为进行注入检测
• 适用场景：无需手动抓包或指定参数，快速扫描含表单的页面（如登录页、搜索页）
• 简化 POST 注入测试：替代手动构造 --data 参数或保存请求文件（-r），直接通过 URL 触发自动化测试

• ⚡使用方法：

• 基础语法：sqlmap -u <目标URL> --forms
• 扫描登录页表单： sqlmap -u "http://1.1.1.1/login" --forms

• 效果：自动识别 username、password 等字段并测试注入点

• 指定注入字段：若需聚焦特定字段，可结合 -p 参数

•  sqlmap -u "http://1.1.1.1/search" --forms -p "keyword"

• ⚠注意事项：

• 与 -r 和 --data 的对比：

• 登录认证支持：若表单需登录后访问，需附加 --cookie 或 --auth-type 参数

•  sqlmap -u "http://1.1.1.1/protected-page" --forms --cookie "sessionid=123abc"

• 结果可靠性验证：启用 -v 3 查看检测详情，确认 sqlmap 是否成功识别表单字段

• 💡总结：

• 优先使用场景：

• 快速筛查含表单的页面 → --forms
• 需精细化控制字段 → -p + --forms
• 复杂请求（含 Cookie/Header）→ -r 替代

• 避坑指南：

• 动态加载的表单（如 Ajax）需手动抓包使用 -r
• 结合 --batch 实现全自动测试（无交互确认）

原文始发于微信公众号（一个努力的学渣）：Sqlmap全参数讲解之第十二篇