Sqlmap全参数讲解之第二篇

Request：请求设置

• -A：自定义 HTTP 请求的 User-Agent 头，常用于绕过 WAF 对默认 User-Agent 的拦截或模拟特定客户端请求

• 模拟移动端请求：sqlmap -u "URL
  
  " -A "Mozilla/5.0 (iPhone; CPU iPhone OS 14_7_1)"
• 可使用--random-agent参数替代-A（自动从内置列表中随机选择 User-Agent）

• -H：自定义 HTTP 请求头，可绕过 WAF 拦截、模拟特定客户端或处理会话验证

• 注意事项：

• 命令行 -H 参数会覆盖配置文件中的 headers 设置
• 若需复用头配置，建议写入配置文件
• 多请求头需分多次指定 -H，或使用 n 分隔（在配置文件中）
• 避免使用 sqlmap 默认请求头特征，可通过 --random-agent 随机化 User-Agent
• 配合 --delay=2 和 --timeout=15 模拟正常用户请求间隔
• 常规测试：-H "User-Agent: ..." + --proxy
• 复杂场景：-H + --eval 动态生成签名或令牌
• 深度渗透：结合 --tamper 脚本和 --level=5

• 基础语法：

• sqlmap -u "URL
  
  "  -H "X-API-Key: 12345" -H "Cookie: session=abcde"
• 绕过请求头验证：sqlmap -u "URL" -H "Authorization: Bearer token123"
• 伪造来源头：sqlmap -u "URL" -H "Referer: 
  
  https://google.com"
• 维持已认证会话Cookie：sqlmap -u "URL" H "Cookie: PHPSESSID=abcd1234"

• 组合策略：

• 多请求头叠加（模拟真实用户的地理位置和语言偏好）：sqlmap -u "URL" -H "X-Forwarded-For: 1.1.1.1" -H "Accept-Language: en-US"
• 组合动态脚本（动态生成签名头，绕过签名校验）：sqlmap -u "URL" --eval="import hashlib; print('X-Sign: '+hashlib.md5('data').hexdigest())"
• 代理调试头与头修改：sqlmap -u "URL" -H "User-Agent: TestBot/1.0" --proxy=
  
  http://127.0.0.1:8080

• 注入含动态令牌的接口：sqlmap -u "URL" -H "X-Token: $(date +%s)" --data="user=admin" --level=5

• 使用 $(date +%s) 生成时间戳令牌（需在 Linux/macOS 的 Shell 中运行）
• --level=5 启用深度检测以覆盖复杂注入点

• --method=<HTTP方法>：指定请求方法，如POST/GET/PUT/DELETE/PATCH等

• 注意事项：

• 若方法为 POST/PUT/PATCH，需用 --data 指定请求体内容（即使为空），否则可能报错 Request body is empty
• 非表单请求（如 JSON/XML）需通过 --headers 指定类型：--headers="Content-Type: application/xml"
• 某些方法（如 PUT）不支持重定向，需禁用跟随跳转：--ignore-redirects

• 方法：

• GET方法：sqlmap -u "
  
  http://192.168.137.11/sqli-labs/Less-1/?id=1" --method=GET
• POST 方法：sqlmap -u "
  
  http://192.168.137.11/sqli-labs/Less-1/?id=1"  --method=POST --data="user=admin&pass=123"
• POST+JSON方法：sqlmap -u "
  
  http://192.168.137.11/sqli-labs/Less-1/?id=1" --method=PUT --data='{"value":"inject"}' --headers="Content-Type: application/json"
• DELETE方法：sqlmap -u "
  
  http://192.168.137.11/resource/9" --method=DELETE

• --data：把数据以POST方式提交

• sqlmap -u "
  
  http://192.168.137.11/sqli-labs/Less-1/?id=1"  --method=POST --data="user=admin&pass=123"
• 举例：

• 基础用法：sqlmap -u "
  
  http://example.com/login.php" --data="username=admin&password=123"
• 指定注入参数：sqlmap -u "
  
  http://example.com/login.php" --data="username=admin&password=123" -p password
• 排除参数：sqlmap -u "
  
  http://example.com/login.php" --data="username=admin&password=123" --skip=username
• 处理JSON格式：sqlmap -u "
  
  http://api.example.com" --data='{"id":1}' --headers="Content-Type: application/json"
• 处理XML格式：sqlmap -u "
  
  http://api.example.com" --data='<query><id>1</id></query>' --headers="Content-Type: application/xml"

• --param=<正则表达式>：当GET或POST的数据需要用其他字符分割测试参数的时候需要用到此参数（新版本整体没测出来，旧版本未测，有感兴趣的可以根据下面的语句进行测试下）

• 举例：

• 仅测试以 `id` 或 `user` 开头的参数：sqlmap -u "
  
  http://example.com?uid=1&token=abc" --param="^(id|user).*"
• 排除 `csrf` 相关参数：sqlmap -u "
  
  http://example.com/login" --data="user=admin&csrf=xyz" --param-exclude="csrf"
• 包含 `price` 且排除 `_token` 的参数：sqlmap -u "http://shop.com?price=10&_token=abc" --param="price" --param-exclude="_token"
• 测试路径参数：sqlmap -u "
  
  http://api.com/user/123" --param="d+$" （匹配数字结尾的路径）
• 过滤时间戳参数：sqlmap -u "
  
  http://site.com?ts=123456&q=test" --param-exclude="ts"
• 批量处理动态参数名：sqlmap -u "
  
  http://api.com/search?q=test&filter_*" --param="filter_.*"

• 新版本无此参数，改为下面两个参数

• --param-filter：正则匹配需测试的参数

• 仅测试以 `id` 或 `user` 开头的参数（没测出来）：python sqlmap.py -u "
  
  http://192.168.137.11/sqli-labs/Less-1/?id=1" --param-filter="^(id|user).*"

• -param-exclude：排除不需要测试的参数（没测出来）

• python sqlmap.py -u "
  
  http://192.168.137.11/sqli-labs/Less-1/?id=1&token=abc" --param-exclude="token"

• --param-del：指定 HTTP 请求参数的分隔符，适用于目标网站使用非标准分隔符（如 ; 或 |）的场景

• 注意事项：

• --param-del 需与 --data 或 --form-string 配合使用，对 URL 查询参数（如 ?a=1&b=2）无效
• 若目标同时使用多种分隔符（如 & 和 ;），需通过多次测试确定实际分隔符

• 特殊字符（如 | 或 %00）需根据 Shell 环境转义：

• Linux/macOS：--param-del="|"
• Windows：--param-del="|"

• 解析非标准分隔符的请求参数，确保 SQL 注入检测逻辑正确执行
• 支持绕过基于分隔符规则的安全防护机制
• 常规测试：结合 --proxy 捕获请求，确认实际分隔符后再设置 --param-del
• 深度渗透：配合 --tamper 脚本和 --eval 动态生成参数

• 基础语法：

• 处理非标准分隔符（正确解析 `|` 分隔的参数，避免注入检测失败）：python sqlmap.py -u  "URL" --data="name=test|id=1" --param-del="|"
• 绕过WAF过滤规则（使用空字节 `%00` 分隔参数，绕过基于字符串匹配的防护）：python sqlmap.py -u  "URL" --data="key=value%00token=abc" --param-del="%00"

• 组合策略：

• 混合 GET/POST 参数（同时处理 URL 查询参数和 POST 数据的分隔符）：python sqlmap.py -u  "URL" --data="user=admin;role=root" --param-del=";"
• 解析分号分隔的 POST 数据：python sqlmap.py -u  "URL" --method=POST --data="username=admin;password=123" --param-del=";"
• 动态参数生成（动态生成带唯一分隔符的参数，避免重复请求被拦截）：python sqlmap.py -u  "URL" --eval="import uuid; print(f'session={uuid.uuid4()}')"

• --load-cookies：从文件获取cookie（新版本没做出来，只不过这个参数也不那么重要，可以使用--cookie参数替代）

• 导出Cookie插件：
  
  https://chromewebstore.google.com/detail/editthiscookie/cmbkolgnkghmgajbbapoicfhjlabmpef?hl=zh
• python sqlmap.py -u "http://192.168.137.11/sqli-labs/Less-20/index.php" --load-cookies=1.txt --level=2#没做出来

•  --cookie-del：指定 Cookie 参数的分隔符，适用于目标网站使用非标准分隔符（如 , 或 |）的场景

• 注意事项：

• 特殊字符（如 | 或 %00）需根据 Shell 环境转义：

• Linux/macOS：--cookie-del="|"
• Windows：--cookie-del="|"

• 解析非标准分隔符的请求参数，确保 SQL 注入检测逻辑正确执行
• 支持绕过基于分隔符规则的安全防护机制
• 常规测试：结合 --proxy 捕获请求，确认实际分隔符后再设置 --cookie-del
• 深度渗透：配合 --tamper 脚本和 --eval 动态生成参数

• 基础语法：

• 解析逗号分隔的 Cookie：python sqlmap.py -u "URL" --cookie="session=abcd,role=admin" --cookie-del=","
• 绕过特殊字符过滤：python sqlmap.py -u "URL" --cookie="id=1|auth=yes" --cookie-del="|"

• 组合策略：

• 混合 GET/POST 参数（同时处理 URL 查询参数和 POST 数据的分隔符）：python sqlmap.py -u  "URL" --cookie="user=admin,auth=true" --cookie-del=","
• 动态参数生成（动态生成带唯一分隔符的参数，避免重复请求被拦截）：python sqlmap.py -u  "URL" --eval="import random; print(f'cookie=test{random.randint(1,100)}')"

•  --live-cookies：用于加载最新值的实时 cookie 文件（好像没啥用，除非脚本能自动把Cookie发送给Sqlmap，不然直接使用--cookie参数就行）

• 工作原理：

• 需要配合 tampermonkey 插件，需编写脚本动态获取 cookies 并提供给 sqlmap（支持的浏览器：Firefox/Chrome）
• sqlmap 会实时从浏览器中抓取最新的 cookies
• 在扫描过程中自动更新 cookies，确保会话始终有效

• 配置方法：

• 安装 tampermonkey插件（支持浏览器扩展）
• 启动浏览器并登录目标网站，保持登录状态
• 在 sqlmap 中使用 --live-cookies 参数

• 注意事项：

• 确保浏览器和 sqlmap 使用相同的 DNS 配置
• 部分现代网站可能设置 SameSite Cookie 属性，可能会影响 cookie 获取
• 对性能有一定开销（需实时与浏览器交互）

•  --load-cookies：从文件加载 Cookie 数据的关键参数，适用于需要维持会话状态或绕过认证的渗透测试场景

• 使用场景：

• 维持登录会话：从浏览器导出已认证的 Cookie 文件，加载后无需重复登录即可测试需认证的接口
• 批量处理多Cookie：支持加载包含多个 Cookie 键值对的文件，避免手动输入复杂 Cookie
• 绕过动态令牌验证：配合动态生成的 Cookie 文件（如含时效性 Token），实现自动化注入测试

• 支持格式：

• Netscape 格式（常见于浏览器导出或 curl -c 生成）

# Netscape 格式示例  .example.com  TRUE  /  TRUE  0  session  abc123  .example.com  TRUE  /  TRUE  0  token    xyz789

• 简化格式：仅包含 key=value 对，每行一个（需确保无额外元数据）

 # 简化格式示例（直接键值对）   session=abc123   token=xyz789

• 使用语法：

• sqlmap -u "URL" --load-cookies=cookies.txt --level=3 --risk=3 --batch

• --drop-set-cookie：忽略服务器在响应中设置的 cookie，即不让这些 cookie 被后续的请求所携带，从而避免这些 cookie 对测试过程产生不必要的影响

• 语法使用：

• sqlmap -u "URL"  --drop-set-cookie

• 使用场景：

• 假设你要测试一个网页应用程序是否存在 SQL 注入漏洞，当你向目标 URL 发送请求时，服务器返回了一个包含 Set-Cookie 头的响应，该 cookie 可能用于会话跟踪或其他功能。如果不使用 --drop-set-cookie 参数，sqlmap 会在后续的测试请求中自动携带这个 cookie。但在某些情况下，这个 cookie 可能会导致 sqlmap 的测试请求被服务器以特殊的方式处理，从而干扰对 SQL 注入漏洞的准确检测。此时，使用 --drop-set-cookie 参数就可以让 sqlmap 不理会这个 cookie，确保测试过程的纯粹性和准确性

• --cookie：设置cookie，提交请求的时候附带所设置的cookie

• 这个参数在以下两个方面很有用：

• web应用需要登陆的时候
• 你想要在这些头参数中测试SQL注入时

• 举例：

• 基本语句：python sqlmap.py -u "
  
  http://192.168.137.11/sqli-labs/Less-20/?id=1" --cookie="uname = admin "

• 测试指定Cookie：python sqlmap.py -u "
  
  http://192.168.137.11/sqli-labs/Less-20/?id=1" --cookie="uname=admin"  -p uname

• 处理动态Token：python sqlmap.py -u "
  
  http://192.168.137.11/sqli-labs/Less-20/?id=1" --cookie="token=xxx" --csrf-token=token
• 处理动态Token：python sqlmap.py -u "
  
  http://192.168.137.11/sqli-labs/Less-20/?id=1" --cookie="token=xxx" --csrf-token=token --eval="token=get_token()"

• --http2：用于强制使用 HTTP/2 协议通信的参数，适用于目标服务器支持 HTTP/2 的场景（没做出来，需要支持的条件较多）

• 使用场景：

• 利用 HTTP/2 性能优势：在支持 HTTP/2 的服务器上，利用多路复用、头部压缩等特性加速检测过程
• 绕过HTTP/1.1限制：某些 WAF 对 HTTP/1.1 的检测规则更严格，改用 HTTP/2 可能绕过部分过滤
• 兼容性测试：某些 WAF 对 HTTP/1.1 的检测规则更严格，改用 HTTP/2 可能绕过部分过滤

• 前置条件：

• SQLMap 的 HTTP/2 支持依赖 Python 的 hyper 或 h2 库，需手动安装：python -m pip install hyper
• 如果使用代理，代理需支持HTTP/2
• 目标服务器需要支持 HTTP/2：curl -I --http2 URL
• httpx版本需要大于0.28：

• 升级版本：python -m pip install --upgrade "httpx>=0.28"
• 验证版本：python -c "import httpx; print(httpx.__version__)"

• 语法使用：

• python sqlmap.py -u  "URL" --http2 --level=3 --risk=3 --proxy=
  
  http://127.0.0.1:8080#通过代理工具（如 Wireshark 或支持 HTTP/2 的 Burp Suite）捕获请求，验证协议版本

• --mobile：用于模拟移动设备请求的参数，通过自动切换为移动端 User-Agent 提升测试隐蔽性

• 使用场景：测试移动端页面或规避基于 UA 的 WAF 拦截
• 语法：pyt
  
  hon sqlmap.py -u "http://192.168.137.11/sqli-labs/Less-1/?id=1" --mobile --proxy=http://127.0.0.1:8080 --batch

• --host：用于直接指定数据库服务器地址的参数，通常用于非基于 HTTP 的数据库连接（如直接通过数据库协议注入）

• 使用场景：

• 直接数据库连接：当数据库服务与 Web 应用分离时，直接指定数据库 IP/域名（需配合 -d 模式使用）
• 特殊注入场景：用于时间盲注、堆叠查询等需要直接与数据库交互的攻击类型
• 绕过网络隔离限制：在数据库暴露于公网但 Web 应用无注入点时尝试直接访问

• 前置条件：

• 若目标数据库为 MySQL/MariaDB，SQLMap 需依赖 PyMySQL 驱动进行连接
• 基础安装：-m pip install PyMySQL
• 扩展认证支持：

• python -m pip install PyMySQL[rsa]      # MySQL 8.0+ 的 RSA 加密认证 
• python -m pip install PyMySQL[ed25519]  # MariaDB 的 ed25519 认证

• --host 需与 -d（直接连接模式）一起使用，单独使用无效

• sqlmap -d "mysql://user:password@dbserver:3307/dbname" --host=dbserver

• 语法使用：

• sqlmap -d "mysql://root:[email protected]:3306/dba" --host=192.168.137.101 --dbs

• --user-agent：自定义 HTTP 请求的 User-Agent 头（升级版：--random-agent）

• python sqlmap.py -u "
  
  http://192.168.137.11/sqli-labs/Less-1/?id=1" --user-agent="Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/120.0.0.0 Safari/537.36"

• --random-agent：使用–random-agnet参数来随机的从./data/txt/user-agents.txt中获取。当–level参数设定为3或者3以上的时候，会尝试对User-Angent进行注入

• 举例：

• 绕过 UA 黑名单：python sqlmap.py -u "
  
  http://192.168.137.11/sqli-labs/Less-1/?id=1" --random-agent --delay=2
• 多线程攻击：python sqlmap.py -u "
  
  http://192.168.137.11/sqli-labs/Less-1/?id=1" --random-agent --threads=5
• 代理链配合：python sqlmap.py -u "
  
  http://192.168.137.11/sqli-labs/Less-1/?id=1" --random-agent --proxy="http://127.0.0.1:9999"
• WAF识别特征绕过：python sqlmap.py -u "
  
  http://192.168.137.11/sqli-labs/Less-1/?id=1" --random-agent --tamper=between,space2comment --safe-freq=10

• --proxy=proxy：使用代理连接到目标URL，隐藏真实IP

• 语法：

• 验证代理是否生效：python sqlmap.py -u "
  
  http://192.168.137.11/sqli-labs/Less-1/?id=1" --proxy="http://127.0.0.1:8080" --check-proxy
• HTTP/HTTPS代理：python sqlmap.py -u "
  
  http://192.168.137.11/sqli-labs/Less-1/?id=1" --proxy="http://127.0.0.1:8080"
• SOCKS 代理（需安装 `requests[socks]`：pip install requests[socks]）：python sqlmap.py -u "
  
  http://192.168.137.11/sqli-labs/Less-1/?id=1" -proxy="socks5://127.0.0.1:9050"
• 带认证的代理：python sqlmap.py -u "
  
  http://192.168.137.11/sqli-labs/Less-1/?id=1" --proxy="http://user:[email protected]:8080"
• 绕过IP封禁：python sqlmap.py -u "
  
  http://192.168.137.11/sqli-labs/Less-1/?id=1" --proxy="socks5://tor-proxy:9050" --check-tor
• 多代理轮转：python sqlmap.py -u "
  
  http://192.168.137.11/sqli-labs/Less-1/?id=1" --proxy-file=proxies.txt（文件中每行一个代理地址）

• --proxy-cred：配置代理服务器认证信息的参数，适用于需要通过 HTTP/HTTPS 代理进行渗透测试的场景

• 作用：--proxy-cred 用于向代理服务器提交认证凭证（如用户名和密码），格式为 username:password。当代理服务器需要身份验证时，此参数必不可少
• 依赖参数：需与 --proxy 参数配合使用，后者指定代理服务器地址（如 --proxy="http://127.0.0.1:8080"）
• 举例：sqlmap -u "URL" --proxy="http://192.168.1.100:8080" --proxy-cred="user:pass"

• --proxy：指定代理服务器地址及端口
• --proxy-cred：提供代理认证的账号密码

• 代理类型拓展：

• 支持认证类型：包括 HTTP Basic、Digest 等（需代理服务器支持）
• 多代理轮换：若需使用多个代理，可将代理列表写入文件，通过 --proxy-file 加载

• 与其他参数组合：

• 绕过本地代理设置：

• 使用 --ignore-proxy 忽略系统全局代理配置，强制通过指定代理访问目标
• sqlmap -u "URL" --ignore-proxy --proxy="http://192.168.1.100:8080" --proxy-cred="user:pass"

• 配合 Tor 网络：

• sqlmap -u "URL" --tor --tor-type=SOCKS5 --proxy-cred="tor_user:tor_pass"
• 需额外配置 Tor 客户端认证信息

•  --proxy-file：批量加载代理服务器列表的关键参数，适用于需要频繁切换代理以绕过 IP 封禁或实现流量分散的场景

• 核心功能：

• 代理轮换机制：

• --proxy-file 允许从文本文件中加载多个代理服务器地址（如 http://IP:PORT），sqlmap 会按顺序或随机（结合 --random-agent）使用这些代理发送请求，避免单一 IP 触发防护机制

• 适用场景：

• 隐蔽性测试：绕过目标网站基于 IP 的访问频率限制或 WAF 封锁
• 负载均衡：分散流量至多个代理节点，降低单点故障风险
• 多地域测试：模拟不同地理位置或网络环境的访问行为

• 典型用法：

• 基础命令：

• sqlmap -u "URL" --proxy-file proxies.txt
• proxies.txt 文件格式：每行一个代理地址（支持 HTTP/HTTPS/SOCKS）

http://192.168.1.100:8080socks5://10.0.0.1:1080

• 结合认证参数：

• 若代理需账号密码认证，需配合 --proxy-cred：
• sqlmap -u "URL"  --proxy-file proxies.txt --proxy-cred="user:pass"

• 与其他参数组合：

• 随机化请求特征：sqlmap -u "URL" --proxy-file proxies.txt --random-agent --delay=2
• --random-agent：随机 User-Agent，避免特征检测
• --delay=2：降低请求频率，减少触发风控

• 注意事项：

• 代理文件有效性：

• 确保代理地址可用，建议提前使用 curl 测试连通性：curl -x "http://代理IP:端口" URL
• 若代理需账号密码认证，需通过 --proxy-cred传递

• 性能优化：

• 代理数量：建议文件包含 5-10 个高匿名代理，过多可能导致性能下降
• 超时设置：通过 --timeout=30 调整单次请求超时时间，避免长时间等待

• --proxy-freq：用于 动态切换代理服务器 的参数，适用于需要高频次切换代理以绕过目标网站 IP 封禁或实现流量分散的场景

• 核心功能：

• 代理轮换机制：

• --proxy-freq 允许用户指定每发送 N 个请求后自动切换代理（例如 --proxy-freq=5 表示每 5 个请求更换一次代理）。此功能需结合 --proxy-file（加载代理列表文件）使用，旨在避免单一 IP 触发目标系统的 WAF 或速率限制

• 适用场景：

• 规避封禁：当目标网站对频繁请求的 IP 进行封锁时，通过轮换代理保持连接稳定性
• 负载均衡：分散请求至多个代理节点，降低单点故障风险
• 匿名性增强：防止目标通过 IP 地址追踪渗透测试行为

• 典型用法：

• 基础命令：

• sqlmap -u "URL" --proxy-file proxies.txt --proxy-freq=3
• proxies.txt 文件格式：每行一个代理地址（支持 HTTP/HTTPS/SOCKS）

http://192.168.1.100:8080socks5://10.0.0.1:1080

• --proxy-freq=3：每发送 3 个请求后切换下一个代理

• 组合其他参数增强隐匿性：

• sqlmap -u "URL" --proxy-file proxies.txt --proxy-freq=5 --random-agent --delay=2
• --random-agent：随机化 User-Agent，避免特征检测
• --delay=2：设置请求间隔为 2 秒，减少触发风控的概率

• 注意事项：

• 代理文件有效性：

• 确保代理地址可用，建议提前使用 curl 测试连通性：curl -x "http://代理IP:端口" URL
• 若代理需账号密码认证，需通过 --proxy-cred传递

• 性能优化：

• 请求频率：--proxy-freq 值不宜过小（如 1），否则频繁切换代理会增加请求耗时；建议根据代理响应速度调整为 3-10
• 并发线程：若使用 --threads 多线程，需确保 --proxy-freq 与线程数匹配，避免代理切换冲突

• 与其他代理参数冲突：

• --tor：若使用 Tor 匿名网络，需通过 --tor-type 和 --tor-port 指定代理类型，此时 --proxy-freq 无效
• --ignore-proxy：强制忽略系统代理设置时，需确保 --proxy-file 和 --proxy-freq 未被覆盖

• --tor：使用tor匿名网络

• 前置条件：安装Tor（windows下载：
  
  https://www.torproject.org/download/tor/）
• 使用：

• 基础匿名扫描：python sqlmap.py -u "
  
  http://192.168.137.11/sqli-labs/Less-1/?id=1" --tor
• 指定自定义 Tor 代理（非默认端口）：python sqlmap.py -u "
  
  http://192.168.137.11/sqli-labs/Less-1/?id=1" --tor --tor-port=9150
• 强制验证 Tor 连通性：python sqlmap.py -u "
  
  http://192.168.137.11/sqli-labs/Less-1/?id=1" --tor  --check-tor#输出应为 "All tests passed!"
• 使用 Proxychains 配合 Tor：proxychains python sqlmap.py -u "
  
  http://192.168.137.11/sqli-labs/Less-1/?id=1" --tor 

• --tor-port：指定 Tor 代理端口 的参数，需与 --tor 参数配合使用，以实现通过 Tor 匿名网络进行渗透测试

• 核心功能：

• 端口定义：

• -tor-port 用于设置 Tor 代理的监听端口（默认值因 Tor 客户端类型而异，如 Tor Browser 默认使用 9150，独立 Tor 服务可能使用 9050）
• 当 Tor 客户端未使用默认端口时，需通过此参数手动指定

• 依赖参数：

• --tor：启用 Tor 匿名网络支持
• --tor-type：指定代理类型（如 SOCKS5 或 HTTP），默认 SOCKS5

• 典型用法：

• 基础命令：

• sqlmap -u "URL" --tor --tor-port=9150 --tor-type=SOCKS5
• --tor-port=9150：指定 Tor 代理端口为 9150（适用于 Tor Browser）
• --tor-type=SOCKS5：明确代理协议类型（避免因协议不匹配导致连接失败）

• 结合其他参数增强隐匿性：

• sqlmap -u "URL" --tor --tor-port=9050 --random-agent --delay=3 --check-tor
• --check-tor：验证 Tor 代理是否生效（若返回 Tor is being used 则配置正确）
• --delay=3：降低请求频率，减少触发目标网站风控的概率

• 注意事项：

• 端口冲突：

• 默认端口差异：独立 Tor 服务的默认端口通常为 9050，而 Tor Browser 默认使用 9150。若端口设置错误，sqlmap 会抛出 Proxy connection error
• 验证方法：使用 curl 测试代理连通性：curl --socks5-hostname 127.0.0.1:9150 
  
  https://check.torproject.org

• 若返回 `Congratulations. This browser is configured to use Tor` 则代理配置正确

• 协议匹配：

• SOCKS5 与 HTTP 代理的区别：Tor 默认通过 SOCKS5 协议通信，若需使用 HTTP 代理，需额外配置 Tor 客户端并指定 --tor-type=HTTP

• 性能影响：

• 延迟问题：Tor 网络因多节点跳转而存在较高延迟，建议通过 --delay 调整请求间隔（如 --delay=5）
• 代理稳定性：Tor 节点可能不稳定，可结合 --proxy-file 加载多个 Tor 出口节点提升成功率

• --tor-type：指定 Tor 代理协议类型 的参数，需与 --tor 配合使用，确保通过 Tor 匿名网络进行渗透测试

• 核心功能：

• 协议类型定义：

• --tor-type 用于指定 Tor 代理的通信协议，支持 SOCKS5（默认）、SOCKS4 或 HTTP 类型。不同协议对应不同的网络配置场景：

• SOCKS5：适用于 Tor 浏览器或标准 Tor 客户端（默认端口 9050）
• HTTP：需额外配置 Tor 的 HTTP 代理（如 Privoxy 转发）
• SOCKS4：兼容旧版客户端，但安全性较低

• 依赖参数：

• 需与 --tor 参数组合，并可能需指定端口 --tor-port（如 Tor Browser 默认使用 9150，独立 Tor 服务默认 9050）

• 典型用法：

• 基础命令：

• sqlmap -u "URL" --tor --tor-type=SOCKS5 --tor-port=9050

• --tor-type=SOCKS5：明确指定代理协议类型
• --tor-port=9050：匹配独立 Tor 服务的默认端口

• 验证Tor配置：

• sqlmap -u "URL"  --tor --tor-type=SOCKS5 --check-tor

• --check-tor：若返回 Tor is being used，说明代理配置成功

• 组合其他隐匿参数：

• sqlmap -u "URL" --tor --tor-type=HTTP --random-agent --delay=3

• --random-agent：随机化 User-Agent 避免特征检测
• --delay=3：降低请求频率，减少触发目标网站风控

• 注意事项：

• 协议与端口匹配：

• Tor Browser 默认使用 SOCKS5 协议，端口为 9150；独立 Tor 服务默认端口为 9050。若端口设置错误，会引发 Proxy connection error
• 若需使用 HTTP 代理，需通过工具（如 Privoxy）将 SOCKS5 转换为 HTTP 代理，并指定 --tor-type=HTTP 和对应端口

• 性能与稳定性：

• 延迟问题：Tor 网络因多节点跳转导致高延迟，建议结合 --delay 调整请求间隔（如 --delay=5）
• 代理切换：若需动态切换出口 IP，需修改 Tor 配置文件 torrc，设置 MaxCircuitDirtiness 60（每 60 秒切换 IP）

• 错误排查：

• 认证失败：若使用 HTTP 代理且需身份验证，需额外配置 --proxy-cred（但 Tor 自身通常无需认证）
• 协议冲突：确保 Tor 客户端配置与 --tor-type 一致。例如，若 Tor 仅支持 SOCKS5，强制设为 HTTP 会失败

• --check-tor：验证 Tor 匿名网络配置是否生效 的关键参数。它通过检测当前网络流量是否通过 Tor 节点路由，确保渗透测试的匿名性

• 强制验证 Tor 连通性：python sqlmap.py -u "
  
  http://192.168.137.11/sqli-labs/Less-1/?id=1" --tor  --check-tor#若成功，输出中会显示 Tor connection is established

• --referer：自定义 HTTP 请求的 Referer 头，模拟合法流量来源以绕过 WAF/IDS 检测

•  –level参数设定为3或者3以上的时候会尝试对referer注入
• 举例：

• 伪装可信来源：python sqlmap.py -u "
  
  http://192.168.137.11/sqli-labs/Less-1/?id=1"  --referer="https://baidu.com"
• 模拟内部页面跳转：python sqlmap.py -u "http://192.168.137.11/sqli-labs/Less-1/?id=1"  --referer="http://192.168.137.11/dba"
• CSRF绕过测试：python sqlmap.py -u "http://192.168.137.11/sqli-labs/Less-1/?id=1"  --referer="http://192.168.137.11/dba" --csrf-token=token

• --headers：向 HTTP 请求添加自定义头部，可绕过 WAF/IDS 检测或模拟特定客户端请求（自定义头部仅在 --level >= 3 时被测试）

• 举例：

• 单次设置多个UA头（使用 n 分隔）：python sqlmap.py -u "
  
  http://192.168.137.11/sqli-labs/Less-1/?id=1"  --headers="User-Agent: Mozilla/5.0nX-Forwarded-For: 1.2.3.4"

• 从文件中加载UA头（每行一个键值对）：python sqlmap.py -u "
  
  http://192.168.137.11/sqli-labs/Less-1/?id=1"  [email protected]

• 绕过IP封禁：python sqlmap.py -u "
  
  http://192.168.137.11/sqli-labs/Less-1/?id=1"  --headers="X-Forwarded-For: 192.168.0.$(rand 1-100)"
• 模拟API请求：python sqlmap.py -u "
  
  http://192.168.137.11/sqli-labs/Less-1/?id=1"  --headers="Authorization: Bearer xyz123nContent-Type: application/json"
• 伪装移动端流量：python sqlmap.py -u "
  
  http://192.168.137.11/sqli-labs/Less-1/?id=1"  --headers="User-Agent: Mobile SafarinX-Device-Id: ABC123"
• 动态头部生成：python sqlmap.py -u "
  
  http://192.168.137.11/sqli-labs/Less-1/?id=1" --headers="X-Token: $(openssl rand -hex 12)" --eval="import time; print(f'X-Timestamp: {int(time.time())}')"

•  --auth-type：指定目标网站 HTTP 认证类型 的关键参数，适用于需要身份验证的网页（如登录后才能访问的注入点）

• 核心功能：

• 支持认证类型：

• --auth-type 允许指定以下 HTTP 认证方式：

• Basic：基础认证（明文传输用户名密码）
• Digest：摘要认证（密码哈希传输）
• NTLM：Windows 域环境常用认证（适用于 IIS 服务器）
• PKI：基于证书的认证（需结合 --auth-file 指定证书路径）

• 依赖参数：

• 必须与 --auth-cred 配合使用，后者用于传递认证凭证（格式：username:password）

• 典型用法：

• 基础命令：

• sqlmap -u "URL" --auth-type Basic --auth-cred "admin:admin123"

• --auth-type Basic：指定认证类型为 Basic
• --auth-cred：提供用户名和密码（明文）

• 复杂场景：

• sqlmap -u "URL" --auth-type NTLM --auth-cred "domainuser:pass" --proxy "http://127.0.0.1:8080" --force-ssl

• --proxy：通过代理发送请求（如 Burp Suite）
• --force-ssl：强制使用 HTTPS 协议（避免因协议错误导致认证失败）

• 注意事项：

• 认证有效性验证：

• 若认证失败，sqlmap 会抛出 [CRITICAL] authentication failed。建议先用 curl 测试认证配置是否有效：curl -u "admin:admin123" 
  
  http://192.168.137.101/admin.php

• 协议匹配：

• 若目标网站使用 HTTPS，需显式添加 --force-ssl 或直接指定 HTTPS URL
• PKI 认证需额外指定证书文件路径（如 --auth-file=client.pem）

• 与其他参数冲突：

• --ignore-proxy：若需忽略系统代理，需确保代理配置未覆盖认证参数
• --csrf-token：若目标网站有 CSRF 保护，需结合此参数处理认证流程

•  --auth-cred：用于 传递 HTTP 协议认证凭证 的参数，需与 --auth-type 配合使用，以绕过目标网站的身份验证机制（如登录框或权限限制）

• 核心功能：

• 支持认证类型：

• --auth-type 允许指定以下 HTTP 认证方式：

• Basic：基础认证（明文传输用户名密码）
• Digest：摘要认证（密码哈希传输）
• NTLM：Windows 域环境常用认证（适用于 IIS 服务器）
• PKI：基于证书的认证（需结合 --auth-file 指定证书路径）

• 适用场景：

• 登录后注入：当注入点位于需要登录才能访问的页面（如后台管理接口）时，需通过此参数提供有效凭证
• 绕过权限限制：针对需 HTTP 认证的接口或目录（如 .htaccess 保护的资源）

• 典型用法：

• 基础命令：

• sqlmap -u "URL" --auth-type Basic --auth-cred "admin:admin123"

• --auth-type Basic：指定认证类型为 Basic
• --auth-cred：提供用户名和密码（明文）

• 复杂场景：

• sqlmap -u "URL" --auth-type NTLM --auth-cred "domainuser:pass" --proxy "http://127.0.0.1:8080" --force-ssl

• --auth-type NTLM：适用于 Windows 域环境，需提供域账号格式 domainuser:pass
• --proxy：结合代理工具（如 Burp Suite）捕获请求，验证认证流程
• --force-ssl：强制使用 HTTPS 协议（避免因协议错误导致认证失败）

• 文件请求注入：

• 若目标为 POST 请求且需复用认证信息，可保存 HTTP 请求到文件（如 request.txt），通过 -r 加载：sqlmap -r request.txt --auth-type Basic --auth-cred "test:test"
• 此方式适用于表单登录或 Cookie 动态更新的场景

• 注意事项：

• 认证有效性验证：

• 若凭证错误或认证类型不匹配，sqlmap 会抛出 [CRITICAL] authentication failed。建议先用 curl 测试认证配置是否有效：curl -u "admin:admin123" 
  
  http://192.168.137.101/admin.php

• 协议与参数冲突：

• HTTPS 强制启用：若目标网站强制 HTTPS，需显式添加 --force-ssl 或直接指定 HTTPS URL
• CSRF 保护：若目标页面有 CSRF 令牌，需结合 --csrf-token 动态处理

• 性能优化：

• 高延迟场景：在 Tor 或代理环境下，建议通过 --delay 增加请求间隔（如 --delay=2）
• 多线程限制：避免多线程（--threads）与认证流程冲突，导致会话失效

• 企业级防护绕过：在 NTLM 认证场景中，注意域策略限制（如密码过期或锁定机制）

•  --auth-file：指定客户端证书或私钥文件 的参数，适用于需要双向 TLS/SSL 认证的场景（如基于 PKI 的 HTTPS 站点）

• 核心功能：

• 客户端认证支持：

• --auth-file 用于加载 PEM 格式的证书或私钥文件，实现客户端与服务器的双向身份验证。常见场景包括：

• PKI 认证：需结合 --auth-type=PKI 使用，适用于企业级 HTTPS 服务
• 私有证书认证：部分网站要求客户端提供特定证书才能访问敏感接口

• 文件格式要求：

• PEM 格式：文件需包含证书和私钥（可通过 OpenSSL 生成）
• 示例生成命令：openssl req -x509 -newkey rsa:2048 -nodes -keyout client.key -out client.crt -days 365 cat client.key client.crt > client.pem

• 典型用法：

• 基础命令：

• sqlmap -u "URL" --auth-type=PKI --auth-file=client.pem

• --auth-type=PKI：明确认证类型为基于证书的 PKI
• --auth-file=client.pem：指定 PEM 文件路径

• 结合代理与HTTPS强制验证：

• sqlmap -u "URL" --auth-file=client.pem --proxy="http://127.0.0.1:8080" --force-ssl

• --force-ssl：强制 HTTPS，避免因协议切换导致证书验证失败

• 注意事项：

• 证书有效性验证：

• 格式错误
  
  ：若 PEM 文件格式不规范，sqlmap 会抛出 [CRITICAL] SSL connection error。建议通过 OpenSSL 手动验证：openssl s_client URL:443 -cert client.pem
• 权限问题：确保文件权限为 600（仅当前用户可读写）

• 与其他参数组合：

• --auth-cred：若需同时使用用户名密码和证书认证，需分步处理（如先认证证书，再通过 Cookie 或 Session 传递凭证）
• --ignore-401：若目标网站混合使用认证方式，可配合此参数跳过 401 错误继续测试

• 性能与兼容性：

• 协议支持：仅适用于支持客户端证书的 HTTPS 站点（需服务器配置 ClientCertificate 策略）
• 代理干扰：若通过 Burp Suite 等代理工具，需确保代理配置不剥离或修改证书信息

• 高级绕过策略：若证书认证结合动态令牌（如 OTP），需结合 --csrf-token 处理二次验证

•  --abort-code：设置触发中止的 HTTP 状态码 的参数。当目标服务器返回指定状态码时，sqlmap 将立即终止扫描流程。此参数常用于优化扫描效率或避免触发目标系统的异常响应监控

• 核心功能：

• 中止条件定义：

• --abort-code 通过指定 HTTP 状态码（如 404、500 等），在遇到对应响应时强制停止扫描。例如：sqlmap -u "URL"  --abort-code=500
• 当服务器返回 500 Internal Server Error 时，sqlmap 自动中止，避免无效请求

• 适用场景：

• 规避风控：若目标系统在异常请求时返回特定状态码（如 403 Forbidden），可提前终止以避免 IP 封禁
• 资源优化：跳过无效路径（如 404 Not Found），减少扫描时间

• 与其他参数对比：

• --ignore-code：忽略指定状态码并继续扫描（与 --abort-code 功能相反）
• --retries：设置失败重试次数，适用于偶发性错误（如网络波动）

• 注意事项：

• 状态码范围：

• 仅支持标准 HTTP 状态码（如 2xx 表示成功，4xx 表示客户端错误，5xx 表示服务端错误）
• 多状态码需逗号分隔：--abort-code=404,503

• 误判风险：

• 若目标系统正常业务逻辑返回非 200 状态码（如 302 重定向），需谨慎设置，避免遗漏有效注入点

• 性能影响：

• 频繁中止可能影响扫描完整性，建议结合日志分析（-v 3 显示详细请求）验证中止原因
• 若需动态调整中止策略，可结合 --flush-session 清空缓存后重新扫描，或通过 --safe-url 指定健康检查接口以维持会话状态

•  --ignore-code：用于忽略特定 HTTP 状态码 的参数。当目标服务器返回指定状态码时，sqlmap 会跳过对这些响应的错误处理，继续执行注入测试。此参数常用于绕过因权限限制或临时错误导致的扫描中断，提升渗透测试的稳定性

• 核心功能：

• 忽略错误状态码：

• 通过指定 HTTP 状态码（如 401、403、500 等），sqlmap 会跳过这些响应，避免因权限不足或服务端错误导致扫描终止
• sqlmap -u "URL" --ignore-code=401,403

• 适用场景：

• 目标网站存在临时权限验证（如登录失效返回 401）或 WAF/IP 封禁（返回 403）时，强制继续测试

• 与 --abort-code 的对比：

• --abort-code：遇到指定状态码时终止扫描
• --ignore-code：忽略指定状态码，继续扫描

• 典型用法：

• 基础命令：

• sqlmap -u "URL"  --ignore-code=401
• 作用：当目标页面因未授权返回 401 时，sqlmap 会绕过此错误继续测试注入点

• 组合其他参数优化扫描：

• sqlmap -u "URL"  --ignore-code=500  --force-ssl  --proxy="http://127.0.0.1:8080"

• --force-ssl：强制使用 HTTPS，避免因协议错误触发 500 状态码
• --proxy：结合代理工具（如 Burp Suite）分析请求响应，验证忽略策略是否生效

• 多状态忽略：

• sqlmap -r request.txt --ignore-code=401,403,404
• 适用场景：处理复杂权限体系（如多级认证）或资源路径频繁变更的情况

• 注意事项：

• 状态码范围与格式：

• 仅支持标准 HTTP 状态码（如 2xx、4xx、5xx）
• 多个状态码需用逗号分隔，如 --ignore-code=401,503

• 误判风险：

• 若忽略的代码与业务逻辑相关（如 302 重定向），可能导致注入点遗漏。建议通过 -v 3 输出详细日志，验证扫描完整性

• 与认证参数的冲突：

• 若需同时处理 HTTP 认证（如 --auth-type），需确保 --ignore-code 不覆盖认证流程中的必要状态码

• 动态调整策略：结合 --flush-session 清空缓存后重新扫描，或通过 --safe-url 指定健康检查接口维持会话状态
• 与错误注入技术结合：若目标返回 500 时泄露数据库信息，可配合 --error-verbose 提取报错内容

• --ignore-proxy：用于 绕过系统代理设置 的关键参数，适用于需要直接访问目标服务器、避免代理干扰的场景（如测试本地网络或目标服务器位于内网）

• 核心功能：

• 绕过系统代理配置：

• --ignore-proxy 会忽略操作系统或环境中预设的 HTTP/HTTPS 代理设置，直接向目标地址发送请求。这在以下场景中尤为重要：

• 本地网络测试：目标服务器位于局域网或本地开发环境（如 Docker 容器），系统代理可能无法正确路由请求
• 代理冲突：当系统全局代理（如 Charles、Burp Suite）与目标网络环境不兼容时，强制直连目标地址

• 与其他代理参数的对比：

• --proxy：手动指定代理服务器（如 --proxy http://127.0.0.1:8080）
• --ignore-proxy：完全跳过代理，直接通信。两者不可同时使用

• 典型用法：

• 基础命令：

• sqlmap -u "URL" --ignore-proxy
• 作用：绕过系统代理，直接访问局域网内的目标服务器

• 复杂场景组合：

• sqlmap -u "URL"  --ignore-proxy --auth-type NTLM  --auth-cred "corpuser:password"
• 适用场景：内网环境中需同时处理代理绕过与 NTLM 认证

• 结合其他参数优化扫描：

• sqlmap -r request.txt --ignore-proxy  --delay=2  --random-agent

• --delay：降低请求频率，减少触发防火墙或 WAF 的风险
• --random-agent：随机化 User-Agent 以规避基础流量检测

• 注意事项：

• 代理优先级问题：

• 若同时使用 --proxy 和 --ignore-proxy，sqlmap 会优先遵循 --proxy 的设置，忽略 --ignore-proxy
• 在 Windows 系统中，需检查环境变量（如 HTTP_PROXY）是否覆盖了参数设置

• 常见错误处理：

• 连接超时：若目标服务器无法直连（如防火墙限制），需检查网络策略或切换至 --proxy 指定代理
• 认证失败：某些内网环境可能需要同时配置 --auth-type 和 --auth-cred，确保绕过代理后仍能完成认证

• 与 Tor 网络的冲突：

• --ignore-proxy 无法与 Tor 匿名网络（--tor 参数）同时使用。若需匿名访问，应使用 --tor 而非绕过代理

• 代理环境检测：使用 curl -v URL 验证系统代理是否生效，再决定是否启用 --ignore-proxy
• 自动化集成：在持续集成（CI）环境中，可通过环境变量 unset http_proxy 实现类似效果，避免硬编码参数

•  --ignore-redirects：用于 忽略 HTTP 重定向尝试 的参数。当目标服务器返回 3xx 状态码（如 301、302 等）时，sqlmap 默认会跟随重定向，但启用此参数后，工具将直接处理原始请求的响应，避免因重定向导致注入流程中断或误判

• 核心功能：

• 阻断重定向流程：

• 当目标网站通过重定向（如跳转到登录页、错误页或验证页面）干扰注入测试时，--ignore-redirects 会强制 sqlmap 停留在原始请求的响应阶段，继续分析当前页面的注入点，而非跟随跳转后的新页面

• 适用场景：

• 注入点位于重定向路径中：例如，某些页面在参数异常时会重定向到错误页，但实际注入漏洞存在于原始请求的响应头或 Cookie 中
• 绕过登录/权限验证：若重定向是权限验证的一部分（如未登录时跳转至登录页），配合 --auth-type 或 --cookie 可维持会话状态继续测试
• 精确控制请求链：在代理工具（如 Burp Suite）中手动分析重定向前后的流量差异时，避免自动化干扰

• 典型用法：

• 基础命令：

• sqlmap -u "URL" --ignore-redirects
• 作用：直接分析 vuln.php 的原始响应，即使服务器返回 302 重定向至其他页面

• 结合代理与认证参数：

• sqlmap -u "URL" --ignore-redirects --proxy="http://127.0.0.1:8080"  --cookie="session=abc123"

• --proxy：通过代理捕获请求，验证重定向是否影响注入流程
• --cookie：维持有效会话，避免因权限问题触发重定向

• 处理复杂重定向逻辑：

• 若目标网站存在多级重定向或动态令牌验证，可结合 --safe-url 维持会话稳定性：

• sqlmap -r request.txt --ignore-redirects --safe-url="
  
  http://target.com/healthcheck"

• --safe-url：定期访问一个稳定的健康检查接口，防止会话过期

• 注意事项：

• 误判风险：

• 忽略有效重定向：某些注入点可能隐藏在重定向后的页面（如分步提交的表单），此时需禁用此参数或手动分析
• 会话失效：若重定向是会话维持的必要步骤（如 CSRF 令牌更新），需配合 --csrf-token 动态处理

• 性能影响：

• 延迟与超时：重定向可能隐含网络延迟逻辑，建议通过 --delay 调整请求间隔（如 --delay=2）
• 错误处理：若原始请求返回 4xx/5xx 错误，需结合 --ignore-code 跳过特定状态码（如 --ignore-code=403）

• 与其他参数冲突：

• --follow-redirects：两者互斥，默认 sqlmap 开启跟随重定向，需显式指定 --ignore-redirects 覆盖
• HTTPS 重定向：若目标强制 HTTPS 跳转，需添加 --force-ssl 或直接指定 HTTPS URL

• 与重定向相关的其他参数：

• --drop-set-cookie：忽略响应中的 Set-Cookie 头，防止重定向过程中的 Cookie 更新干扰
• --eval：通过自定义 Python 代码动态处理重定向逻辑（如提取 Location 头）

• 自动化绕过策略：

• 结合 --random-agent 和 --hpp（HTTP 参数污染）可进一步降低重定向触发的风控检测概率

• --ignore-timeouts：用于 忽略网络连接或请求超时导致的错误，避免扫描过程中因超时中断测试

• 核心功能：

• 绕过超时中断：

• --ignore-timeouts 会强制 sqlmap 在遇到网络连接超时（如服务器响应缓慢、防火墙干扰等）时继续执行注入测试，而非终止扫描流程。这在以下场景中尤为重要：

• 高延迟网络环境：目标服务器位于海外或网络质量较差的场景
• 防护机制干扰：目标服务器部署了速率限制（Rate Limiting）或动态阻断策略，导致部分请求超时

• 与其他超时相关参数的对比：

• --timeout：设置单次请求的超时时间（默认 30 秒），控制等待响应的最大时长
• --retries：定义超时后重试次数（默认 3 次）
• --ignore-timeouts：完全跳过超时错误的处理，直接忽略并继续测试

• 典型用法：

• 基础命令：

• sqlmap -u "URL"  --ignore-timeouts
• 作用：针对高延迟目标，即使部分请求超时也继续扫描

• 结合其他参数优化稳定性：

• sqlmap -u "URL" --ignore-timeouts --delay=2  --timeout=45  --retries=5

• --delay=2：降低请求频率（2 秒/次），减少触发服务器防护的概率
• --timeout=45：延长单次请求超时时间至 45 秒，适应高延迟环境

• 处理复杂网络干扰：

• sqlmap -r request.txt  --ignore-timeouts --proxy="http://127.0.0.1:8080" --random-agent  --tamper=space2comment

• --proxy：通过代理工具（如 Burp Suite）监控超时请求
• --tamper：混淆载荷以绕过 WAF，减少超时触发概率

• 注意事项：

• 潜在风险：

• 漏报风险：忽略超时可能导致某些注入点未被检测到（如仅在高延迟下可触发的注入）
• 性能影响：频繁超时可能大幅延长扫描时间，建议结合 --threads 调整并发线程数

• 日志与调试：

• 使用 -v 3 输出详细请求日志，分析超时原因（如网络问题或服务器主动阻断）

• 与异常状态码的配合：

• 若超时伴随特定 HTTP 状态码（如 504 Gateway Timeout），可结合 --ignore-code=504 进一步优化流程

• --delay：用于 控制请求发送间隔时间 的关键参数，通过人为增加请求间的延迟，降低扫描速度，从而规避目标服务器的防护机制（如 WAF、速率限制）

• 参数功能：

• 规避风控检测：

• 通过设置延迟（单位为秒），降低请求频率，避免触发目标服务器的异常流量监控。例如：sqlmap -u "URL" --delay=2
• 作用：每个 HTTP 请求间隔 2 秒，模拟正常用户操作，减少被 WAF 或 IPS 拦截的概率

• 适应高延迟环境：

• 在跨国或网络质量较差的场景中，适当增加延迟可避免因超时导致的扫描中断，需配合 --timeout 调整单次请求超时时间

• 优化扫描稳定性：

• 避免因高频请求导致目标服务器过载或会话中断，尤其在盲注（时间盲注、布尔盲注）中至关重要

• 典型用法：

• 基础命令：

• sqlmap -u "URL" --delay=3
• 设置 3 秒延迟，适用于常规渗透测试场景

• 动态调整延迟：

• 结合其他参数优化隐蔽性：

• sqlmap -u "URL" --delay=1.5 --random-agent  --tamper=space2comment

• --random-agent：随机化 User-Agent，降低流量特征识别概率
• --tamper：使用混淆脚本（如 space2comment）绕过 WAF 规则

• 时间盲注场景：

• 时间盲注依赖服务器响应延迟判断条件真假，需根据实际情况调整延迟：

• sqlmap -u "URL" --delay=5 --time-sec=10  --technique=T

• --time-sec：设置时间盲注的基准延迟（默认 5 秒），需与 --delay 协调避免冲突

• 注意事项：

• 延迟与效率的平衡：

• 过低延迟：可能导致请求被拦截或服务器崩溃
• 过高延迟：显著延长扫描时间，建议结合 --threads 限制并发线程数（如 --threads=2）

• 与其他参数的冲突：

• --threads：高并发线程会抵消延迟效果，需根据网络环境动态调整
• --timeout：若服务器响应较慢，需增加超时时间（如 --timeout=60）

• 特殊场景适配：

• 双参数注入点：若目标对同一参数多次处理（如 id=1&id=2），需配合 --hpp（HTTP 参数污染）增强隐蔽性
• 代理环境：通过 --proxy 监控实际请求间隔，验证延迟策略是否生效

• 动态延迟脚本：通过 --eval 编写 Python 代码动态调整延迟（如根据响应时间自动增减间隔）
• 健康检查机制：配合 --safe-url 定期访问无害页面维持会话，避免因长时间静默触发防护重置

• --timeout：用于设置 HTTP(S) 请求超时时间的关键参数，通过控制单次请求的等待时间，避免因服务器响应缓慢或网络延迟导致扫描中断

• 核心功能：

• 控制单次请求的等待时间：

• 默认情况下，sqlmap 等待服务器响应的超时时间为 30 秒。若超过设定时间未收到响应，sqlmap 将终止当前请求并标记为超时

• 适用场景：

• 目标服务器位于高延迟网络环境（如跨国访问）
• 绕过 WAF 或 IPS 的慢速响应干扰策略

• 与时间盲注检测的关联：

• --timeout 直接影响时间盲注（Time-Based Blind SQLi）的准确性。若网络延迟超过 --time-sec（时间盲注基准延迟），可能引发误判。建议将 --timeout 设置为 --time-sec 的 2 倍以上

• 典型用法：

• 基础命令：

• sqlmap -u "URL" --timeout=20 --batch
• 作用：设置每次请求最多等待 20 秒，适用于常规渗透测试

• 高延迟环境优化：

• sqlmap -u "URL" --timeout=60 --retries=5  --delay=3

• --retries：超时后重试次数（默认 3 次）
• --delay：请求间隔时间（3 秒），降低触发风控的概率

• 结合代理调试：

• sqlmap -r request.txt  --timeout=30 --proxy="http://127.0.0.1:8080"
• 用途：通过 Burp Suite 等代理工具观察实际响应时间，验证超时是否由网络问题或服务器主动拦截导致

• 注意事项：

• 误报与漏报风险：

• 误报：若 --timeout 设置过短，可能导致有效响应被误判为超时
• 漏报：若服务器因负载过高间歇性超时，需结合 --retries 重试机制

• 与其他参数的优先级：

• --time-sec：时间盲注的基准延迟（默认 5 秒），需与 --timeout 协调
• sqlmap -u "URL" --time-sec=10 --timeout=25  # 确保超时覆盖盲注延迟

• --threads：高并发线程可能加剧超时问题，建议限制线程数（如 --threads=2）

• 网络环境排查：

• 若频繁超时，需检查防火墙规则、目标服务状态（如 SQL 服务是否运行）
• 使用 tcping 或 Wireshark 分析网络层延迟

• 超时与数据库性能：

• SQL Server、MySQL 等数据库的锁等待超时（如 Lock wait timeout exceeded）可能与 --timeout 冲突，需调整数据库参数（如 innodb_lock_wait_timeout）

• 自动化优化：使用 --eval 编写动态脚本，根据响应时间自适应调整超时值

• --retries：用于 控制 HTTP(S) 请求超时后的重试次数 的关键参数，适用于网络不稳定或目标服务器响应缓慢的场景。通过调整重试次数，可提高扫描成功率，同时避免因单次超时导致测试中断

• 核心功能：

• 超时请求自动重试：

• --retries 指定当 HTTP(S) 请求超时（由 --timeout 定义超时时间）后，sqlmap 重新发起请求的最大次数。默认值为 3 次，适用于以下场景：

• 高延迟网络：跨国或跨地区访问时，服务器响应可能因网络波动超时
• 服务器防护机制：目标服务器部署了速率限制或动态流量清洗策略，偶发性丢弃请求

• 与其他超时参数的关联：

• --timeout：定义单次请求的超时时间（默认 30 秒），与 --retries 共同决定总等待时间（如 --timeout=30 --retries=5，则总超时时间为 30×5=150 秒）
• --delay：设置请求间隔时间，避免高频重试触发 WAF/IP 封禁

• 典型用法：

• 基础命令：

• sqlmap -u "URL" --retries=5
• 作用：单次请求超时后自动重试 5 次，适用于稳定性较差的网络环境

• 结合超时与延迟优化：

• sqlmap -u "URL" --retries=5 --timeout=45 --delay=2

• --timeout=45：延长单次请求超时时间至 45 秒，适应高延迟服务器
• --delay=2：每次重试前等待 2 秒，降低触发防护机制的概率

• 处理复杂防护策略：

• 若目标服务器存在动态封禁 IP 的行为，可结合 --safe-url 和随机化参数增强隐蔽性：
• sqlmap -r request.txt --retries=3 --safe-url="
  
  http://target.com/healthcheck"  --randomize=id  --tamper=space2comment

• --safe-url：定期访问无害页面维持会话，防止因重试过多导致会话失效

• 注意事项：

• 性能与效率的平衡：

• 过高重试次数：可能导致扫描时间大幅延长（如 --retries=10 可能使单个请求耗时超过 5 分钟）
• 过低重试次数：可能遗漏实际存在的注入点，尤其在盲注场景下

• 错误日志分析：

• 使用 -v 3 输出详细日志，判断超时原因是网络问题还是服务器主动拦截

• 与异常状态码的配合：

• 若超时伴随特定 HTTP 状态码（如 504），可结合 --ignore-code=504 跳过无效重试

• 自动化重试策略：

• 结合 --eval 编写 Python 脚本，根据响应动态调整重试次数（如根据网络延迟自动增减）

• 与 Tor 网络的兼容性：

• 使用 --tor 匿名网络时，需适当增加 --retries 和 --timeout 以应对 Tor 节点的不稳定性

• --retry-on：用于 根据响应内容匹配正则表达式触发重试 的高级参数，适用于目标服务器因特定错误（如临时网络中断、防护机制干扰）导致请求失败但需重试的场景

• 核心功能：

• 条件化重试机制：

• --retry-on 允许用户通过正则表达式定义触发重试的响应内容。当请求失败时，若服务器返回的响应内容匹配预设的正则表达式，sqlmap 将自动重试请求，否则直接标记为失败。例如：

• sqlmap -u "URL" --retry-on="(timeout|drop)"
• 作用：当响应包含 timeout 或 drop 关键词时，sqlmap 重新发起请求，适用于处理云 WAF 临时拦截或高延迟环境下的偶发性丢包

• 与基础重试参数的协同：

• --retries：控制最大重试次数（默认 3 次），与 --retry-on 配合可限制重试范围
• --timeout：设置单次请求的超时时间（默认 30 秒），需根据正则匹配的典型错误调整。例如，处理间歇性网络抖动时，可延长超时并增加重试次数

• 典型用法：

• 匹配特定错误信息：

• 若目标服务器在遭遇 SQL 注入探测时返回特定错误（如 Connection reset），可通过正则精准捕获并重试：

• sqlmap -u "URL" --retry-on="Connection reset" --retries=5
• 场景：绕过基于错误关键词的临时阻断策略（如云 WAF 的速率限制）

• 结合代理与日志分析：

• 通过代理监控请求/响应，提取高频错误模式并动态调整正则表达式：

• sqlmap -r request.txt --retry-on="(limit exceeded|quota)" --proxy="http://127.0.0.1:8080" -v 3

• -v 3：输出详细日志，便于分析匹配逻辑的有效性

• 多条件组合匹配：

• 使用逻辑运算符 | 覆盖多种错误类型：

• sqlmap -u "URL" --retry-on="(timeout|blocked|invalid session)"
• 适用场景：处理会话失效、临时封禁等多因素干扰

• 注意事项：

• 正则表达式优化：

• 精准性：过于宽泛的正则（如 .*error.*）可能导致无效重试，增加扫描时间
• 性能损耗：复杂正则可能影响 sqlmap 的响应分析效率，建议优先使用简单匹配

• 与其他参数的冲突：

• --ignore-code：若已忽略特定状态码（如 504），需确保 --retry-on 的正则不与之重叠，避免逻辑矛盾
• --delay：重试间隔需合理设置（如 --delay=2），防止高频重试触发更严格的风控

• 误判风险：

• 无限重试：若正则匹配持续成功（如服务器始终返回相同错误），需通过 --retries 限制次数
• 资源消耗：长时间重试可能占用大量系统资源，建议结合 --threads 限制并发线程数

• 正则表达式语法：sqlmap 使用 Python 的 re 模块进行匹配，支持 |（或）、()（分组）、d（数字）等标准语法
• 自动化脚本：结合 --eval 编写动态调整正则表达式的脚本，根据响应内容自适应优化重试条件

• --randomize：用于 随机化指定参数值 的核心参数，通过动态改变请求参数的值（保持长度和类型一致）来绕过基于参数值的防护机制（如 WAF、规则匹配）

• 核心功能：

• 绕过特征检测：

• 通过随机化指定参数的值，避免请求中参数值的重复性特征被 WAF 或 IDS/IPS 识别为攻击行为。例如：

• sqlmap -u "http://192.168.137.101/search?q=test"  --randomize=q
• 作用：每次请求时 q 参数的值会被随机替换为相同长度和类型的字符串（如 test → a1b2），但保持 SQL 注入载荷的有效性

• 与其他隐蔽性参数的协同：

• --tamper：结合混淆脚本（如 randomcase、space2comment）进一步模糊攻击载荷特征
• --delay：控制请求间隔，避免高频随机化触发异常流量告警

• 典型用法：

• 基础命令：

• sqlmap -u "http://192.168.137.101/search?data=test"  --randomize=data
• 效果：data 参数的值在每次请求时随机变化（如 123 → 456、789），但保持数值类型和长度一致

• 多参数随机化：

• 若需同时随机化多个参数，可用逗号分隔：

• sqlmap -u "
  
  http://192.168.137.101/login?user=admin&token=abc123" --randomize="user,token"
• 适用场景：绕过基于多参数组合的规则检测

• 结合代理监控：

• 通过 --proxy 观察随机化后的实际请求效果：

• sqlmap -u "
  
  http://192.168.137.101/product?id=1"  --randomize=id  --proxy="http://127.0.0.1:8080" -v 3

• -v 3：输出详细日志，验证参数值是否按预期随机化

• 注意事项：

• 参数类型与长度限制：

• 数值型参数：随机值会保持原参数的数字类型（如 id=1 → id=987）
• 字符串参数：随机值仅替换字符内容，不改变长度（如 name=Alice → name=3xY9z）
• 特殊格式参数：若参数包含特定格式（如日期、邮箱），需结合 --eval 编写 Python 代码动态生成合法值

• 与注入技术的兼容性：

• 布尔盲注/时间盲注：随机化不影响逻辑判断，可直接使用
• 联合查询注入：需确保随机化参数不影响 UNION 子句的结构有效性

• 误判与性能影响：

• 误报风险：过度随机化可能导致合法请求被误判为异常（如登录态参数被随机破坏）
• 效率优化：建议限制随机化参数范围（如仅针对高危参数），并配合 --threads 控制并发线程数

• 扩展技巧：

• 动态脚本生成：

• 使用 --eval 编写 Python 代码，根据上下文动态生成随机值（如模拟时间戳或会话 ID）：

• sqlmap -u "
  
  http://192.168.137.101/api?timestamp=123456"  --eval="import random; timestamp=str(random.randint(100000,999999))"  --randomize=timestamp

• 与批量扫描结合：

• 在批量扫描日志文件（-l burp.log）时，通过 --scope 过滤目标并随机化关键参数：

• sqlmap -l burp.log --scope="(api|data).target.com" --randomize=id,cookie

•  --safe-url：用于 维持会话稳定性 的核心参数，通过定期访问一个“安全无害”的 URL，防止目标服务器因长时间未收到合法请求而中断会话或触发防护机制（如 IP 封禁、WAF 拦截）

• 核心功能：

• 维持会话有效性：当目标服务器存在 会话超时机制 时，长时间未收到合法请求可能导致会话失效。通过 --safe-url 定期访问指定 URL（如首页、健康检查页），可保持会话活跃，避免因注入测试的异常流量导致连接中断
• 绕过速率限制：部分 WAF/IPS 会对高频异常请求触发封禁。通过 --safe-url 定期发送正常请求，可混淆流量特征，降低触发风控的概率
• 兼容复杂防护策略：在需要 多阶段交互 的场景（如二次注入、带 CSRF 防护的页面），定期访问安全 URL 可刷新令牌或维持上下文状态

• 典型用法：

• 基础命令：

• sqlmap -u "
  
  http://192.168.137.101/vuln.php?id=1" --safe-url="http://192.168.137.101/index.php"
• 作用：每执行若干次注入测试后，自动访问 index.php 维持会话
• 适用场景：目标服务器设置了 5-10 分钟会话超时

• 动态调整访问频率：

• 通过 --safe-freq 指定访问安全 URL 的间隔（默认根据测试进度动态调整）：

• sqlmap -u "
  
  http://192.168.137.101/vuln.php?id=1" --safe-url="http://192.168.137.101/index.php" --safe-freq=20

• --safe-freq=20：每执行 20 次注入测试后访问一次安全 URL

• 结合POST请求或自定义请求：

• 若安全 URL 需 POST 数据或携带特定参数，可配合 --safe-post 或 --safe-req：

• sqlmap -r request.txt --safe-url="
  
  http://192.168.137.101/index.php" --safe-post="username=guest&password=guest"  --safe-freq=15

• --safe-post：发送特定 POST 数据模拟合法登录请求
• --safe-req：从文件中加载完整的 HTTP 请求内容

• 注意事项：

• 安全 URL 的选择：

• 无副作用：确保目标 URL 不会修改数据库或触发业务逻辑（如首页、静态资源页）
• 响应稳定性：优先选择返回 HTTP 200 状态码的页面，避免因访问错误页面暴露异常行为

• 与代理工具的协同：通过 --proxy 监控实际请求，验证 --safe-url 是否按预期发送请求
• 性能平衡：

• 过高频率：可能增加扫描时间，需根据目标服务器的超时阈值调整 --safe-freq
• 过低频率：无法有效维持会话，建议结合 --timeout 延长单次请求等待时间

• 与其他参数的冲突：

• --skip-waf：若目标存在复杂 WAF，需配合 --tamper 脚本混淆注入载荷，避免安全 URL 请求被误判为攻击
• --flush-session：清空历史会话缓存时，需重新验证安全 URL 的有效性

• 扩展技巧：

• 自动化健康检查：结合 --eval 编写 Python 脚本，动态选择安全 URL（如轮询多个静态页面）

• sqlmap -u "http://192.168.137.101" --eval="import random; safe_urls=['/home', '/contact']; random.shuffle(safe_urls)"

• 日志分析优化：使用 -v 3 输出详细日志，观察安全 URL 的访问间隔与服务器响应状态，调整 --safe-freq 参数

• --safe-post：用于 在测试期间向指定安全 URL 发送合法 POST 请求 的关键参数，主要用于维持会话稳定性或绕过防护机制对异常流量的检测

• 核心功能：

• 维持会话有效性：当目标服务器存在 会话超时机制 或 动态封禁策略 时，--safe-post 可定期向指定 URL 发送合法的 POST 请求，模拟正常用户行为，防止因注入测试的高频异常流量导致会话中断或 IP 封禁
• 绕过 WAF/IPS 检测：部分防护系统会基于流量特征（如请求频率、参数值）拦截攻击。通过 --safe-post 发送无害请求，可混淆流量特征，降低触发风控的概率
• 与 --safe-url 的协同作用：

• --safe-url：指定安全 URL（如首页、健康检查页）用于 GET 请求的定期访问
• --safe-post：专门处理需要 POST 请求的场景（如登录、表单提交），确保 POST 型接口的合法性

• 典型用法：

• 基础命令：

• sqlmap -u "
  
  http://192.168.137.101/login.php" --safe-post="username=guest&password=guest" --safe-url="http://192.168.137.101/status"
• 作用：每执行若干次注入测试后，自动向 /status 发送 GET 请求，并向 /login.php 发送 POST 数据 username=guest&password=guest，维持会话活跃

• 结合代理调试：通过 --proxy 监控请求，验证安全 POST 请求是否生效

• sqlmap -r request.txt  --safe-post="token=valid_session"  --proxy="http://127.0.0.1:8080"  -v 3
• -v 3：输出详细日志，观察 POST 请求是否按预期发送

• 动态调整访问频率：使用 --safe-freq 控制安全请求的间隔

• sqlmap -u "
  
  http://192.168.137.101/api" --data="data=1"  --safe-post="action=ping"  --safe-freq=20
• --safe-freq=20：每执行 20 次注入测试后发送一次安全 POST 请求

• 注意事项：

• 安全 POST 数据的选择：

• 无副作用：确保 POST 数据不会触发业务逻辑（如写入数据库或修改用户状态）。例如，使用 action=healthcheck 而非 action=delete
• 格式兼容性：若目标接口要求 JSON 格式，需通过 --safe-post 指定完整 JSON 内容（如 {"status":"alive"}）

• 与异常状态码的配合：

• 若安全 URL 返回非 200 状态码（如 401），需结合 --ignore-code 忽略无效响应：

• sqlmap -u "
  
  http://192.168.137.101"  --safe-post="key=valid"  --ignore-code=401

• 性能优化：

• 避免高频请求：合理设置 --delay（如 --delay=2）和 --safe-freq（如 --safe-freq=30），平衡扫描效率与隐蔽性
• 多参数混淆：结合 --randomize 随机化参数值，增强流量合法性

• sqlmap -u "
  
  http://192.168.137.101"  --safe-post="id=1&token=random"  --randomize=id,token

• 与 --safe-req 的区别：

• --safe-post：直接指定 POST 数据
• --safe-req：从文件中加载完整的 HTTP 请求（含 HEADER 和 BODY），适用于复杂场景（如需携带特定 Cookie 或 Content-Type）

• 自动化健康检查：结合 --eval 编写动态生成 POST 数据的脚本，例如根据时间戳生成临时令牌

• sqlmap -u "http://192.168.137.101" --eval="import time; post_data=f'token={int(time.time())}'"  --safe-post="$post_data"

• 与 Tor 网络兼容：

• 使用 --tor 匿名网络时，需增加 --timeout 和 --retries 以应对 Tor 节点的延迟

• --safe-req：用于 从文件加载安全 HTTP 请求以维持会话稳定性 的核心参数，适用于需要精确控制请求格式或绕过复杂防护机制的场景

• 核心功能：

• 维持会话有效性：

• 通过从文件加载预先捕获的合法 HTTP 请求，定期发送该请求以模拟正常用户行为，防止目标服务器因注入测试的异常流量中断会话或触发封禁：

• 适用场景：目标存在会话超时机制、动态风控（如 WAF 对异常请求频率敏感）或需维持 CSRF 令牌有效性

• 精确控制请求细节：与 --safe-url（仅指定 URL）和 --safe-post（仅指定 POST 数据）不同，--safe-req 支持从文件加载完整 HTTP 请求（包括 Headers、Cookie、Body 等），适用于需携带特定认证头或复杂参数的场景

• 典型用法：

• 基础命令：

• sqlmap -r <请求文件路径> --safe-req <安全请求文件路径>
• sqlmap -r vuln_request.txt --safe-req safe_request.txt

• vuln_request.txt：包含待测试的注入点请求（如 Burp 捕获的请求）
• safe_request.txt：预先保存的合法请求（如访问首页或健康检查接口的请求）

• 结合频率控制：通过 --safe-freq 指定安全请求的发送间隔

• sqlmap -r vuln_request.txt --safe-req safe_request.txt --safe-freq 20
• 作用：每执行 20 次注入测试后发送一次安全请求，平衡隐蔽性与效率

• 与代理工具协同调试：通过 Burp Suite 捕获合法请求并保存为文件，用 --proxy 监控实际发送情况

• sqlmap -r vuln_request.txt --safe-req safe_request.txt --proxy="http://127.0.0.1:8080" -v 3

• -v 3：输出详细日志，验证安全请求是否按预期发送

• 注意事项：

• 文件格式要求：

• 安全请求文件需为原始 HTTP 请求格式（含请求方法、URL、Headers、Body），与 Burp Suite 导出格式一致
• 错误示例：仅包含 URL 而无 Headers，可能导致会话维持失效

• 避免逻辑冲突：

• 若同时使用 --safe-req 和 --safe-url/--safe-post，优先级为 --safe-req > --safe-post > --safe-url，建议仅选其一
• 若安全请求需动态更新（如令牌过期），需结合 --eval 编写脚本实时生成请求文件

• 性能优化：

• 高频请求：--safe-freq 值过低（如 <10）可能显著延长扫描时间，建议根据目标超时阈值调整（通常 15-30 次/请求）
• 请求复杂度：包含大量 Headers 或大 Body 的请求会增加资源消耗，需测试稳定性

• 动态令牌刷新：结合 --eval 在安全请求中嵌入时间戳或会话 ID

• sqlmap -r vuln_request.txt --eval "import time; token=open('token.txt','w'); token.write(f'Authorization: Bearer {int(time.time())}')" --safe-req safe_request.txt

• 多安全请求轮询：创建多个安全请求文件，通过脚本轮换发送以增强隐蔽性

• 参数对比与选择建议：

• 优先使用 --safe-req 应对需携带动态令牌或自定义头的复杂场景
• 简单场景可用 --safe-url 或 --safe-post 简化配置

• --safe-freq：用于 控制安全请求发送频率 的核心参数，主要解决因高频异常请求触发目标服务器会话超时或防护机制（如 WAF 封禁）的问题。其核心逻辑是：在每执行 N 次注入测试后，自动发送一次预设的“安全无害”请求，以维持会话活跃性

• 核心功能：

• 防止会话失效：当目标服务器存在 会话超时机制（如 5-10 分钟无操作自动登出）时，持续注入测试可能被误判为异常行为。--safe-freq 定期发送合法请求（如访问首页、健康检查页），确保会话不被中断
• 绕过流量风控：部分 WAF/IPS 会对高频异常请求触发临时封禁。通过穿插合法请求，混淆流量特征，降低触发风控的概率
• 与安全请求参数协同：

• --safe-url：指定安全请求的 URL（GET 请求）
• --safe-post：指定安全请求的 POST 数据
• --safe-req：从文件加载完整 HTTP 请求（含 Headers/Cookies）
• --safe-freq 依赖以上参数定义安全请求内容，默认每 3 次注入后发送一次安全请求（可自定义）

• 典型用法：

• 基础命令：

• sqlmap -u "
  
  http://192.168.137.101/vuln.php?id=1"  --safe-url="http://192.168.137.101/index.php" --safe-freq=20
• 作用：每执行 20 次注入测试后，访问 index.php 维持会话

• 结合POST请求：

• sqlmap -u "
  
  http://192.168.137.101/login"  --data="user=admin&pass=123"  --safe-post="action=ping"  --safe-freq=15
• 适用场景：需模拟表单提交（如刷新 CSRF 令牌）时

• 调试与验证：

• sqlmap -r request.txt  --safe-req safe_req.txt  --safe-freq=10  --proxy="http://127.0.0.1:8080"  -v 3
• -v 3：输出详细日志，确认安全请求是否按预期发送

• 注意事项：

• 频率设置需权衡：

• 过高频率（如 --safe-freq=5）：显著延长扫描时间，建议根据目标超时阈值调整（通常 15-30 次/请求）
• 过低频率：无法有效维持会话，需配合 --delay 降低请求速度（如 --delay=2）

• 安全请求的选择原则：

• 无副作用：避免选择触发业务逻辑的 URL（如注销接口、写入操作）
• 稳定性：优先返回 HTTP 200 的静态页面（如 /healthcheck）

• 冲突与性能优化：

• 与 --skip-waf 冲突：若目标存在复杂 WAF，需配合 --tamper 混淆注入载荷（如 space2comment）
• 资源消耗：安全请求包含大量 Headers 时可能增加负载，建议测试稳定性

• 动态令牌刷新：结合 --eval 生成实时 Token（如时间戳）

• sqlmap -u "http://192.168.137.101"  --eval="import time; token=open('token.txt','w'); token.write(f'ts={int(time.time())}')"  --safe-req safe_req.txt  --safe-freq=20

• 多安全请求轮换：创建多个安全请求文件（如 safe1.txt, safe2.txt），通过脚本轮换发送增强隐蔽性

• 参数对比：

• 简单场景：--safe-url + --safe-freq 足以维持会话
• 复杂认证：使用 --safe-req 加载含动态令牌的完整请求

• --skip-urlencode：用于 跳过对请求参数的自动 URL 编码 的关键参数，主要用于处理不符合 RFC 标准的服务器或特殊场景下的注入测试

• 核心功能：

• 绕过非标准 URL 处理机制：

• 问题背景：默认情况下，sqlmap 会对所有参数值进行 URL 编码（如空格转为 %20）。但部分服务器未遵循 RFC 规范，仅接受原始字符（如保留空格为空格而非 %20），导致注入测试失败
• 作用：--skip-urlencode 强制 sqlmap 发送原始未编码的参数值，确保请求格式符合目标服务器的非标准要求

• 处理预编码参数：若参数值已手动编码（如通过 Burp Suite 捕获的请求），再次编码会导致数据格式错误。此参数避免双重编码问题
• 兼容特殊字符注入：某些注入场景需保留原始字符（如单引号 '、分号 ;）的语义，自动编码会破坏语法结构。跳过编码可维持攻击载荷的有效性

• 典型用法：

• 基础命令：sqlmap -u "
  
  http://192.168.137.101/search?q=test" --skip-urlencode

• 效果：q 参数的值 test 以原始形式发送，不转换为 %74%65%73%74

• 结合Burp Suite捕获的请求：sqlmap -r request.txt --skip-urlencode

• 场景：request.txt 包含已编码的请求（如从 Burp Suite 导出），避免 sqlmap 二次编码

• 处理 JSON/XML等复杂参数：sqlmap -u "
  
  http://192.168.137.101/data" --data '{"id":1}' --skip-urlencode

• 作用：JSON 数据 {"id":1} 保持原样发送，防止 {、} 等符号被编码破坏结构

• 绕过 WAF 对编码的依赖：sqlmap -u "
  
  http://192.168.137.101/api?filter=name='admin'"  --skip-urlencode  --tamper=charunicodeescape  --level=3

• 效果：跳过编码后直接发送 name='admin'，配合 charunicodeescape 将单引号转为 u0027

• 注意事项：

• 服务器兼容性测试：

• 仅当目标服务器明确要求原始字符时使用此参数，否则可能导致正常请求失败
• 验证方法：先发送未编码的合法请求（如通过 curl），确认服务器是否接受

• 与编码相关参数的冲突：

• --tamper 脚本：若使用了混淆脚本（如 base64encode），需确保脚本逻辑与跳过编码不冲突
• --eval：动态生成的参数若需编码，应在 Python 代码中显式处理（如 urllib.parse.quote()）

• 隐蔽性影响：未编码的特殊字符（如 '、#）可能被 WAF 直接拦截，建议配合 --tamper 混淆载荷（如 charunicodeescape）
• 动态编码处理：结合 --eval 在特定参数上选择性编码

• sqlmap -u "
  
  http://192.168.137.101"  --eval "import urllib.parse; id=urllib.parse.quote(id)"  --skip-urlencode
• 作用：仅对 id 参数手动编码，其他参数保持原始值

• 参数对比与建议：

• 建议：

• 优先通过代理（如 --proxy http://127.0.0.1:8080）观察原始请求，确认是否需要跳过编码
• 若需处理复杂数据（如 XML/JSON），结合 --data 和 --skip-urlencode 确保格式正确

• --csrf-token：用于 自动处理 CSRF Token 防御机制 的关键参数，主要解决目标网站通过动态 Token 防止 CSRF 攻击时，注入测试因 Token 校验失败而中断的问题。其核心原理是：自动识别并更新请求中的 Token 值，确保每次测试请求均携带有效的 Token

• 核心功能：

• 绕过动态 Token 防护：

• 问题背景：目标网站每次请求会生成随机 Token（如 <input type="hidden" name="token" value="随机值">），普通注入测试因无法更新 Token 会被服务器拒绝
• 作用：--csrf-token 指定 Token 参数名（如 token），sqlmap 自动从响应中提取最新 Token 并添加到后续请求中

• 支持多种 Token 来源：

• 同页面获取：默认从当前注入点的响应中提取 Token（需页面返回 Token）
• 独立 URL 获取：通过 --csrf-url 指定单独获取 Token 的 URL（适用于 Token 与注入点不同源的情况）

• 典型用法：

• 基础命令：sqlmap -u "
  
  http://192.168.137.1/vuln?param=1" --csrf-token="token"

• 效果：自动从 
  
  http://192.168.137.1/vuln 的响应中提取名为 token 的参数值，添加到后续请求的 token 字段中

• 指定独立Token获取URL：sqlmap -u "
  
  http://192.168.137.1/inject?data=1"  --csrf-token="csrf_token"  --csrf-url="http://192.168.137.1/get_token"

• 适用场景：Token 需从 /get_token 接口获取，与注入点分离

• 结合BurpSuite获取的请求：sqlmap -r request.txt --csrf-token="token" --proxy="http://127.0.0.1:8080"

• 步骤：

• 用 BurpSuite 捕获含 Token 的请求，保存为 request.txt
• 指定 Token 参数名，sqlmap 自动更新并重放请求

• 注意事项：

• Token 识别逻辑：

• sqlmap 通过正则匹配响应内容提取 Token，需确保参数名（如 token）在响应中明确存在且格式一致
• 验证方法：使用 -v 3 查看详细日志，确认 Token 是否被正确提取

• 动态 Token 的更新频率：若 Token 每次请求更新，需确保 --csrf-url 或当前页面响应始终返回最新 Token，否则需配合脚本动态生成
• 与其他参数的协同：--eval：当 Token 需计算生成时（如基于时间戳），用 Python 脚本动态赋值

• sqlmap -u "
  
  http://192.168.137.1" --csrf-token="token"  --eval="import time; token=str(int(time.time()))"

• --tamper：若目标存在 WAF，需配合混淆脚本（如 charencode）绕过 Token 规则检测

• Token 加密或散列：若 Token 为加密字符串，需编写脚本解密后传入

• sqlmap -u "
  
  http://192.168.137.1" --csrf-token="enc_token"  --eval="from crypto_lib import decrypt; enc_token=decrypt(enc_token)"

• 多阶段 Token 获取：对于需登录后获取 Token 的场景，先模拟登录再注入

• sqlmap -r login_request.txt --csrf-token="login_token"  -r inject_request.txt --csrf-token="api_token"

• 参数对比：

• 选择建议：

• 优先通过 --proxy 监控请求，验证 Token 是否按预期更新
• 复杂场景可结合 BurpSuite 的 CSRF Token Tracker 插件辅助自动化

• --csrf-url：用于 指定独立获取 CSRF Token 的 URL 的关键参数，主要解决当目标网站的 Token 生成页面与注入点分离时，自动获取并更新 Token 以绕过 CSRF 防护的问题

• 核心功能：

• 分离式 Token 获取：

• 问题背景：部分网站的 CSRF Token 并非由注入点页面返回（例如 Token 通过独立接口 /get_token 生成），导致 --csrf-token 无法从当前页面提取 Token
• 作用：--csrf-url 指定一个独立 URL（如 http://target.com/token_api），sqlmap 在每次请求前先访问该 URL 获取最新 Token，再将其添加到注入请求中

• 与 --csrf-token 的协同：

• --csrf-token：定义 Token 的参数名（如 token）
• --csrf-url：提供 Token 的来源地址，两者必须配合使用

• 典型用法：

• 基础命令：sqlmap -u "
  
  http://192.168.137.1/vuln?param=1" --csrf-token="token_name"  --csrf-url="http://192.168.137.1/get_token"

• 效果：

• 访问 http://192.168.137.1/get_token 提取 Token 值
• 将 Token 添加到 vuln 接口的 token_name 参数中

• 结合BurpSuite捕获的请求：sqlmap -r request.txt  --csrf-token="csrf_token"  --csrf-url="
  
  http://192.168.137.1/token_endpoint"  --proxy="http://127.0.0.1:8080"

• 步骤：

• 用 BurpSuite 捕获含 Token 的请求（request.txt）
• sqlmap 通过 --csrf-url 更新 Token 并重放请求

• 动态Token刷新(如时间戳)：

• sqlmap -u "
  
  http://192.168.137.1/api" --csrf-token="timestamp" --csrf-url="http://192.168.137.1/current_time" --eval="import time; token=str(int(time.time()))"
• 作用：通过 Python 脚本实时生成 Token，替代固定 URL 获取

• 注意事项：

• Token 识别逻辑：sqlmap 默认通过正则匹配响应内容提取 Token。需确保 --csrf-url 的响应中 明确包含 Token 值（如 JSON 中的 {"token": "value"} 或 HTML 隐藏域）

• 验证方法：使用 -v 3 查看日志，确认 Token 是否被正确提取

• Token 更新频率：

• 若 Token 每次请求更新（如一次性 Token），需设置 --csrf-url 为动态生成接口，否则可能导致 Token 失效
• 高频访问可能触发风控，建议配合 --delay 降低请求频率（如 --delay=2）

• 安全性与隐蔽性：

• WAF 绕过：若目标存在 WAF，需结合 --tamper（如 charencode）混淆 Token 请求
• 性能影响：频繁访问 --csrf-url 可能增加扫描时间，建议测试稳定性

• 参数对比：

• 选择建议：

• 优先通过 --proxy 监控请求流，确认 Token 更新逻辑是否符合预期
• 复杂场景可结合 BurpSuite 的 CSRF Token Tracker 插件辅助自动化

• --csrf-method：用于 指定获取 CSRF Token 的 HTTP 请求方法 的关键参数，主要解决当目标网站通过特定方法（如 GET 或 POST）动态生成 Token 时，需明确指定方法以正确获取 Token 的问题

• 核心功能：

• 动态 Token 获取方法控制：

• 问题背景：部分网站通过独立接口（如 /get_token）生成 CSRF Token，且生成方式可能限定为 GET 或 POST 请求。若未指定方法，sqlmap 默认使用 GET 请求，可能导致 Token 获取失败
• 作用：--csrf-method 显式定义获取 Token 的 HTTP 方法（支持 GET 或 POST），确保 sqlmap 能成功获取有效 Token

• 与 --csrf-url 和 --csrf-token 的协同：

• 必需组合：该参数需配合 --csrf-url（指定 Token 来源 URL）和 --csrf-token（定义 Token 参数名）使用，三者共同完成 Token 的自动化更新
• 优先级：若未指定 --csrf-method，sqlmap 默认使用 GET 请求 访问 --csrf-url

• 典型用法：

• 基础命令：sqlmap -u "
  
  http://192.168.137.1/vuln?param=1"  --csrf-token="token_name"  --csrf-url="http://192.168.137.1/token-api"  --csrf-method="POST"

• 效果：通过 POST 请求访问 token-api 获取 Token，再将其添加到注入请求的 token_name 字段中

• 携带POST数据获取Token：若 Token 接口需提交表单数据（如 action=generate）

• sqlmap -u "
  
  http://192.168.137.1/data?id=1"  --csrf-token="csrf_token"  --csrf-url="http://192.168.137.1/gen-token"  --csrf-method="POST"  --csrf-data="action=generate&user=guest"

• --csrf-data：指定 POST 请求的 Body 数据

• 调试与验证：sqlmap -r request.txt  --csrf-token="token"  --csrf-url="
  
  http://192.168.137.1/token-endpoint"  --csrf-method="GET"  --proxy="http://127.0.0.1:8080"  -v 3

• -v 3：输出详细日志，确认 Token 是否按预期通过 GET 获取

• 注意事项：

• 方法兼容性测试：

• GET 限制：部分接口禁止 GET 请求生成 Token（防参数泄露），需强制指定 --csrf-method=POST
• POST 依赖：若接口仅接受 POST，未指定方法会导致 Token 获取失败，扫描中断

• 动态 Token 更新机制：

• 一次性 Token：若 Token 仅单次有效，需确保 --csrf-url 每次访问均返回新 Token，否则需配合 --eval 脚本实时生成
• 频率控制：高频 Token 请求可能触发风控，建议添加 --delay=2 降低请求速率

• 安全性与隐蔽性：

• WAF 绕过：若目标存在 WAF，需配合 --tamper（如 charencode）混淆 Token 请求头或载荷
• 性能影响：POST 请求比 GET 消耗更多资源，可能延长扫描时间

• 参数选择建议：

• 操作提示：

• 优先通过 Burp Suite 抓包确认 Token 获取接口的请求方法，再选择 --csrf-method 值
• 复杂场景可结合 --eval 动态构造请求（如添加时间戳或加密参数）

• --csrf-data：用于 向 CSRF Token 生成接口提交额外表单数据 的关键参数，主要解决当目标网站生成 Token 需附带特定参数（如登录凭证或动态参数）时的自动化注入问题

• 核心功能：

• 动态 Token 认证支持：

• 问题背景：部分网站的 CSRF Token 接口（如 http://192.168.1.1/get_token）需提交表单数据（如 user=admin&pass=123）才能返回有效 Token，否则请求被拒绝
• 作用：--csrf-data 指定需提交的键值对数据，使 sqlmap 在访问 --csrf-url 时自动携带这些参数以获取合法 Token

• 与 --csrf-url 和 --csrf-method 的协同：

• 必需组合：该参数必须与 --csrf-url（Token 来源 URL）及 --csrf-method（请求方法，通常为 POST）配合使用
• 典型流程：

• 通过 --csrf-url 访问 Token 接口并提交 --csrf-data 数据
• 提取响应中的 Token 值
• 将 Token 添加到注入请求的指定参数（由 --csrf-token 定义）