Sqlmap全参数讲解之第十三篇

免责声明

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

General：常规参数

此篇为常规参数的第二篇，第一篇为《Sqlmap全参数讲解之第十二篇》

• --fresh-queries：用于强制忽略会话缓存中的历史查询结果的参数，确保每次执行时重新从目标数据库获取最新数据。其核心作用是避免因缓存导致的数据滞后或误报，适用于需要实时性的场景

• 🔍核心功能：

• 动态数据更新：

• 当目标数据库频繁变动（如测试环境或实时业务系统）时，使用 --fresh-queries 可确保每次查询均获取最新数据，避免旧缓存干扰结果

• 典型用例：渗透测试中需验证实时漏洞修复效果，或监控数据篡改行为
• 与缓存参数的协同关系：

• --flush-session：直接删除会话文件（.sqlite），彻底清除所有历史缓存（包括注入点记录）
• --fresh-queries：仅忽略查询结果缓存，保留注入点等元数据，效率更高
• → 若需全面重扫，选 --flush-session；若仅需更新数据，选 --fresh-queries

• ⚡使用方法：

• 基础语法：sqlmap -u <目标URL> --fresh-queries [其他参数]
• 验证漏洞修复后数据： sqlmap -u "http://1.1.1.1/search?id=1" --fresh-queries --dbs

• 效果：忽略历史库名缓存，重新枚举当前数据库列表

• 结合数据导出操作： sqlmap -u "http://1.1.1.1/login" --data="user=admin" --fresh-queries --dump -T users

• 效果：强制从数据库实时导出 users 表数据，避免导出过时信息

• ⚠注意事项：

• 性能影响：

• 重新执行所有查询会显著增加扫描时间，尤其在盲注场景下。建议仅在必要时启用
• 优化方案：搭配 --threads 提升并发效率（如 --threads=10）

• 常见问题解决：

• 替代方案：

• 轻量级忽略缓存：--skip-cache（部分版本支持）
• 彻底清除缓存：sqlmap ----purge 删除整个 output/ 目录

• 💡总结：

• 优先使用场景：

• 目标数据库数据频繁更新（如电商库存、日志系统）
• 需验证漏洞修复或实时监控数据一致性时

• 参数协作建议：

• 实时扫描 + 高效导出：--fresh-queries --threads 10 --dump
• 避免误报：配合 -v 3 查看实时请求日志

• 参数对比表：

• --gpage：用于指定 Google 搜索结果页码的参数，需与 -g（Google 搜索模式）联合使用。它允许用户自定义扫描 Google 搜索结果的范围，突破默认仅扫描前 100 条结果的限制，适用于批量自动化注入测试场景

• 🔍核心功能：

• 扩展扫描范围：默认 -g 参数仅抓取 Google 前 100 条结果（约第 1 页），--gpage=N 可指定扫描第 N 页结果，扩大目标覆盖面
• 适用场景：批量扫描特定关键词的潜在注入点（如 inurl:login.php?id=），适用于大规模漏洞挖掘或资产普查
• 自动化批量注入：结合 --batch（自动确认）、--threads（多线程）等参数，实现全自动化扫描流程

• ⚡使用方法：

• 基础语法： sqlmap -g "inurl:view.php?id=" --gpage=3 --batch
• 扫描 Google 前 3 页结果： sqlmap -g "inurl:view.php?id=" --gpage=3 --batch

• 效果：自动检测 Google 前 3 页中所有含 view.php?id= 的 URL 是否存在注入漏洞

• 突破默认 100 条限制：修改 sqlmap 源码文件 sqlmap/lib/utils/search.py，将 num=100 调整为 num=1000，可配合 --gpage 抓取更多结果

# 修改前url += "num=100&hl=en&complete=0&safe=off&filter=0&btnG=Search"# 修改后url += "num=1000&hl=en&complete=0&safe=off&filter=0&btnG=Search"

• ⚠注意事项：

• 依赖网络环境：

• 需稳定访问 Google，若受限可添加 --proxy 参数（如 --proxy="http://127.0.0.1:8080"）
• 关键词需符合 Google 语法（如 site:, inurl:, filetype:）

• 性能与效率优化：

• 多线程加速：--threads 建议 ≤ 10，避免触发反爬机制
• 结果过滤：搭配 --smart 仅检测易注入目标，减少无效扫描

•  sqlmap -g "inurl:index.php?id=1" --gpage=2 --smart

• 法律与合规性：

• 授权测试：未经授权扫描第三方网站可能违法，务必在授权范围内使用
• 结果验证：自动扫描可能存在误报，需手动复测关键目标

• 💡总结：

• 核心价值：--gpage 是 批量自动化漏洞挖掘 的高效工具，尤其适合安全团队进行资产风险普查
• 替代方案：若需精细控制单个目标，优先使用 -u 或 -r 参数
• 实战命令：综合优化扫描效率与准确性

•  sqlmap -g "site:example.com inurl:id=" --gpage=5 --threads 8 --batch --smart

• --har：用于通过 HAR 文件（HTTP Archive）自动化检测注入点的参数。它允许用户将浏览器或抓包工具（如 Charles、Burp Suite）记录的完整 HTTP 流量直接导入 sqlmap，无需手动配置请求参数，特别适用于复杂请求场景（如含动态 Token、多步骤认证的页面）

• 🔍核心功能：

• 自动化解析复杂请求：

• HAR 文件作用：记录浏览器与服务器的完整交互（URL、Headers、Cookies、POST 数据等），解决手动抓包配置繁琐的问题

• 典型场景：

• 目标网站需登录（含 Cookie 或 CSRF-Token）
• 请求结构复杂（如多层 JSON 参数、动态表单）
• 需批量测试多个接口（HAR 可包含多个请求）

• 与 -r 参数的对比：

• ⚡使用方法：

• 生成 HAR 文件：

• 浏览器开发者工具（Chrome/Firefox）

• 打开开发者工具 → Network 面板
• 操作目标页面（如提交表单）
• 右键请求列表 → Save all as HAR with content

• 抓包工具 Charles：Tools → Auto Save → 选择保存路径

• 基础命令：sqlmap --har=<HAR文件路径> [其他参数]

• 测试登录接口注入： sqlmap --har=login_session.har --batch --dbs

• 效果：自动识别 login_session.har 中的 POST 请求，检测 username、password 等字段的注入点

• 绕过动态 Token 防护： sqlmap --har=api_request.har --tamper=space2comment --risk=3

• 技巧：配合 --tamper 混淆载荷，避免 WAF 识别动态 Token

• OA 系统批量测试：sqlmap --har=oa_traffic.har --batch --crawl=2 --forms

• 技巧：组合 --crawl 爬取子页面 + --forms 解析新表单，扩大检测范围

• ⚠注意事项：

• 文件路径问题：

• 路径含空格或特殊字符时需加引号：--har="C:My Datasession.har"
• 若 sqlmap 报错 Unable to parse HAR file，检查 HAR 格式有效性（可用在线工具验证）

• 过滤无效请求：HAR 可能包含图片、CSS 等静态请求，通过 --scope 正则过滤目标 URL

•  sqlmap --har=traffic.har --scope="(login|search).php"

• 会话维持：若需保持登录态，确保 HAR 包含登录后的请求（如 Cookie: sessionid=xxx）
• 性能优化：大体积 HAR 文件（>50MB）可能降低扫描速度，建议先手动删除无关请求

• 💡替代方案：

• 优先使用场景：

• 复杂身份验证流程 → --har
• 需批量扫描多个 API 接口 → --har + --scope

• 轻量级替代：

• 单一请求测试 → -r request.txt
• 已知参数结构 → --data "key=value"

• 最佳实践：

• 使用 Charles 定期保存 HAR 文件（Tools → Auto Save）
• 扫描前用 --validate 校验 HAR 解析结果（需 sqlmap 开发版）
• 敏感环境测试时，用 --output-dir 指定独立输出目录避免污染

• --hex：用于处理非 ASCII 字符数据的关键参数，通过将数据编码为十六进制格式后再解码回原始形式，确保特殊字符（如中文、二进制数据等）在注入过程中的完整性和可读性

• 🔍核心功能：

• 非 ASCII 字符安全传输：当目标数据库包含中文、emoji 或二进制数据（如图片、文件）时，直接检索可能导致乱码或截断。--hex 会先将数据转换为十六进制格式（如 中文字符 → E4B8ADE69687），检索完成后再解码还原
• 典型场景：

• 数据库字段含中文内容（如用户昵称、日志文本）
• 提取二进制数据（如存储的图片、加密密钥）

• 绕过字符转义问题：某些 WAF/IDS 设备会对特殊字符（如单引号、换行符）进行过滤。十六进制格式可规避此类检测，提高注入成功率

• ⚡使用方法：

• 基础语法：sqlmap -u <目标URL> --hex [其他参数]
• 提取含中文的数据库字段： sqlmap -u "http://1.1.1.1/news?id=1" --hex ---dump -D test -T test

• 效果：content 字段中的中文文本将以十六进制形式传输，解码后显示原文

• 导出二进制文件（如图片）： sqlmap -u "http://1.1.1.1/profile?user=admin" --hex --dump -C avatar --where "user_id=1"

• 输出：返回十六进制字符串（如 89504E470D0A1A0A...），可通过 xxd -r -p 命令还原为 PNG 文件

• ⚠注意事项：

• 性能影响：编解码过程会增加额外开销，尤其在盲注场景下可能显著延长扫描时间。建议搭配 --threads 提升效率

•  sqlmap -u "http://1.1.1.1" --hex --threads 8

• 数据验证与解码：使用 -v 3 查看原始十六进制响应
• 手动解码工具：

• Python：bytes.fromhex(hex_string).decode('utf-8')
• 在线工具：
  
  https://www.rapidtables.com/convert/number/hex-to-ascii.html

• 与 --tamper 的协同使用：若目标存在 WAF，可组合编码脚本（如 charencode.py）增强隐蔽性

• 💎替代方案与参数对比：

• 优先选择场景：

• 需确保数据完整性时 → --hex
• 仅需规避字符过滤 → --tamper + 编码脚本

• 💡总结：

• 何时使用：

• 数据库含 非拉丁字符（如中文、俄文） 或 二进制数据
• 常规注入返回 乱码/截断数据 时

• 优化策略：

• 大字段提取：结合 --limit 100 分批获取，避免超时
• 结果保存：使用 --output-dir=/tmp 指定独立输出目录

• --output-dir：用于自定义扫描结果存储路径的核心参数，默认情况下 sqlmap 会将日志、数据提取文件等输出到临时目录（~/.sqlmap/output/），而该参数允许用户将结果集中保存到指定路径，便于结果管理和后续分析

• 🔍核心功能：

• 统一管理扫描结果：默认输出路径分散且不易查找，--output-dir 可将所有输出文件（包括日志、数据导出文件、会话缓存等）整合到指定目录，避免结果散落
• 典型用例：

• 批量扫描多个目标时，按目标域名/IP 分目录存储结果
• 长期渗透测试项目需归档历史扫描记录

• 避免权限冲突：若默认输出目录（如 /root/.sqlmap）因权限问题无法写入，可通过该参数重定向到用户有写权限的路径（如 /tmp/）

• ⚡使用方法：

• 基础语法：sqlmap -u <目标URL> --output-dir=/自定义/路径 [其他参数]
• 指定绝对路径保存结果： sqlmap -u "http://1.1.1.1/vuln.php?id=1" --output-dir=/home/user/sqlmap_results/

• 效果：所有输出文件（如日志 log、数据文件 dump）均保存至 /home/user/sqlmap_results/

• 结合批量扫描与多线程： sqlmap -m targets.txt --output-dir=./scan_reports/ --threads=10

• -m targets.txt：扫描多个目标（每行一个URL）
• 结果按目标URL自动生成子目录存放，结构清晰

• ⚠注意事项：

• 路径格式要求：

• 路径需以 / 结尾（Linux/macOS）或 结尾（Windows），否则可能被识别为文件名
• 路径含空格时需加引号：--output-dir="C:My ReportsSQL Injection"

• 目录复用与清理：

• 复用目录：若目录已存在，sqlmap 会追加新结果而非覆盖，可能导致文件混杂。建议每次扫描使用新路径或手动清理旧文件
• 彻底清除缓存：

•  清空默认输出目录：sqlmap ----purge
• 清空自定义目录(貌似不行)：sqlmap --output-dir=/tmp/ ----purge

• 💡总结：

• 最佳实践：

• 重要扫描务必指定 --output-dir 备份结果
• 敏感数据扫描后使用 --purge、 清理痕迹

• --parse-errors：用于解析并显示数据库返回的内建错误信息的关键参数，尤其在利用报错注入漏洞时能快速定位数据库结构及注入点

• 🔍核心功能：

• 自动解析数据库错误信息：当目标网站开启数据库错误回显（如未屏蔽 SQL 执行错误）时，--parse-errors 会自动提取并分析错误中的关键信息（如数据库类型、表结构、语法问题等）
• 典型用例：

• 快速识别数据库类型（如 MySQL 的 You have an error in your SQL syntax）
• 定位注入点字段的数据类型或约束条件（如 Column 'id' cannot be null）

• 与常规注入技术的协同：

• ⚡使用方法：

• 基础命令：sqlmap -u "http://1.1.1.1/page.php?id=1" --parse-errors
• 识别数据库类型及版本： sqlmap -u "http://1.1.1.1/news?id=1" --parse-errors --banner
• 辅助复杂注入绕过： sqlmap -u "http://1.1.1.1/data" --data='{"key":"value*"}' --parse-errors --level=3

• 配合 --level 提升检测深度，解析 JSON/XML 等复杂请求中的错误
• 若错误含表名（如 Table 'users' doesn't exist），可直接用于后续枚举（--tables -D current_db）

• ⚠注意事项：

• 依赖错误回显机制：

• 目标需未屏蔽数据库错误（如 PHP 的 display_errors=On），否则参数无效
• 若错误信息被框架封装（如返回 HTTP 500 但无详细 SQL 错误），需结合 --string/--not-string 过滤响应特征

• 性能与输出优化：启用 -v 3 查看原始错误响应细节，验证解析准确性

• 💡优化建议：

• 优先使用场景：

• 目标开启数据库错误回显 → --parse-errors + --technique=E
• 需快速验证注入点有效性 → --parse-errors + --banner

• 无错误回显替代方案：

• 布尔盲注：--technique=B --string="Welcome back"
• 时间盲注：--technique=T --time-sec=5

• --preprocess：用于 在注入测试前对 HTTP 请求进行预处理 的参数，主要用于优化请求结构、处理特殊编码及绕过基础防护机制

• 🔍适用场景：

• 绕过 Web 应用防火墙（WAF） ：通过修改请求内容，绕过 WAF 的检测规则
• 自定义请求处理 ：在发送请求前对请求进行特定的修改，如添加特定的请求头或修改参数格式

• ⚡使用方法：

• 基础命令：sqlmap -u <目标URL> --preprocess [脚本名]

• ⚠注意事项：

• 脚本编写 ：需要确保脚本正确无误，并且与 sqlmap 的预期行为一致。脚本编写不当可能会导致请求失败或结果不准确
• 与其他参数配合使用 ：可以根据需要与其他参数（如 --tamper、--postprocess 等）配合使用，以实现更复杂的请求处理逻辑
• 性能影响 ：预处理脚本会增加一定的处理时间，特别是在处理大量请求时，可能会对测试效率产生一定影响

• 💡总结：在需要对 sqlmap 发送的请求进行特定修改时，可以使用 --preprocess 参数指定预处理脚本。这有助于绕过安全机制或满足特定的测试需求。使用时需确保脚本的正确性，并注意其对性能的影响

• --postprocess：对 sqlmap 获取到的 HTTP 响应进行后处理有关

• 🔍适用场景：

• 提取特定信息 ：在 sqlmap 获取到的响应中提取特定的信息，如页面标题、特定字段等
• 解码或解析数据 ：对响应内容进行解码或解析，以便更好地理解和利用这些数据
• 验证响应内容 ：检查响应内容是否符合预期，如验证是否存在特定的标记或内容

• ⚡使用方法：

• 基础用法：sqlmap -u <目标URL> --postprocess [脚本名]

• ⚠注意事项：

• 脚本编写 ：需要确保脚本正确无误，并且与 sqlmap 的预期行为一致。脚本编写不当可能会导致处理失败或结果不准确
• 与其他参数配合使用 ：可以根据需要与其他参数（如 --preprocess、--tamper 等）配合使用，以实现更复杂的请求处理逻辑
• 性能影响 ：后处理脚本会增加一定的处理时间，特别是在处理大量响应时，可能会对测试效率产生一定影响

• 💡总结：在需要对 sqlmap 获取到的 HTTP 响应进行特定处理或分析时，可以使用 --postprocess 参数指定后处理脚本。这有助于提取特定信息、解码数据或验证响应内容。使用时需确保脚本的正确性，并注意其对性能的影响

• --repair：用于重新转储（redump）包含未知字符标记（通常显示为 ?）的数据库条目。该功能主要解决数据提取过程中因字符编码或特殊符号解析异常导致的数据显示不全问题

• 🔍核心功能：

• 修复乱码标记：当使用 --dump 导出数据时，若数据库内容包含无法被 SQLMap 自动解码的字符（如二进制数据、特殊编码字符），这些位置会显示为 ?。--repair 会重新尝试解析并转储这些标记部分，尽可能恢复原始数据
• 需配合其他参数使用：--repair 本身不独立执行操作，需与数据提取命令（如 --dump）结合使用

• 此命令在导出数据的同时，强制重试解码所有标记为 ? 的字段

• 适用数据类型：对以下类型的数据修复效果较好

• 二进制大对象（BLOB）
• 非标准编码文本（如某些数据库的私有编码）
• 被截断的字符串字段

• ⚡使用方法：

• 在导出 'users' 表时修复未知字符：sqlmap -u "http://192.168.1.1/login.php" --cookie="sessionid=123"  -D app_db -T users --dump --repair

• ⚠注意事项：

• 成功率依赖字符集支持：若数据库使用的字符集未内置于 SQLMap，修复可能失败。可通过 --charset 手动指定编码（如 --charset=GBK）
• 数据完整性风险：修复过程可能无法完全还原原始数据，尤其对加密或压缩字段。建议优先检查数据库日志确认原始格式
• 替代方案：若修复无效，可尝试：

• 使用 --hex 参数以十六进制格式导出数据，避免字符解码问题
• 直接查询数据库（如 --sql-query "SELECT HEX(field) FROM table"）

• 💡技术背景：此功能源于早期数据库修复工具（如 PC Tools）对乱码数据处理逻辑，通过二次解析尝试匹配字符映射表，但依赖目标数据库的元信息完整性

• --save：用于将当前命令行配置保存到自定义的 INI 格式文件中，便于后续重复调用相同配置，避免重复输入复杂参数

• 🔍核心功能：

• 保存当前配置：--save 会将当前使用的所有命令行选项（如目标 URL、注入技术、风险等级等）写入指定文件，生成 .sqlmap 或 .ini 格式的配置文件

•  sqlmap -u "http://1.1.1.1/vuln.php?id=1" --level=5 --risk=3 --random-agent --save myconfig.sqlmap

• 此命令将 --level=5（测试等级）、--risk=3（风险等级）、--random-agent（随机 User-Agent）等配置保存到 myconfig.sqlmap 文件

• 后续调用配置文件：通过 -c 参数加载已保存的配置，快速复现测试环境

•  sqlmap -c myconfig.sqlmap
• 等同于重新执行原命令的所有参数，无需手动输入，如果目标更改URL需修改

• 适用场景：

• 复杂参数组合：需多次使用包含 --technique（注入技术）、--proxy（代理）等参数的场景
• 批量测试：配合 -m（多目标文件）时，统一配置可提高效率
• 避免重复操作：如绕过 WAF 的 --tamper 脚本配置保存后可直接复用

• ⚡使用方法：

• 保存完整配置并调用：sqlmap -u "http://1.1.1.1/login.php" --data="user=admin&pass=123"  --proxy="http://127.0.0.1:8080" --tamper=space2comment  --save config_proxy.ini  
• sqlmap -c config_proxy.ini

• ⚠注意事项：

• 文件路径与权限：确保保存路径可写（如 /tmp/ 或用户目录），否则可能报错
• 配置覆盖规则：若文件名已存在，新配置会覆盖原文件内容。建议使用唯一文件名（如添加时间戳）
• 不保存敏感信息：密码或 Cookie 等敏感数据需手动处理，避免泄露
• 依赖其他参数：--save 仅保存静态配置，若命令中包含动态参数（如 --fresh-queries），需重新验证其时效性

• 💡替代方案：

• 手动编辑配置：生成的 INI 文件可手动修改（如调整 level 或 risk 值）
• 与 --output-dir 联动：保存配置的同时，用 --output-dir=/path/logs 指定结果输出目录，便于整理报告
• 错误排查：若配置加载失败，检查文件格式是否完整（INI 结构），或使用 -v 3 显示详细调试信息
• 总结：通过 --save 参数，可显著提升复杂注入测试的效率和一致性，尤其适合渗透测试中的重复验证场景

• --scope：主要用于 过滤扫描目标，特别是在批量处理多个 URL 时，通过正则表达式筛选符合特定条件的 URL 进行注入测试

• 🔍核心功能：

• 目标范围过滤：--scope 通过正则表达式（regex）匹配目标 URL，仅对符合条件的 URL 执行扫描

•  sqlmap -l targets.txt --scope "https?://target.com/.*"
• 该命令只扫描 targets.txt 文件中匹配 http://target.com/ 或 https://target.com/ 的 URL

• 多目标场景优化：当配合 -m（批量读取目标文件）或 -g（Google 搜索目标）时，--scope 可大幅减少无效扫描，提升效率

•  sqlmap -g "inurl:php?id=" --scope "vuln.php?id=[0-9]+"
• 仅测试包含数字 ID 参数的 vuln.php 页面

• ⚡使用方法：

• 结合 BurpSuite 日志分析：

• 导出 BurpSuite 代理日志（如 burp_log.txt）
• 使用正则过滤特定路径或参数： sqlmap -l burp_log.txt --scope "/api/.*?token="
• 仅扫描包含 `/api/` 路径且带 `token` 参数的请求

• 批量测试时排除干扰：若目标文件包含非测试页面（如静态资源）

•  sqlmap -m urls.txt --scope ".(asp|aspx|php)?"
• 仅过滤动态页面（ASP/ASPX/PHP），跳过图片或 CSS 文件

• 与代理工具联动：在绕过 CSRF 防护时，限定扫描范围避免误操作

•  sqlmap --proxy="http://127.0.0.1:8080" --scope "login.php"
• 配合 BurpSuite 代理，仅针对登录页面测试

• ⚠注意事项：

• 正则表达式语法：需符合 Python re 模块规范，例如 d 匹配数字，.* 匹配任意字符
• 路径区分大小写：部分服务器对 URL 大小写敏感，正则需覆盖大小写变体（如 [Ll]ogin）
• 文件路径问题：若使用 -l 加载文件，需确保路径正确，否则可能报错 No targets found

• 💡替代方案：若需更复杂的过滤逻辑（如基于响应内容），可结合以下参数

• --crawl：自动爬取站点并扫描，但需谨慎避免过度请求
• --forms：仅测试表单页面，适用于聚焦用户输入点

• 💡总结：通过灵活使用 --scope，可显著提升大规模渗透测试的精准度和效率，尤其适合定向漏洞挖掘场景

• --skip-heuristics：用于跳过启发式检测阶段，直接进入具体的 SQL 注入测试流程。该参数适用于已知目标存在注入点或需要绕过特定干扰的场景，可提升测试效率，但也可能因跳过预检而遗漏部分潜在漏洞

• 🔍核心功能：

• 跳过启发式预检：SQLMap 默认在注入测试前会执行启发式检测（Heuristics），包括：

• 判断目标是否受 WAF/IPS 拦截
• 识别数据库类型、错误消息特征等基础信息
• 检测页面动态性（如参数变化是否影响响应）
• 使用 --skip-heuristics 会跳过这些预检步骤，直接执行 --level 设定的测试等级

• 适用场景：

• 已知注入点：确认目标存在注入漏洞时，避免重复检测以节省时间
• 规避干扰：目标页面包含大量动态内容（如广告、随机元素），启发式检测可能误判
• 绕过特定防御：某些 WAF 对启发式探测敏感，跳过可减少触发拦截的风险
• 性能优化：对大规模目标批量测试时，减少单点耗时

• ⚡使用方法：

• 已知 id 参数存在注入，需快速获取数据：sqlmap -u "http://1.1.1.1/product?id=123"  --skip-heuristics  --dbms=mysql  --level=5  --risk=3  -D app_db -T users --dump

• 作用：跳过预检，直接对 id 进行高级别注入测试，并导出 app_db.users 表数据

• 绕过启发式检测触发的 WAF 拦截：sqlmap -r request.txt  --skip-heuristics  --tamper=space2comment  --random-agent

• 作用：从 Burp 日志加载请求，跳过预检并配合 space2comment 脚本及随机 UA 绕过 WAF

• ⚠注意事项：

• 可能漏报漏洞：启发式检测能识别非常规注入点（如静态参数、Header 注入），跳过后可能遗漏此类漏洞
• 需配合其他参数使用：跳过预检后，需手动指定关键信息确保测试准确性

•  sqlmap -u "http://1.1.1.1/page?id=1" --skip-heuristics --dbms=mysql --level=3

• 不适用于未知目标：若未确认注入点存在，跳过启发式检测可能导致无效测试或误判

• 💡总结：

• 推荐场景：仅在确认注入点存在且启发式检测成为瓶颈时使用，如高频 WAF 拦截或批量测试
• 避免场景：对未知目标或需全面检测时，禁用此参数以确保完整性
• 替代方案：若需优化性能，可改用 -o（一键优化）或 --threads（多线程）

• --skip-waf：用于绕过 Web 应用防火墙（WAF）检测的关键参数，通过忽略 WAF 的拦截机制提升注入成功率

• 🔍核心功能：

• 跳过 WAF 检测机制：默认情况下，sqlmap 会自动探测目标是否存在 WAF（如 Cloudflare、安全狗等），并尝试绕过。但部分严格场景下，主动禁用 WAF 检测逻辑（--skip-waf）可减少误判，直接执行注入测试
• 降低请求特征可见性：避免生成易被 WAF 识别的试探性 payload（如 1' AND 1=1），减少触发规则的概率

• ⚡使用方法：

• 基础使用： sqlmap -u "http://1.1.1.1/page?id=1" --skip-waf

• 配合其他绕过技术增强隐匿性： sqlmap -u "http://1.1.1.1/page?id=1" --skip-waf --tamper=space2comment --random-agent
• 绕过安全狗 WAF：sqlmap -u "http://192.168.0.220/page?id=1" --skip-waf --tamper=space2comment,between --delay=2 --dbms=MySQL

• space2comment 将空格转为 /**/ 避开关键词过滤
• between 替换比较符（如 > 转为 BETWEEN AND）
• --delay 降低请求频率防止触发速率限制

• 🛠关键组合参数与技巧：

• ⚠注意事项：

• 可能增加误报风险：跳过 WAF 检测后，sqlmap 可能发送高危 payload 导致目标服务异常或 IP 封禁，需谨慎评估
• 并非万能解决方案：部分 WAF（如阿里云云盾）需结合特定混淆脚本（如 space2mssqlblank, charencode），仅靠 --skip-waf 无法完全绕过
• 优先尝试自动检测：建议先确认防护类型，再针对性选择绕过策略

• 📚替代方案参考：若 --skip-waf 无效，可尝试

• 自定义 tamper 脚本：修改 payload 编码（如 Base64、Unicode），参考脚本库路径：/usr/share/sqlmap/tamper/
• 分块传输编码：启用 --chunked 拆分请求包
• 时间盲注优化：调整 --time-sec 降低延迟阈值，避免长时等待超时

• 💡总结：--skip-waf 适用于快速跳过基础 WAF 检测，但对抗高级防护需结合混淆脚本、流量隐匿等策略。建议优先使用 sqlmap 内置的 --tamper 脚本库（如 equaltolike, space2dash）并实时更新工具版本以适配新型 WAF

• --table-prefix：用于自定义临时表命名前缀的参数，主要解决 SQL 注入测试过程中临时表与数据库原有表冲突或规避安全机制的问题(没测出来，临时表不知道在哪)

• 🔍核心功能：

• 临时表前缀自定义：SQLMap 在执行复杂注入操作（如系统表查询、数据中转）时会自动创建临时表存储中间结果。--table-prefix=T.. 允许用户指定这些临时表的前缀（如 T_temp_data），避免与业务表重名，同时减少被 WAF/IDS 识别为恶意操作的风险
• 默认值与覆盖规则：

• 默认前缀为 sqlmap（例如 sqlmapoutput）
• 用户可通过 --table-prefix=自定义前缀 修改（如 --table-prefix=tmp_）

• ⚡使用方法：

• 规避关键词拦截：若目标数据库过滤 sqlmap 等敏感词，改用非常规前缀（如 xyz_）可绕过检测

•  sqlmap -u "http://1.1.1.1/vuln.php?id=1" --table-prefix="xyz_"

• 多任务并发隔离：同一数据库同时运行多个 SQLMap 任务时，为每个任务分配独立前缀避免临时表冲突

•  任务1：sqlmap -u "http://target.com/pageA?id=1" --table-prefix="task1_" 
• 任务2：sqlmap -u "http://target.com/pageB?id=2" --table-prefix="task2_"

• 清理痕迹：测试结束后，通过前缀快速定位并删除所有临时表

•  DROP TABLE IF EXISTS tmp_*; -- 需手动执行

• ⚠注意事项：

• 前缀命名规范：

• 需符合数据库标识符规则（如不含空格、特殊字符）
• 建议使用下划线连接（例：audit_temp），避免与业务表混淆

• 与其他参数协作：结合 --hex 或 --tamper 进一步规避安全设备，配合 --purge 自动清理历史临时表（需谨慎）
• 临时表生命周期：SQLMap 创建的临时表通常在会话结束后保留（除非显式删除），需手动维护以避免数据库膨胀

• 💡总结建议：

• 适用场景：需规避安全检测、多任务并行或严格管理临时表时
• 替代方案：若仅需避免表名冲突，可直接用 --hex 导出十六进制数据（不生成临时表）
• 最佳实践：前缀长度建议 3-8 字符，并添加时间戳（如 tmp_0617_）便于追踪

• --test-filter：用于 筛选具体 Payload 类型 的参数，通过指定关键字（如 ROW、BENCHMARK 等）过滤测试用例，从而精细化控制注入检测范围

• 🔍核心功能：

• 精准过滤测试 Payload：默认情况下，sqlmap 会遍历所有预定义的 SQL 注入测试载荷（如布尔盲注、时间盲注、报错注入等）。--test-filter 可指定仅测试特定类型的 Payload，例如筛选与行操作相关的注入（ROW）或性能测试类（BENCHMARK）
• 提升检测效率：跳过无关 Payload 可减少请求次数，避免触发目标系统的冗余告警或封禁机制，尤其适用于需隐蔽测试的场景

• ⚡使用方法：

• 针对性漏洞验证：当已知目标存在特定类型注入漏洞（如基于报错的注入、基于联合查询注入）时，直接筛选相关 Payload 进行验证

•  sqlmap -u "http://1.1.1.1/page?id=1" --test-filter="ERROR"

• sqlmap -u "http://1.1.1.1/page?id=1" --test-filter="UNION"

• 避开高风险 Payload：避免测试可能引发服务异常的 Payload（如 BENCHMARK 可能导致数据库负载激增）

•  sqlmap -u "http://1.1.1.1/page?id=1" --test-skip="BENCHMARK" --test-filter="UNION"
• 注：--test-skip 用于排除指定 Payload，常与 --test-filter 组合使用

• 与混淆脚本联用：结合 --tamper 脚本绕过 WAF 规则，同时限定 Payload 类型

•  sqlmap -u "http://1.1.1.1/page?id=1" --test-filter="TIME" --tamper=space2comment

• ⚠注意事项：

• 需熟悉 Payload 分类关键字：sqlmap 的 Payload 按技术类型标记，常用关键字包括

• BOOL（布尔盲注）、TIME（时间盲注）、ERROR（报错注入）
• UNION（联合查询）、STACK（堆叠注入）、ROW（行操作）
• 若不明确关键字，可查阅 sqlmap 的 data/xml/payloads 目录下的预定义文件

• 可能遗漏漏洞类型：过度筛选可能导致未覆盖的注入点未被检测（如仅测试 UNION 时错过时间盲注漏洞）
• 兼容性限制：部分 Payload 仅适用于特定数据库（如 ROW 类多用于 MySQL），需结合 --dbms 指定数据库类型

• 📚替代方案参考：若需更灵活的 Payload 控制，可尝试

• 自定义 Payload 文件：修改 xml/payloads/*.xml 中的测试用例，按需增删后通过 --test-file 加载
• 结合 --level 和 --risk：调整检测深度与风险等级（如 --level=3 --risk=2），间接控制 Payload 范围

• 💡总结：--test-filter 适合对 SQL 注入技术原理较熟悉的场景，通过精确过滤提升测试效率。常规渗透测试建议优先使用默认全量检测（省略该参数），再根据结果针对性验证

• --test-skip：用于 跳过指定类型注入测试 的关键参数，通过排除特定 Payload（如 BENCHMARK、ERROR 等）减少无效请求，提升检测效率或规避风险

• 🔍核心功能：

• 精准过滤高危或无效测试：默认 sqlmap 会遍历所有预定义的注入测试（布尔盲注、报错注入等），--test-skip 可排除特定关键字标识的 Payload（如跳过 BENCHMARK 避免数据库负载激增）
• 提升隐蔽性与效率：减少触发 WAF 告警或速率限制的概率，尤其适用于需规避高风险操作的场景（如生产环境测试）

• ⚡使用方法：

• 规避服务异常风险：跳过可能引发目标服务崩溃的高危 Payload（如 BENCHMARK 或复杂堆叠查询）

•  sqlmap -u "http://1.1.1.1/page?id=1" --test-skip="BENCHMARK,STACK"

• 针对性漏洞验证：结合 --test-filter 限定测试范围（如仅测 UNION 注入时跳过其他类型）

•  sqlmap -u "http://1.1.1.1/page?id=1" --test-filter="UNION" --test-skip="TIME,ERROR"

• 绕过 WAF 干扰：排除易被 WAF 拦截的 Payload 类型（如 ROW 操作符），并与混淆脚本联用

•  sqlmap -u "http://1.1.1.1/page?id=1" --test-skip="ROW" --tamper=space2comment

• ⚠注意事项：

• 关键字需匹配 sqlmap 内部标识：Payload 分类关键字需与 sqlmap 的 data/xml/payloads 目录下预定义文件一致（如 BOOL、UNION、ERROR 等），错误关键字将导致跳过失效
• 过度跳过可能遗漏漏洞：若跳过过多类型（如同时排除 TIME 和 ERROR），可能漏检时间盲注或报错注入点，建议结合 --level 和 --risk 调整检测粒度
• 数据库兼容性限制：部分 Payload 仅适用特定数据库（如 ROW 多用于 MySQL），需通过 --dbms 指定类型确保跳过有效性

• 📚替代方案：

• 自定义 Payload 文件：直接编辑 xml/payloads/*.xml 文件删除需跳过的测试项，通过 --test-file 加载配置
• 动态调整检测等级：降低 --level（如设为 2）可减少部分高危 Payload，但粒度不如 --test-skip 精准
• 结合日志分析优化：使用 -v 3 查看详细请求日志，识别无效 Payload 后动态更新跳过列表

• 💡总结：--test-skip 适合对 SQL 注入技术较熟悉的场景，通过排除干扰项提升测试效率。常规渗透建议先全量扫描（无过滤参数），再根据初筛结果针对性跳过高危或冗余测试项

• --time-limit：用于 设定扫描任务最大运行时长 的参数，通过强制终止超时任务来避免资源过度消耗或触发目标系统的防护机制

• 🔍核心功能：

• 控制扫描时长：当扫描大型数据库或复杂注入点时，通过 --time-limit=SECONDS 限制 sqlmap 的运行时间（单位：秒），超时自动终止进程 
• 规避安防策略：避免长时间连续请求触发 WAF/IP 封禁，尤其在高风险环境中减少暴露风险

• ⚡使用方法：

• 渗透测试时间窗口受限：在合规测试或红队演练中，需在规定时间内完成扫描任务

•  限制30分钟：sqlmap -u "http://1.1.1.1/login?user=admin" --time-limit=1800 

• 结合其他隐匿参数：与 --delay（请求延迟）、--proxy（代理轮换）联用，平衡效率与隐蔽性

•  sqlmap -u "http://1.1.1.1/data?id=1" --time-limit=1200 --delay=2 --proxy="http://127.0.0.1:8080"

• ⚠注意事项：

• 可能中断有效扫描：若目标响应缓慢或数据量庞大，强制终止可能导致漏洞未被完全探测（如深层盲注点遗漏）
• 依赖网络与目标性能：实际有效扫描时长受网络延迟、目标服务器负载影响，需预留缓冲时间
• 日志完整性：超时终止后，可通过 -v 3 生成详细日志，结合 --output-dir 保存中间结果供后续分析 

• 📚替代方案：若需完整扫描但受限于时间，可尝试

• 分阶段扫描：先用 --level=1 --risk=1 快速初筛，再针对高危点深度测试
• 任务拆分：按数据库或表分区扫描（如 -D dbname -T tablename），分批执行

• 💡 参数组合策略：

• 💡总结：--time-limit 是平衡效率与安全的实用参数，尤其适合 时间敏感型任务 或 规避安防的场景，但需合理评估目标规模避免漏检。建议搭配日志记录与分阶段策略提升覆盖率

• --unsafe-naming：用于 禁用 DBMS 标识符转义 的参数，主要应用于处理非标准命名的数据库对象（如表名、列名含特殊字符）

• 🔍核心功能：

• 禁用标识符转义：默认情况下，sqlmap 会对数据库标识符（如表名、列名）进行转义处理（如添加引号），确保符合目标数据库的命名规范。使用 --unsafe-naming 后，sqlmap 将直接使用原始名称，不进行任何转义处理
• 典型场景：目标数据库的表名/列名包含空格、保留字（如 order、user）或特殊符号（如 @、#），转义可能导致语法错误或探测失败
• 提升兼容性：部分老旧或非主流数据库系统对标识符的解析规则宽松，禁用转义可避免因过度转义引发的查询失败

• ⚡使用方法：

• 处理含空格的表名：目标表名为 user data，默认转义为 "user data"，但目标数据库实际要求直接使用原始名称

• sqlmap -u "http://1.1.1.1/page?id=1" --tables --unsafe-naming

• 绕过非标准命名限制：列名包含 @timestamp，转义后变为 "@timestamp" 导致查询失败

• sqlmap -u "http://1.1.1.1/page?id=1" -D testdb -T log -C @timestamp --dump --unsafe-naming

• 联合其他参数规避安防：配合随机 User-Agent 和延时降低请求特征

• sqlmap -u "http://1.1.1.1/page?id=1" --unsafe-naming --random-agent --delay=2

• ⚠注意事项：

• 语法错误风险：若标识符包含 SQL 保留字（如 SELECT、WHERE）或特殊字符，未转义直接使用可能导致 SQL 语句语法错误，甚至触发数据库报错机制

• 示例：表名 order 未转义时，查询可能被解析为 SELECT * FROM order（语法错误），正确应为 SELECT * FROM "order"

• WAF 绕过局限性：非转义的标识符可能被 WAF 规则识别为恶意负载（如包含 union、select 等关键词），需配合 --tamper 脚本（如 space2comment）或 --skip-waf 增强隐蔽性
• 依赖目标数据库特性：该参数对 MySQL、PostgreSQL 等主流数据库有效，但部分 DBMS（如 SQLite）可能无需转义，实际效果需结合目标环境验证

• 📚替代方案：

• 优先验证标识符规范：使用  -v 3 查看 sqlmap 自动转义后的标识符，确认是否因转义引发问题再启用本参数
• 手动指定转义符：部分数据库支持自定义转义符（如 MySQL 的反引号 `），可通过 --prefix/--suffix 手动添加

•  sqlmap -u "http://1.1.1.1/page?id=1" --prefix="`" --suffix="`"

• 谨慎用于生产环境：在未明确目标数据库命名规则时，禁用转义可能导致不可预知的查询失败，建议仅在测试环境或已知命名规则后使用

• 💡总结：--unsafe-naming 是 处理非标准数据库命名的应急方案，适用于转义机制与目标 DBMS 不兼容的场景。其核心价值在于提升特殊标识符的兼容性，但需警惕语法错误与安防风险。建议优先通过 --tamper 脚本或手动转义优化查询，仅在必要时启用此参数

• --web-root：用于指定目标网站根目录绝对路径的参数，主要在文件写入或操作系统交互时确保路径有效性

• 🔍核心功能：

• 定位Web可写路径：当通过 --file-write 上传文件或 --os-shell 获取交互式 shell 时，需明确 Web 服务器文档根目录（如 /var/www/html），否则文件可能无法通过 URL 访问

• 例如：上传 Webshell 到 /var/www/html/shell.php 后，可通过 http://1.1.1.1/shell.php 访问

• 避免路径猜测错误：默认情况下，sqlmap 尝试常见路径（如 /var/www、C:inetpub），但不同服务器配置差异大，手动指定可提高成功率

• ⚡使用方法：

• 写入Webshell或文件：需结合 --file-write（本地文件路径）和 --file-dest（目标服务器路径），并确保 --web-root 正确指向可访问目录

•  Linux(未测，如果无法写入，可尝试绝对路径，见Window)：sqlmap -u "http://1.1.1.1/page?id=1" --file-write=/local/shell.php --file-dest=/uploads/shell.php --web-root=/var/www/html
• 此处 --file-dest 需在 --web-root 的子目录下（如 /var/www/html/uploads/）
• Windows：sqlmap -u "http://1.1.1.1/page?id=1" --batch --file-write=/root/1.php --file-dest="C:phpstudy_proWWWsqli-labsLess-1shell.php" --web-root="C:phpstudy_proWWWsqli-labsLess-1"

• 获取交互式Shell（--os-shell）：当利用数据库写权限获取系统 shell 时，需指定 Web 根目录生成临时脚本

•  sqlmap -u "http://1.1.1.1/page?id=1" --os-shell --web-root=/var/www/html
• 执行后 sqlmap 会在 /var/www/html/ 下生成临时脚本（如 tmpbwqg.php），通过 URL 调用实现命令执行

• ⚠注意事项：

• 依赖路径可写权限：需确保 Web 服务账户（如 www-data、apache）对目标目录有写权限，否则文件写入失败
• 路径格式兼容性：Windows 系统需使用反斜杠和盘符（如 C:inetpubwwwroot），Linux 区分大小写（如 /var/www ≠ /Var/WWW）
• 与数据库权限联动：写入文件要求数据库用户具备 FILE 权限（MySQL）且 secure_file_priv 配置允许目标路径

• 📚参数组合：

• 💡路径探测替代方案：若未知 Web 根目录，可尝试以下方法

• 利用报错信息：触发数据库报错（如 ' AND 1=CONVERT(int,@@version)--），可能泄露路径
• 查询服务器变量：通过 SQL 查询获取路径（如 MySQL 的 @@datadir 或 PHP 的 $_SERVER['DOCUMENT_ROOT']），需具备 SQL 执行权限
• 默认路径遍历：

• Linux: /var/www/html, /srv/www, /usr/share/nginx/html
• Windows: C:inetpubwwwroot, D:xampphtdocs

• 💎总结：--web-root 是 sqlmap 文件操作和系统交互的关键路径配置参数，需严格匹配服务器环境。实际渗透中建议先通过信息收集（如报错、配置文件泄露）确认路径，再结合 --file-write 或 --os-shell 实现深入利用

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