Sqlmap全参数讲解之第六篇

免责声明

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

Enumeration：枚举数据

• -a/--all：用于全面枚举目标数据库的所有可获取信息，包括数据库、表、字段、数据内容及系统级信息（如用户权限、密码哈希等），属于最高级别的信息收集模式

• ⚙自动化全面扫描：-a 参数会触发 sqlmap 的全自动模式，依次执行以下操作：

• 数据库指纹识别（DBMS 类型、版本、操作系统）
• 枚举所有数据库、表、列名（相当于组合 --dbs、--tables、--columns）
• 提取所有表的数据（相当于 --dump-all）
• 尝试获取系统文件权限或执行命令（若权限允许）
• 耗时警告：因操作覆盖范围极广，扫描时间可能显著延长（尤其对大型数据库）

• 💡适用场景：

• 需全面掌握目标数据库结构的渗透测试
• 时间充裕且无需针对性提取特定数据

• 💡显著缺点：

• 耗时极长：因覆盖范围广，扫描时间可能数倍于针对性命令
• 流量显著：大量请求易触发WAF或告警机制
• 结果冗余：输出包含大量无关信息，需手动筛选

• ⚡典型用法：

• 基础扫描（低风险环境）：sqlmap -u "http://example.com/vuln.php?id=1" -a --batch

• 输出内容：

• 数据库类型、版本、操作系统
• 所有数据库名、表名、字段名及数据内容
• 当前用户权限及是否支持命令执行（如 --os-shell）

• 结合登录态扫描（Cookie/Session）：sqlmap -u "目标URL" --cookie="session_id=123abc" -a

• 适用场景：需认证的页面注入点（如用户后台）

• 绕过 WAF 的深度扫描：sqlmap -u "目标URL" -a --tamper=charencode,space2comment --level=5

• --tamper：载荷混淆脚本（绕过过滤规则）
• --level=5：最高检测等级（覆盖 Cookie/XFF 头等参数）

• 🆚-a vs 其他常用参数对比：

• 建议：优先使用针对性参数（如 --tables、--dump），避免滥用 -a
• 注意：若目标为敏感环境，建议添加 --batch 自动确认提示，避免交互中断

• ⚠注意事项：

• 高隐蔽性风险：

• 流量特征明显：-a 会触发大量探测请求，极易被 WAF/IDS 拦截
• 建议配合隐蔽参数： sqlmap -u "目标URL" -a --delay=3 --random-agent --proxy="http://127.0.0.1:8080"
• --delay：控制请求间隔（降低频率）
• --random-agent ：随机化 User-Agent
• --proxy：通过代理隐藏真实 IP

• 资源消耗问题：

• 目标负载：全面扫描可能导致目标数据库性能下降（尤其在时间盲注场景）
• 本地资源：大数据量提取时可能占用较高内存和带宽

• 法律合规：未经授权的扫描可能违反《网络安全法》等法规，仅限授权测试使用
• 替代方案：需快速获取关键信息时，推荐组合命令

sqlmap -u "http://example.com/?id=1" --dbs              # 获取库名   sqlmap -u "http://example.com/?id=1" -D app_data --tables # 获取表名   sqlmap -u "http://example.com/?id=1" -D app_data -T users --dump # 导出数据

• 权限依赖：若当前数据库用户非 DBA 权限，部分操作（如文件读取、命令执行）将失败

• 💎 总结：-a 是 sqlmap 的“核武器”级选项，适用于深度审计场景，但效率低下且风险高。日常测试建议：

• 分步骤扫描：优先使用 --dbs、--tables 等针对性参数
• 隐蔽性优化：结合 --delay 降低请求频率，或使用 --proxy 代理IP
• 结果过滤：通过 --search 搜索特定表/字段（如 -T 'user*'）

• -b, --banner：用于获取数据库管理系统（DBMS）标识（Banner）信息的命令参数。该参数主要用于快速识别目标数据库的类型和版本号，是渗透测试中信息收集的关键步骤

• ⚙获取数据库标识（Banner）：执行 sqlmap -u "目标URL" -b 后，SQLMap 会尝试通过注入手段提取数据库的 Banner 信息，通常包括：

• 数据库类型（如 MySQL、Oracle、SQL Server 等）
• 详细版本号（例如 MySQL 5.7.32 或 Microsoft SQL Server 2019）

• ⚙技术原理：利用数据库的报错注入或联合查询注入，触发 DBMS 返回包含版本信息的系统变量（如 MySQL 的 @@version、SQL Server 的 @@VERSION）
• ⚡典型用法：

• 基础用法： sqlmap -u "http://1.1.1.1/page?id=1" -b
• 指定参数注入点（-p）： sqlmap -u "http://1.1.1.1/login" --data="username=admin&password=123" -p "username" -b
• 从 Burp Suite 日志加载请求（-r）： sqlmap -r request.txt -b

• 📊与其他关键参数的协同作用：

• ⚠注意事项：

• 依赖注入漏洞：-b 仅在目标存在 SQL 注入漏洞时生效，若漏洞不存在或防御机制（如 WAF）拦截，可能返回空结果
• 结果准确性：部分数据库（如 SQLite、Access）可能无法通过 Banner 获取版本，需结合其他参数（如 --fingerprint）
• 隐蔽性：高频 Banner 探测易触发安全告警，建议配合 --delay 参数降低请求频率

• 💎总结：sqlmap -b 是快速识别数据库类型与版本的利器，适用于渗透测试初期信息收集阶段。实际使用时需结合漏洞存在性、防御策略灵活调整参数，并优先在授权环境中验证操作合法性

• --current-user：用于获取当前数据库连接用户的核心命令参数。该参数在渗透测试中用于识别数据库操作权限，是判断后续攻击可行性的关键步骤

• ⚙核心作用：通过注入点触发数据库返回当前连接用户的系统变量（如 MySQL 的 CURRENT_USER()、SQL Server 的 SUSER_SNAME()）
• ⚙权限关联性：

• 结果若为高权限用户（如 root、sa），可进一步尝试获取密码(--passwords)、执行命令(--os-shell)等操作
• 若返回普通用户（如 public），则操作可能受限

• ⚡典型用法：

• 基础用法： sqlmap -u "http://1.1.1.1/page?id=1" --current-user
• 典型组合命令：

• 结果准确性：部分数据库（如 Access）不支持此功能，需改用其他参数（如 --users 枚举所有用户）
• 隐蔽性与延迟：高频请求易触发告警，建议添加 --delay 参数（如 --delay=2 表示 2 秒/请求）

• 💎 总结：sqlmap --current-user 是权限探测的核心起点，需结合漏洞存在性灵活使用：

• 高权限用户 → 尝试密码提取、命令执行
• 低权限用户 → 转向表结构枚举或结合其他漏洞提权
• 无结果返回 → 检查注入点有效性或切换数据库类型适配参数
• ⚠️ 操作需在授权环境进行，避免法律风险

• --current-db：用于获取当前数据库名称的核心命令参数，在渗透测试的信息收集阶段至关重要

• ⚙作用：通过 SQL 注入漏洞直接获取目标网站当前连接的数据库名称，为后续操作（如表枚举、数据提取）提供目标定位
• ⚙技术原理：

• 利用注入点触发数据库返回系统变量（如 MySQL 的 DATABASE()、SQL Server 的 DB_NAME()）
• 支持多种注入技术（布尔盲注、时间盲注、报错注入等），自动适配目标数据库类型

• ⚡典型用法：

• 基础用法：sqlmap -u "http://1.1.1.1/page?id=1" --current-db
• 结合其他参数：

• ⚠注意事项：

• 依赖注入漏洞：

• 仅当目标存在 SQL 注入漏洞时生效，若漏洞被 WAF 拦截或不存在则返回空结果
• 可结合 --technique 指定注入技术（如 --technique=B 布尔盲注）绕过防御

• 结果准确性：部分数据库（如 SQLite、Access）可能不支持此功能，需改用 --dbs 枚举所有库名再人工判断
• 隐蔽性优化：

• 添加 --delay 2 延迟请求，避免触发安全告警
• 使用 --proxy=http://127.0.0.1:8080 通过代理隐藏真实 IP

• 📊SQLMap 典型工作流：

• 检测注入点 → sqlmap -u URL
• 获取当前库名 → --current-db
• 枚举表 → -D 库名 --tables
• 提取数据 → -T 表名 --dump

• 💎 总结：

• 核心价值：快速定位攻击目标，减少后续操作盲目性
• 适用场景：渗透测试初期、授权环境漏洞验证
• 法律合规：仅限授权测试，滥用可能导致法律风险

• --hostname：用于获取数据库服务器主机名的命令参数。该功能在渗透测试的信息收集阶段至关重要，可帮助识别目标服务器的网络环境信息

• ⚙核心作用：通过 SQL 注入漏洞提取数据库服务器的主机名（Hostname），通常用于定位服务器在网络中的标识
• ⚙技术原理：

• 对 MySQL 使用 @@hostname 系统变量
• 对 Microsoft SQL Server 使用 HOST_NAME() 函数
• 其他数据库（如 Oracle、PostgreSQL）需依赖特定系统表或函数支持

• ⚡典型用法：

• 基础用法：sqlmap -u "http://1.1.1.1/page?id=1" --hostname
• 典型组合命令：

• ⚠注意事项：

• 依赖注入漏洞：

• 仅在目标存在 有效 SQL 注入点 时生效。若漏洞被 WAF 拦截或防护机制生效，可能返回空结果
• 可配合 --technique 指定注入技术（如 --technique=E 报错注入）绕过防御

• 数据库兼容性：

• 支持数据库：MySQL、SQL Server、PostgreSQL 等主流 DBMS
• 不支持场景：

• Access、SQLite 等文件型数据库通常无法获取主机名
• 若数据库用户权限不足（如无系统表读取权限），可能返回错误

• 结果解析：

• 主机名可能反映服务器在内部网络中的角色（如 web-db-prod 暗示生产环境数据库服务器）
• 可与 IP 地址关联，辅助识别网络拓扑结构（例如区分物理服务器与容器环境）

• 📊SQLMap 主机名探测典型工作流：

• 漏洞确认 → sqlmap -u URL
• 权限检测 → --is-dba
• 主机名获取 → --hostname
• 环境关联 → 结合 --banner（数据库类型）和 --current-db（当前库名）综合判断服务器用途

• 💎 总结：

• 核心价值：快速定位数据库服务器在网络中的逻辑位置，辅助内网渗透路径规划
• 适用场景：授权渗透测试中的资产识别、服务器角色分析
• 局限性：依赖注入漏洞及用户权限，结果受数据库类型和网络配置影响
• 法律合规：仅限授权测试，滥用可能违反《网络安全法》

• --is-dba：用于 检测当前数据库连接用户是否具有数据库管理员（DBA）权限 的核心命令参数。该参数在渗透测试中至关重要，直接决定后续攻击路径的可行性（如系统命令执行、密码哈希提取等）

• ⚙核心作用：通过 SQL 注入漏洞查询数据库管理系统（DBMS）的权限配置，判断当前用户是否拥有 管理员权限（如 MySQL 的 SUPER 权限、SQL Server 的 sysadmin 角色）
• ⚙权限关联性：

• 若返回 True，可尝试高危操作（如 --os-shell 执行系统命令、--passwords 提取密码哈希）
• 若返回 False，需转向低权限攻击路径（如枚举表结构、结合其他漏洞提权）

• ⚡典型用法：

• 基础用法：sqlmap -u "http://1.1.1.1/page?id=1" --is-dba
• 典型组合命令：

• ⚠注意事项：

• 依赖注入漏洞：

• 仅在目标存在有效 SQL 注入点且未被 WAF 拦截时生效，否则返回空或错误
• 可配合 --technique 指定注入技术（如 --technique=B 布尔盲注）绕过防御

• 数据库兼容性：

• 支持数据库：MySQL、SQL Server、Oracle、PostgreSQL 等主流 DBMS
• 不适用场景：

• 文件型数据库（如 SQLite、Access）无 DBA 概念，返回结果无意义
• 部分云数据库（如 AWS RDS）可能限制管理员权限检测

• 结果可靠性：

• 若数据库配置了最小权限原则（Principle of Least Privilege, POLP），即使返回 True 也可能受限
• 建议结合 --privileges 进一步验证具体权限范围

• 💡--is-dba 通常位于信息收集阶段的关键步骤：

• 确认注入点 → sqlmap -u URL
• 获取用户身份 → --current-user
• 检测权限 → --is-dba
• 制定攻击路径：

• ✅ True → 尝试 --os-shell 或 --file-write
• ❌ False → 使用 --tables 枚举敏感数据

• 💎 总结：

• 核心价值：快速识别攻击面边界，避免触发不必要的防御机制
• 适用场景：授权渗透测试中的权限提升阶段
• 法律合规：仅限合法授权测试，未经许可使用可能违反《网络安全法》

• --users：用于枚举数据库管理系统（DBMS）中所有用户账户的核心命令参数。该功能在渗透测试的信息收集阶段至关重要，可帮助识别潜在的高权限账户或弱密码目标

• ⚙核心作用：通过 SQL 注入漏洞查询数据库的系统表（如 MySQL 的 mysql.user、SQL Server 的 sys.syslogins），列出所有注册用户账户

• 用户名格式：通常包含用户名和主机名（如 MySQL），或直接显示用户名（如 SQL Server）

• ⚙权限依赖：

• 需当前数据库连接用户具备系统表读取权限（如 SELECT 权限）
• 若权限不足，可能仅返回当前用户（--current-user）或空结果

• ⚡典型用法：

• 基础用法：sqlmap -u "http://1.1.1.1/vuln.php?id=1" --users
• 进阶组合命令：

• ⚠注意事项：

• 依赖注入漏洞：

• 仅在目标存在 有效 SQL 注入点 时生效。若 WAF 拦截或漏洞无效，可能返回空结果
• 可配合 --technique 指定注入技术（如 --technique=B 布尔盲注）绕过防御

• 数据库兼容性：

• 支持数据库：MySQL、SQL Server、Oracle、PostgreSQL 等主流 DBMS
• 不支持场景：

• 文件型数据库（如 SQLite、Access）无用户管理系统
• 云数据库（如 AWS RDS）可能限制系统表访问

• 结果准确性：

• 部分数据库返回的用户名可能包含系统服务账户（如 mysql.sys），需人工筛选
• 若需验证用户权限，可结合 --privileges -U 用户名 查看详细权限

• 📊SQLMap 用户枚举典型工作流：

• 确认注入点 → sqlmap -u URL
• 检测当前权限 → --is-dba
• 枚举用户 → --users
• 针对性攻击：

• 高权限用户 → 提取密码（--passwords）、执行命令（--os-shell）
• 低权限用户 → 枚举表结构（--tables）或结合其他漏洞提权

• 💎 总结：

• 核心价值：快速识别数据库账户体系，为横向渗透或权限提升提供目标
• 适用场景：授权渗透测试中的账户审计、弱密码爆破前置步骤
• 法律合规：仅限合法授权测试，滥用可能违反《网络安全法》

• --passwords：用于提取数据库用户密码哈希值的核心命令参数，适用于渗透测试中的权限提升阶段

• ⚙核心作用：通过 SQL 注入漏洞查询数据库系统表（如 MySQL 的 mysql.user、SQL Server 的 sys.syslogins），获取所有用户的密码哈希值（如 MySQL 的 authentication_string、SQL Server 的 password_hash）
• ⚙权限要求：

• ⚠️ 需当前数据库用户具备 系统表读取权限（如 SELECT 权限）
• 若权限不足（非 DBA），可能仅返回当前用户的哈希或空结果

• ⚡典型用法：

• 基础用法：sqlmap -u "http://1.1.1.1/page?id=1" --passwords
• 进阶组合命令：

• 🔓输出解析与密码破解：

• 哈希类型识别：

• SQLMap 自动识别哈希算法（如 MySQL 的 SHA1、SQL Server 的 0x0100…）
• 常见格式：

• MySQL 5.7+：*SHA1
• SQL Server：0x0100…（基于 SHA-512 的 PBKDF2）

• 哈希破解方法：

• 本地破解：

•  hashcat -m 100 hashes.txt rockyou.txt 
• MySQL SHA1 模式

• 在线破解：

• crackstation：https://crackstation.net/
• hashes：https://hashes.com/en/decrypt/hash
• cmd5：https://www.cmd5.com/

• ⚠注意事项：

• 依赖条件：

• 仅当目标存在 有效 SQL 注入漏洞 时生效，若 WAF 拦截可能失败
• 仅当目标存在 有效 SQL 注入漏洞 时生效，若 WAF 拦截可能失败

• 法律与道德：

• 仅限授权测试：未经许可使用违反《网络安全法》，可能面临法律责任
• 结果可能包含系统服务账户（如 mysql.sys），需人工筛选有效目标

• 隐蔽性优化：

• 添加 --delay=3 延迟请求，避免触发安全告警
• 使用 --proxy=http://127.0.0.1:8080 隐藏真实 IP

• 💎 总结：

• 核心价值：快速获取密码哈希，为横向渗透或权限提升提供关键凭证
• 典型工作流：

• 确认注入点 → sqlmap -u URL
• 检测权限 → --is-dba
• 提取哈希 → --passwords
• 针对性破解 → 使用 Hashcat 或在线工具

• 最佳实践：

• 优先针对高权限用户（如 root、sa）
• 结合 --privileges 验证用户权限范围

• ⚠️法律声明：操作需在授权环境下进行

• --privileges：用于 枚举数据库用户的权限信息 的核心命令参数，在渗透测试的权限评估阶段至关重要

• ⚙核心功能：通过 SQL 注入漏洞查询数据库系统表（如 MySQL 的 mysql.user、SQL Server 的 sys.syslogins），列出所有用户的权限范围（如 SELECT、INSERT、UPDATE、DROP 等）
• ⚙权限类型：

• 管理员权限：SUPER（MySQL）、sysadmin（SQL Server）
• 数据操作权限：SELECT、INSERT、UPDATE、DELETE
• 结构管理权限：CREATE、ALTER、DROP

• ⚙技术依赖：

• 需当前数据库用户具备 系统表读取权限（如 SELECT ON mysql.user）
• 若权限不足，仅返回当前用户权限或空结果

• ⚡典型用法：

• 基础用法：sqlmap -u "http://1.1.1.1/page?id=1" --privileges
• 进阶组合命令：

• ⚠注意事项：

• 依赖条件：

• 注入漏洞有效性：若目标不存在 SQL 注入或触发 WAF 拦截，结果可能为空
• 数据库兼容性：

• 支持：MySQL、SQL Server、PostgreSQL 等主流数据库
• 不支持：Access、SQLite 等无权限系统的数据库

• 权限结果解析：

• 权限名称为数据库原生术语（如 Oracle 的 EXECUTE ANY PROCEDURE）
• 部分权限（如 GRANT OPTION）允许用户转授权限，需重点关注

• 法律与隐蔽性：

• ⚠️仅限授权测试：未经许可使用可能违反《网络安全法》
• 建议添加 --proxy 或 --delay=3 降低操作痕迹

• 🔄典型权限评估工作流：

• 确认注入点 → sqlmap -u URL
• 枚举用户 → --users
• 权限分析 → --privileges
• 针对性操作：

• 高权限用户 → 执行命令（--os-shell）、提取密码（--passwords）
• 低权限用户 → 枚举表结构（--tables）或联合其他漏洞提权

• 💎 总结：

• 核心价值：快速识别用户权限边界，制定精准攻击路径，避免触发防御机制
• 适用场景：渗透测试中的权限审计、最小权限原则（POLP）验证
• 最佳实践：

• 优先针对具备 GRANT OPTION 或 SUPER 权限的用户
• 结合 --roles（Oracle/PostgreSQL）进一步验证角色继承权限

• ⚠️合规提示：操作需严格在授权环境下进行

• --roles：用于 枚举数据库管理员的角色信息 的核心参数，适用于支持角色管理的数据库（如 Oracle、PostgreSQL）

• ⚙核心作用：通过 SQL 注入漏洞查询数据库的系统角色表（如 Oracle 的 DBA_ROLES、PostgreSQL 的 pg_roles），列出所有角色及其权限范围
• ⚙适用数据库：

• Oracle：需当前用户具备 SELECT 权限访问 DBA_ROLES 表
• PostgreSQL/SQL Server：依赖系统视图（如 pg_roles）

• ⚙权限依赖：

• ⚠️ 需当前数据库用户拥有 系统表或视图的读取权限（如 Oracle 的 SELECT ANY DICTIONARY）
• 若权限不足，仅返回当前用户所属角色或空结果

• ⚡典型用法：

• 基础用法：sqlmap -u "http://1.1.1.1/vuln.php?id=1" --roles
• 进阶组合命令：

• ⚠注意事项：

• 数据库兼容性：

• 支持：Oracle、SQL Server、PostgreSQL 等支持角色管理的 DBMS
• 不支持：MySQL（无原生角色系统）、SQLite、Access

• 结果可靠性：

• 角色权限可能被继承或覆盖（如 PostgreSQL 的 INHERIT 属性），需结合 --privileges 验证
• 云数据库（如 AWS RDS）可能限制角色信息访问

• 法律与隐蔽性：

• ⚠️仅限授权测试：滥用可能违反《网络安全法》
• 建议配合代理（--proxy）或延迟（--delay=3）隐藏操作痕迹

• 🔄典型角色分析工作流：

• 确认注入点 → sqlmap -u URL
• 枚举用户 → --users
• 角色识别 → --roles
• 权限验证 → --privileges
• 针对性操作：

• 高权限角色（如 sysadmin）→ 尝试 --os-shell 或 --file-write
• 低权限角色 → 枚举敏感数据（--dump -T users）

• 💎 总结：

• 核心价值：快速识别数据库权限架构，辅助制定最小权限原则（POLP）绕过策略
• 适用场景：

• 渗透测试中的权限提升路径规划
• 数据库安全审计（如检测过度赋权角色）

• 最佳实践：

• 优先针对具备 ADMIN OPTION 的角色（如 Oracle 的 DBA）
• 结合 --schema 分析角色关联的系统对象

• --dbs：用于 枚举目标数据库管理系统（DBMS）中所有可访问的数据库名称 的核心命令参数。该操作通常在确认目标存在 SQL 注入漏洞后进行，是渗透测试信息收集阶段的关键步骤

• ⚙核心作用：通过 SQL 注入漏洞查询数据库的系统表（如 MySQL 的 information_schema.schemata、SQL Server 的 sys.databases），列出所有数据库名称
• ⚙权限依赖：

• 需当前数据库用户具备 系统表读取权限（如 MySQL 的 SELECT 权限）
• 若权限不足，可能仅返回部分数据库或空结果

• ⚡典型用法：

• 基础用法：sqlmap -u "http://1.1.1.1/vuln.php?id=1" --dbs
• 进阶组合命令：

• ⚠注意事项：

• 依赖注入漏洞有效性：

• 仅当目标存在 有效 SQL 注入点 时生效。若 WAF 拦截或漏洞无效，结果可能为空
• 可配合 --level 提升检测深度（默认 1，最高 5），增加检测成功率

• 数据库兼容性：

• 支持数据库：MySQL、SQL Server、Oracle、PostgreSQL 等主流 DBMS
• 不支持场景：

• 文件型数据库（如 SQLite、Access）无多数据库概念
• 云数据库（如 AWS RDS）可能限制系统表访问权限

• 结果可靠性：

• 返回的数据库名可能包含 系统内置库（如 mysql），需人工筛选有效目标
• 建议结合 --current-db 确认当前应用使用的数据库，优先聚焦关键目标

• 💡--dbs 位于 SQLMap 标准工作流的第二步：

• 确认注入点 → sqlmap -u URL
• 枚举数据库 → --dbs
• 选择目标库 → -D 数据库名
• 后续操作：

• 枚举表（--tables）→ 提取数据（--dump）
• 权限提升（--is-dba → --os-shell）

• 💎 总结：

• 核心价值：快速识别目标数据库体系，为后续表/列枚举提供方向
• 适用场景：授权渗透测试中的信息收集阶段、数据库资产梳理
• 最佳实践：

• 优先分析非系统数据库（如 dvwa、cms_db）
• 结合 --exclude-sysdbs 过滤系统库（如 information_schema）

• 法律合规：仅限合法授权测试，滥用可能违反《网络安全法》

• --tables：用于 枚举目标数据库中所有表名 的核心命令参数，通常在确认目标数据库（-D）后使用

• ⚙核心作用：通过 SQL 注入漏洞查询数据库系统表（如 MySQL 的 information_schema.tables、SQL Server 的 sysobjects），列出指定数据库内的所有表名

• 关键信息：

• 表名暴露业务逻辑（如 users 存储用户凭证，orders 存储交易数据）
• 系统表（如 mysql）通常需过滤，聚焦用户创建的表

• ⚙权限依赖：

• 需当前数据库用户具备 系统表读取权限（如 MySQL 的 SELECT 权限）
• 权限不足时仅返回部分表或空结果

• ⚡典型用法：

• 基础用法：sqlmap -u "http://1.1.1.1/vuln.php?id=1" -D 数据库名 --tables
• 进阶组合命令：

• ⚠注意事项：

• 依赖条件：

• 有效注入点：若漏洞被 WAF 拦截或无效，结果可能为空（可尝试 --level=5 提升检测深度）
• 数据库兼容性：

• 支持：MySQL、SQL Server、PostgreSQL 等主流数据库
• 不支持：SQLite/Access 等文件型数据库（无多表概念）

• 结果解析：

• 表名可能包含 临时表或备份表（如 tmp_orders），需人工筛选有效目标
• 建议结合 --columns 进一步分析表结构

• 隐蔽性与合规：⚠️仅限授权测试：滥用违反《网络安全法》，建议添加 --delay=3 或 --proxy 隐藏痕迹

• 🔄--tables 位于 SQLMap 标准流程的第三步：

• 确认注入点 → sqlmap -u URL
• 枚举数据库 → --dbs
• 选择目标库 → -D 数据库名
• 枚举表名 → --tables
• 后续操作：

• 提取表数据（-T 表名 --dump）
• 权限提升（--is-dba → --os-shell）

• 💎 总结：

• 核心价值：快速定位业务关键表（如用户/订单表），为敏感数据提取提供目标
• 适用场景：

• 渗透测试中的数据库结构侦察
• 安全审计（检测未授权访问表）

• 最佳实践：

• 优先分析含敏感关键词的表（如 user、passwd）
• 结合 --schema 导出完整数据库结构

• 法律声明：仅限合法授权测试

• --columns：用于枚举指定数据库表中所有字段名称及类型的核心命令参数，通常在确认目标数据库（-D）和表名（-T）后使用

• ⚙核心作用：通过 SQL 注入漏洞查询数据库系统表（如 MySQL 的 information_schema.columns），列出指定表的所有字段名、数据类型及约束信息

• 关键信息：

• 暴露表结构，识别敏感字段（如 password、email）
• 字段类型决定后续数据提取方式（如哈希值需用 hashcat 破解）

• ⚙权限依赖：

• 需当前数据库用户具备 系统表读取权限（如 MySQL 的 SELECT 权限）
• 权限不足时仅返回部分字段或空结果

• ⚡典型用法：

• 基础用法：sqlmap -u "http://1.1.1.1/vuln.php?id=1" -D dvwa -T users --columns
• 进阶命令组合：

• ⚠注意事项：

• 依赖条件：

• 有效注入点：若漏洞被 WAF 拦截，需配合 --tamper（如 space2comment）或 --level=3 提升检测深度
• 数据库兼容性：

• 支持：MySQL、SQL Server、PostgreSQL 等主流数据库
• 不支持：SQLite/Access 等文件型数据库（需直接读取文件）

• 结果解析：

• 字段名可能含 业务关键词（如 token、salt），需优先列为攻击目标
• 类型为 BLOB 或 BINARY 的字段需特殊处理（如 --hex 转换）

• 隐蔽性与合规：⚠️仅限授权测试：滥用违反《网络安全法》，建议添加 --delay=3 或 --proxy 隐藏痕迹

• 🔄--tables 位于 SQLMap 标准流程的第四步：

• 确认注入点 → sqlmap -u URL
• 枚举数据库 → --dbs
• 选择目标库 → -D 数据库名
• 枚举表名 → --tables
• 枚举字段 → -T 表名 --columns
• 后续操作：

• 提取敏感数据（-C 字段名 --dump）
• 提权攻击（--os-shell）

• 💎 总结：

• 核心价值：精准定位敏感字段（如凭证、密钥），为数据窃取或权限提升提供目标
• 最佳实践：

• 优先分析含 pass、token 等关键词的字段
• 结合 --schema 导出完整数据库结构

• 法律声明：仅限合法授权测试

• --search：用于在数据库内快速搜索包含特定关键词的表名或列名的功能，尤其适用于大型数据库的定向侦察

• ⚙技术原理：通过 SQL 注入漏洞查询数据库系统表（如 MySQL 的 information_schema.columns），模糊匹配用户指定的关键词（如表名含 user、列名含 pass）
• 💡适用场景：

• 快速定位敏感表（如用户凭证表、订单表）
• 绕过复杂数据库结构，直接锁定攻击目标

• ⚙权限依赖：需当前数据库用户具备 系统表读取权限（如 MySQL 的 SELECT 权限）
• ⚡典型用法：

• 基础语法：

• 搜索列名：sqlmap -u <目标URL> --search -C "username,password"
• 搜索表名：sqlmap -u <目标URL> --search -T "user,admin"

• 进阶用法：

• ⚠注意事项：

• 依赖条件：

• 需目标存在 有效 SQL 注入点，若被 WAF 拦截需配合 --tamper 混淆（如 space2comment）
• 数据库兼容性：支持 MySQL、SQL Server 等主流数据库，不支持 SQLite/Access

• 搜索逻辑：

• 关键词匹配为 大小写不敏感，支持通配符 %（如 %token% 匹配 user_token）
• 若未指定 -C 或 -T，默认同时搜索表名和列名

• 法律与隐蔽性：⚠️仅限授权测试：滥用违反《网络安全法》，建议添加 --delay=2 降低请求频率

• 🔄--search 通常位于侦察阶段末尾：

• 确认注入点 → sqlmap -u URL
• 枚举数据库 → --dbs
• 选择目标库 → -D 数据库名
• 枚举表名 → --tables
• 关键词搜索 → --search -C "password"
• 提取数据 → -T 敏感表 --dump

• 💎 总结：

• 核心价值：在大型数据库中高效定位敏感字段，缩短攻击路径
• 最佳实践：

• 优先搜索 pass、token、credit 等关键词字段
• 结合 --exclude-sysdbs 避免系统表干扰

• --comments：获取数据库管理系统（DBMS）中的注释信息，这些注释通常包含表、列、函数等对象的描述性文本，可能暴露业务逻辑或敏感设计细节

• ⚙核心作用：通过 SQL 注入漏洞查询数据库的系统表（如 MySQL 的 information_schema.COLUMNS 的 COLUMN_COMMENT 字段），提取目标对象的注释内容
• 💡适用场景：

• 辅助理解数据库设计逻辑（如字段含义、业务规则）
• 识别敏感字段（如注释含 encrypted、secret 等关键词）

• ⚙权限依赖：需当前数据库用户具备 系统表读取权限（如 MySQL 的 SELECT 权限）
• ⚡典型用法：

• 基础用法：sqlmap -u <目标URL> --comments
• 进阶组合命令：

• ⚠注意事项：

• 依赖条件：

• 数据库兼容性：

• 支持：MySQL、PostgreSQL（pg_description 系统表）、Oracle（ALL_TAB_COMMENTS）
• 不支持：SQLite、Access 等无系统表存储注释的数据库

• 注释信息可能被开发者清除或未添加，导致结果为空

• 安全与合规：

• ⚠️仅限授权测试：注释可能含敏感信息（如加密算法、密钥位置），滥用违反《网络安全法》
• 建议配合代理（--proxy）隐藏操作痕迹

• 🔄典型注释分析工作流：

• 确认注入点 → sqlmap -u URL
• 枚举数据库 → --dbs
• 枚举表名 → -D 目标库 --tables
• 提取注释 → -T 目标表 --comments
• 针对性操作：

• 发现敏感注释（如 encryption_key）→ 尝试提取密钥字段（-C 字段名 --dump）
• 识别业务逻辑漏洞（如注释提示弱校验）→ 设计绕过策略

• 💎 总结：

• 核心价值：揭示数据库设计细节，辅助渗透测试中的定向攻击（如定位加密字段、理解业务规则）
• 最佳实践：

• 优先分析含 key、token、secret 等关键词的注释
• 结合 --schema 导出完整元数据

• ⚠️合规提示：操作需严格在授权环境下进行，注释信息可能受《数据安全法》保护

• --statements：用于枚举数据库服务器上近期执行的 SQL 语句的参数，尤其在渗透测试中用于识别动态查询、存储过程或高频操作

• ⚙动态语句检索：--statements 会尝试从数据库的系统表（如 information_schema.PROCESSLIST（MySQL）、pg_stat_activity（PostgreSQL）或日志中提取近期执行的 SQL 语句

• 典型输出：包含 SQL 查询文本、执行时间、用户等信息
• 用途：识别注入点（如动态生成的查询）、分析数据库行为或定位敏感操作（如密码更新）

• ⚙依赖权限与数据库支持：

• 需当前数据库用户具备读取系统视图的权限（如 PROCESS 权限）
• 支持主流 DBMS（MySQL、PostgreSQL、SQL Server），但 SQLite/SQLite3 等嵌入式数据库通常不支持

• ⚡典型用法：

• 基本用法：sqlmap -u "http://1.1.1.1/page?id=1" --statements
• 指定数据库：sqlmap -u "http://1.1.1.1/page?id=1" -D test_db --statements
• 输出调试：sqlmap -u "http://1.1.1.1/page?id=1" --statements -v 3

• 💡适用场景：

• 注入点扩展：发现未直接暴露的注入漏洞（如存储过程中的动态 SQL）
• 数据库行为分析：监控后台任务或自动化脚本执行的敏感操作
• 权限提升验证：检查当前用户是否能访问系统级信息

• ⚠注意事项：

• 权限要求严格：非特权用户可能无法访问系统表（如 MySQL 需 SHOW PROCESSLIST 权限），导致返回空结果
• 输出内容受配置影响：

• 数据库若未启用查询日志（如 MySQL 默认关闭 general_log），则无法获取历史语句
• 仅捕获当前活跃会话的语句，历史语句可能需额外审计配置

• 性能与干扰：高频查询数据库时，--statements 可能触发安全告警（如大量读取系统表的行为）
• 无结果返回：检查权限（如 MySQL 执行 GRANT PROCESS ON *.* TO 'user'@'%';）或确认 DBMS 支持性
• 输出不完整：使用 -v 3 查看详细 payload 调试，或尝试 --fresh-queries 忽略缓存 

• 💎 总结：--statements 是 sqlmap 中高阶信息搜集的关键参数，适用于深入分析数据库行为或挖掘隐蔽注入点，但其有效性高度依赖权限和数据库配置。在具备足够权限的目标中，它能提供宝贵的行为洞察力；若遇权限不足，需优先尝试权限提升（如利用 --is-dba 验证）

• -D：用于指定目标数据库名称的核心参数，通常在已确认存在注入点并获取数据库列表（--dbs）后使用

• ⚙核心用途：

• 指定目标数据库：在枚举表名（--tables）、字段名（--columns）或提取数据（--dump）时，用 -D 明确操作的目标数据库
• 避免混淆：当服务器存在多个数据库时，必须用 -D 选定特定库，否则 SQLMap 默认操作当前数据库（--current-db）

• ⚡典型用法：

• 基础语法：sqlmap -u <目标URL> -D <数据库名> [后续操作参数]
• 常用组合场景：

• ⚠注意事项：

• 依赖前置步骤：

• 使用 -D 前必须先通过 --dbs 或 --current-db 获取有效数据库名，否则会报错
• 若未指定 -D，SQLMap 默认操作当前数据库（可通过 --current-db 确认）

• 特殊字符处理：若数据库名含空格或特殊字符（如 user data），需用引号包裹：-D "user data"
• 权限与兼容性：

• 需当前数据库用户具备目标库的读取权限，否则返回空结果
• 支持所有主流数据库（MySQL、SQL Server 等），但 SQLite/Access 需直接操作文件，无法使用 -D

• 🔄-D 位于 SQLMap 标准流程的第二步：

• 确认注入点 → sqlmap -u URL
• 枚举数据库 → --dbs
• 指定目标库 → -D 数据库名
• 枚举表名 → --tables
• 枚举字段 → --columns
• 提取数据 → --dump

• 💎 总结：

• 核心价值：-D 是精准定位目标数据库的关键参数，避免多库环境下的误操作
• 最佳实践：

• 始终在 --dbs 后使用，明确指定库名
• 结合 -T 和 -C 限定表及字段，提升效率

• 法律合规：仅限授权测试，滥用违反《网络安全法》

• -T：用于在 SQL 注入攻击中指定目标数据库中的表名，是精准定位数据的关键参数。需在确认数据库（-D）后使用，配合其他操作（如枚举字段或导出数据）

• 🔍定位目标表：在已知数据库（通过 -D 指定）后，用 -T 明确要操作的具体表，避免多表环境下的误操作

• 典型场景：枚举表字段、提取敏感数据（如用户凭证、订单信息）
• 权限依赖：需当前数据库用户具备目标表的 SELECT 权限

• ⚡典型用法：

• 基础语法：sqlmap -u <目标URL> -D <数据库名> -T <表名> [操作参数]
• 常用操作场景：

• ⚠注意事项：

• 依赖前置步骤：

• 必须先通过 -D 指定有效数据库名，否则报错。未指定 -D 时默认操作当前库（通过 --current-db 确认）
• 表名需通过 --tables 枚举获取，不可随意猜测

• 特殊字符处理：若表名含空格或特殊字符（如 user data），需用引号包裹：-T "user data"
• 权限与兼容性：

• 若用户无目标表读取权限，操作将返回空结果
• 不支持 SQLite/Access 等文件型数据库（需直接操作文件）

• 隐蔽性与合规：

• 高频请求易触发 WAF，建议添加 --delay=2 或 --proxy 隐藏 IP
• ⚠️仅限授权测试，未授权操作违反《网络安全法》

• 🔄SQLMap 标准流程中 -T 位于第三步：

• 确认注入点 → sqlmap -u URL
• 枚举数据库 → --dbs
• 指定目标库 → -D 数据库名
• 指定表名 → -T 表名
• 枚举字段 → --columns
• 提取数据 → --dump

• 💎总结：

• 核心价值：-T 是精准操作数据库表的关键参数，避免多表干扰，提升渗透测试效率
• 最佳实践：

• 始终在 -D 后使用，结合 --columns 或 --dump 定向提取数据
• 优先操作含敏感信息的表（如 users、admin）

• 扩展命令：

• 枚举表结构 → --schema
• 交互执行 SQL → --sql-shell

• -C：用于 指定目标字段（列） 的核心参数，通常与 -D（数据库名）、-T（表名）和 --dump（导出数据）等参数组合使用，实现精准提取特定列的数据

• 🔍核心用途：

• 指定目标字段：在数据提取阶段（--dump）或列名枚举阶段（--columns）时，用 -C 明确操作的目标列名，避免全表扫描
• 提升效率：仅提取关键列（如 username、password）可减少请求量，降低被防护系统拦截的风险
• 敏感字段定位：快速定位含敏感信息的列（如加密密钥、凭证字段）

• ⚡典型用法：

• 基础语法：sqlmap -u <目标URL> -D <数据库名> -T <表名> -C <列名1,列名2> --dump
• 常用组合场景：

• ⚠注意事项：

• 依赖前置参数：

• 必须组合使用：-C 需与 -D、-T 同时指定，否则 SQLMap 报错 Missing parameter(s)
• 列名合法性：若列名含空格或特殊字符（如 user name），需用引号包裹：-C "user name"

• 权限与效率优化：

• 最小权限原则：仅提取必要列，降低数据库负载和日志暴露风险
• 结合过滤条件：使用 --where 限定数据范围（如 -C credit_card --where "user_id=1001"）

• 安全与隐蔽性：

• 延迟请求：添加 --delay=2 降低请求频率，绕过 WAF 频控
• 混淆注入：配合 --tamper 参数（如 space2comment）混淆 SQL 语句

• 🔄-C 位于 SQLMap 数据提取流程的末端：

• 确认注入点 → sqlmap -u URL
• 枚举数据库 → --dbs
• 指定目标库 → -D 数据库名
• 枚举表名 → --tables
• 枚举字段 → --columns
• 指定列名提取数据 → -C 列名 --dump

• 💎总结：

• 核心价值：-C 是 SQLMap 精准数据提取的关键参数，尤其适用于渗透测试中快速获取高价值字段（如凭证、密钥）
• 最佳实践：

• 敏感字段优先：优先提取含 password、token、key 等关键词的列
• 结果验证：对加密字段（如 AES、MD5）结合 --sql-query 执行解密函数测试

• 法律合规：仅限授权测试，未授权使用 -C 提取数据违反《网络安全法》

•  -X：用于在枚举数据库表结构（如列名、数据）时跳过指定字段，避免扫描无意义或干扰性字段（如系统自动生成的 id、时间戳等）参数存疑

• 感觉用处不大，通常使用-C直接指定列名就行，而且第一次枚举列名能直接知道的只有id字段
• 虽然用处不大，但既然有这个参数，也列出来吧
• 英文：DBMS database identifier(s) to not enumerate
• 翻译：不枚举的DBMS数据库标识符
• 没做出来，指定不枚举mysql，实际还枚举了，也有可能是用法不对，网上也没找到相关资料

• 🔍排除特定字段：用于在枚举数据库表结构（如列名、数据）时跳过指定字段，避免扫描无意义或干扰性字段（如系统自动生成的 id、时间戳等），从而提升扫描效率并减少输出冗余
• 💡典型场景：

• 表中含大量低价值字段（如日志表的 create_time）时，排除后可快速聚焦敏感数据（如 password、api_key）
• 绕过系统库干扰（如 information_schema 中的默认字段），需配合 --exclude-sysdbs 使用

• ⚡典型用法：

• 基础语法：sqlmap -u <目标URL> -D <数据库名> -T <表名> -X <排除字段> [操作参数]
• 常用场景示例：

• ⚠注意事项：

• 依赖前置参数：

• 必须组合使用：-X 需与 -D（数据库名）、-T（表名）同时指定，否则 SQLMap 报错 Missing parameter(s)
• 字段名合法性：若字段含空格或特殊字符（如 user name），需用引号包裹：-X "user name"

• 效率与隐蔽性优化：

• 减少请求量：排除非关键字段可降低数据库负载及 WAF 触发风险
• 结合延迟参数：建议添加 --delay=2 控制请求频率，避免被防护系统拦截

• 与 --exclude-sysdbs 的区别：

• -X：排除表中字段
• --exclude-sysdbs：排除系统数据库（如 information_schema），两者可同时使用

• 🔄该参数通常与以下操作组合使用：

• 枚举字段：--columns
• 导出数据：--dump
• 统计条目：--count

• 💎 总结：

• 核心价值：-X 是 SQLMap 精准扫描的关键参数，尤其适用于快速定位高价值字段（如凭证、密钥）并规避干扰
• 最佳实践：

• 优先排除含 id、timestamp 等默认字段的表
• 结合 --columns 预检字段列表，再通过 -X 定制扫描范围

• 扩展命令：

• 系统库排除 → --exclude-sysdbs
• 敏感字段提取 → -C + --dump

• -U：用于指定目标数据库中的用户名，通常用于枚举用户权限、密码哈希或执行与特定用户相关的操作

• 🔍用户权限枚举：

• 查看用户权限：结合 --privileges 参数，可列出指定用户的数据库操作权限（如 SELECT、UPDATE 等）
• 提取密码哈希：配合 --passwords 参数，可获取指定用户的密码哈希值（如 MySQL 的 mysql.user 表）
• 权限依赖：需当前注入点具备 INFORMATION_SCHEMA 或系统表的读取权限

• ⚡典型用法：

• 基础语法：sqlmap -u <目标URL> -U <用户名> [操作参数]
• 常用场景与命令：

• ⚠注意事项：

• 依赖用户枚举：

• 使用 -U 前需通过 --users 获取有效用户名，否则返回空结果
• 若未指定 -U，--privileges 默认操作当前用户（通过 --current-user 确认）

• 权限与兼容性：

• 系统表依赖：操作需依赖数据库的系统表（如 MySQL 的 mysql.user），若无权限则失败
• 数据库支持：适用于 MySQL、PostgreSQL 等，不适用 SQLite/Access 等文件型数据库

• 安全与隐蔽性：

• 避免高频请求：添加 --delay=2 或 --proxy 降低触发 WAF 的风险
• 合规性：仅限授权测试，未授权操作违反《网络安全法》

• 🔄-U 常用于权限审计阶段：

• 枚举数据库用户 → --users
• 指定目标用户 → -U <用户名>
• 查看权限 → --privileges
• 提取密码哈希 → --passwords

• 💎 总结：

• 核心价值：-U 是 SQLMap 权限审计的关键参数，用于精准定位高危账户（如 root、admin）
• 最佳实践：

• 优先检查管理员账户：结合 --privileges 确认是否具备 SUPER 或 DBA 权限
• 密码哈希破解：对获取的哈希使用 --hash-id + --crack 联动破解工具（如 John the Ripper）

• 替代方案：

• 枚举所有用户权限 → sqlmap -u <URL> --privileges
• 获取当前用户信息 → sqlmap -u <URL> --current-user

• --exclude-sysdbs：用于排除系统数据库的关键参数，在枚举数据库、表或列时自动过滤默认的系统库（如 information_schema、mysql 等），避免干扰渗透测试结果

• 🔍过滤系统数据库：在枚举操作（如 --dbs、--tables）中跳过系统库，仅显示用户创建的数据库或表，提升结果的可读性
• 💡适用场景：

• 枚举非系统数据库：sqlmap -u <URL> --dbs --exclude-sysdbs

• 没成功，不知道为啥

• 统计用户表数量：sqlmap -u <URL> --count --exclude-sysdbs

• ⚙优化扫描效率：减少对无价值系统库的扫描请求，降低被 WAF 拦截的风险，同时缩短测试时间
• ⚡典型用法：

• 基础语法：sqlmap -u <目标URL> --exclude-sysdbs [枚举操作]
• 常用组合场景：

• ⚠注意事项：

• 依赖枚举操作：必须配合枚举参数（如 --dbs、--tables）使用，单独使用无效。若未指定枚举操作，SQLMap 会提示参数错误
• 数据库兼容性：

• 仅对支持系统库的 DBMS 有效（如 MySQL、PostgreSQL）
• 不适用于 SQLite、Access 等无系统库的数据库

• 权限要求：若当前数据库用户无权读取系统表，即使未排除系统库，枚举结果也可能为空。此时需先提升权限
• 与 -X 参数的区别：

• --exclude-sysdbs：排除系统数据库
• -X：排除表中字段（如 id, create_time），两者可叠加使用

• 💎 总结：

• 核心价值：--exclude-sysdbs 是高效聚焦业务数据的必备参数，尤其适用于快速定位高价值目标（如用户表、配置表）
• 最佳实践：

• 优先组合 --dbs 或 --tables：确保排除系统库后直接输出用户数据
• 敏感库优先枚举：如 users、admin 等含凭证的表应作为首要目标

• 替代方案：若需暴力破解表名（如 MySQL <5.0），使用 --common-tables 代替 --tables

• --pivot-column：用于 指定行转列操作的枢轴列（Pivot Column） 的特殊参数，适用于在枚举或导出数据时对结果进行行列转换

• 一般应该用不到
• 🔍行转列（Pivot）支持：

• 枢轴列指定：--pivot-column 用于在数据提取（如 --dump）时，将原始数据按指定列的值横向展开为多列，实现类似 SQL 中 PIVOT 操作的效果
• 优化输出结构：适用于将重复属性（如日期、类别）作为新列名，使结果更直观（例：将不同月份的数据转为列标题）

• 💡典型应用场景：

• 数据报表生成：如将订单表中的客户按月消费金额横向展示
• 敏感字段重组：将分散在多行的密钥或状态值聚合为单行多列

• ⚡典型用法：

• 基础语法：sqlmap -u <目标URL> --pivot-column=<列名> [其他操作参数]

• 参数依赖与组合：

• 必须与数据提取操作组合：--pivot-column 需搭配 --dump、--columns 或 --sql-query 使用，否则无效
• 典型工作流：

• 枚举表结构 → --columns -T <表名>
• 指定枢轴列 → --pivot-column=<列名>
• 导出转换后数据 → --dump

• ⚠注意事项：

• 列名合法性：

• 若枢轴列含特殊字符（如空格），需用引号包裹：--pivot-column="order date"
• 仅支持单列指定，不支持多列同时转置

• 数据库兼容性：

• 依赖目标数据库的 SQL 语法，对 SQL Server/Oracle 支持较好，而 SQLite/MySQL 需手动模拟 PIVOT
• 若数据库无内置 PIVOT 功能，SQLMap 会尝试通过多次查询模拟，可能显著增加请求量

• 性能与隐蔽性：

• 避免全表转置：结合 --where 限定数据范围（如 --where "year=2024"），减少数据量
• 延迟请求：添加 --delay=2 降低触发 WAF 的风险

• 💎 总结：

• 核心价值：--pivot-column 是 SQLMap 中少数支持数据重塑的参数，适合生成结构化报表或聚合敏感字段
• 手动替代方案：若目标数据库不支持自动转置，可用 --sql-query 执行自定义 PIVOT 语句： sqlmap -u <URL> --sql-query="SELECT * FROM sales PIVOT(SUM(amount) FOR month IN ('Jan','Feb'))"
• 法律合规：仅限授权测试，未授权使用可能违反《网络安全法》
• 操作建议：优先通过 --columns 确认枢轴列的唯一性（避免重复值导致数据错位）

• --where：用于 在导出数据时添加自定义筛选条件 的核心参数，通常与 --dump 组合使用，实现对特定数据的精准提取

• 🔍数据筛选导出：--where 允许在导出表数据（--dump）时附加 SQL WHERE 子句，仅导出满足条件的记录
• ⚙与核心参数的关系：

• 必须组合 -D（数据库名）、-T（表名）、--dump 使用，否则无效
• 若未指定 --where，默认导出全表数据

• 💡适用场景：

• 导出用户表中管理员账户（如 role='admin'）

• 提取特定时间范围的日志（如 create_time > '2025-01-01'）
• 过滤敏感字段（如 salary > 10000）以减少数据量

• ⚡典型用法：

• 基础语法：sqlmap -u <目标URL> -D <数据库名> -T <表名> --where "<SQL条件>" --dump
• 常用场景示例：

• ⚠注意事项：

• 条件字段必须存在：

• 若 --where 指定的字段名错误（如 roal 误写为 role），SQLMap 会报错 Invalid column name
• 解决方案：先用 --columns 确认表结构： sqlmap -u <URL> -D user_db -T accounts --columns

• SQL 注入风险：

• --where 的条件字符串会直接拼接到 SQL 语句中。若条件含特殊字符（如单引号），需用转义符处理（如 '）
• 中文条件需加 N 前缀（如 --where "name=N'张三'"）

• 与 -C 的优先级：若同时指定 -C（选择字段）和 --where，优先执行 --where 筛选，再提取 -C 指定的字段

• 💎 总结：

• 核心价值：--where 是高效提取 高价值目标数据 的利器，尤其适用于精准渗透测试（如定位管理员、财务数据）
• 最佳实践：

• 预检表结构：先通过 --columns 确认字段名及类型，避免条件错误
• 组合时间盲注：若条件含复杂逻辑（如子查询），改用 --sql-query 直接执行自定义 SQL
• 隐蔽性优化：添加 --delay=2 和 --proxy 降低触发 WAF 的风险

• ⚠️法律合规：所有操作需在 合法授权 范围内进行，滥用违反《网络安全法》

• --start：用于指定导出数据时的起始行号，通常与 --dump 或 --dump-all 结合使用，实现对大型数据表的分批导出（一般用不到，渗透测试严禁脱裤）

• 🔍分批导出数据：当目标表数据量过大（如百万行）时，一次性导出可能因网络或性能问题失败。--start 允许从指定行开始分段导出，例如 --start 100 --stop 200 表示导出第 100 到 200 行的数据
• 💡适用场景：

• 导出用户表（如 users）中特定区间的敏感数据（如第 1000–2000 条记录）
• 绕过数据库查询行数限制（如 MySQL 的 LIMIT 超时）

• ⚙与 --stop 联动：--start 必须与 --stop 组合使用，否则 SQLMap 会报错 Missing mandatory parameter '--stop'

• ⚡典型用法：

• 基础语法：sqlmap -u <目标URL> -D <数据库名> -T <表名> --start <起始行> --stop <结束行> --dump
• 常用场景：

• ⚠注意事项：

• 依赖其他参数：

• 必须组合使用：--start/--stop 需与 --dump 或 --dump-all 联动，否则无效
• 行号逻辑：行号从 1 开始计数（首行为第 1 行），例如 --start 1 --stop 9 导出前 10 行

• 性能优化建议：

• 添加延迟：对大表操作时建议添加 --delay=2（秒）避免触发 WAF 或锁表
• 跳过系统表：若目标表位于系统库（如 information_schema），需先用 --exclude-sysdbs 过滤

• 替代方案：若需导出随机数据（非连续行），可用 --where 条件筛选（如 --where "id>100 AND id<200"）

• 💎 总结：

• 核心价值：--start 是 SQLMap 高效处理大数据表的关键参数，尤其适用于分批次导出敏感数据（如用户凭证、交易记录）
• 最佳实践：

• 先通过 --count 统计表总行数（如 sqlmap -u <URL> -D db -T table --count），再规划分段区间
• 优先导出高价值字段（如 password、email），避免全字段导出导致的冗余

• 扩展命令：

• 统计表行数 → --count
• 条件筛选导出 → --where "column=value"

• ⚠️法律合规：所有操作需在授权测试范围内进行，滥用违反《网络安全法》

• --stop：用于在数据提取操作（如 --dump）时指定结束行号，通常与 --start 联合使用，控制导出数据的范围，避免一次性提取过多数据引发异常或触发防护机制（一般用不到，渗透测试严禁脱裤）

• 🔍限定数据提取范围：

• 当目标表数据量过大时，通过 --start 和 --stop 指定起始行和结束行，分批导出数据（如导出第 1-10 行）
• 降低风险：减少单次请求的数据量，避免因高频查询触发 WAF 或导致数据库响应超时

• 💡典型应用场景：

• 导出用户表前 10 条敏感数据（如账号密码）
• 测试阶段快速验证数据格式，无需全量导出

• ⚡典型用法：

• 基础语法：sqlmap -u <目标URL> --dump --start <起始行> --stop <结束行> [其他参数]
• 常用组合场景：

• ⚠注意事项：

• 依赖数据提取操作：

• 必须与 --dump 或 --sql-query 组合：单独使用 --stop 无效，需明确指定数据导出操作
• 需先枚举表结构：执行前需通过 --tables 和 --columns 确认目标表及字段

• 行号计算逻辑：

• 从 1 开始计数：--start 1 --stop 5 表示第 1 行到第 5 行（共 5 条）
• 避免越界：若结束行号超过表总行数，默认导出至最后一行

• 性能与隐蔽性：

• 延迟设置：添加 --delay=2 降低请求频率，减少被拦截风险
• 数据量控制：单次提取行数建议 ≤50 行，避免长时间查询引发告警

• 💎 总结：

• 核心价值：--stop 是 精准控制数据导出范围的关键参数，尤其适用于大型表的渗透测试或数据抽样验证
• 手动替代方案：若需动态分页，可通过 --sql-query 执行自定义分页 SQL： sqlmap -u <URL> --sql-query="SELECT * FROM users LIMIT 5 OFFSET 5"
• 最佳实践：

• 优先导出高价值字段（如 password、email），减少无关数据干扰
• 结合 --exclude-sysdbs 排除系统表，聚焦业务数据

• ⚠️法律合规：所有操作需在授权测试范围内进行，未授权使用违反《网络安全法》

• --first：用于 限制数据检索范围 的关键参数，主要作用是在枚举或导出数据时指定从查询结果的第几个字符开始提取。该参数通常与 --last 或 --dump 组合使用，避免一次性获取大量数据，提升测试效率和隐蔽性（没做出来）

• 🔍分段提取数据：在数据枚举（如 --dump）时，通过 --first=N 指定从结果字符串的第 N 个字符开始读取，避免全量导出触发 WAF 警报
• 💡典型场景：

• 分段导出密码哈希值：sqlmap -u <URL> --dump -C password --first=1 --last=10

• 分批次获取大字段内容（如日志、配置文本）

• ⚙隐蔽性优化：减少单次请求的数据量，降低被安全设备拦截的风险，尤其适用于敏感字段的渐进式窃取
• ⚡典型用法：

• 基础语法：sqlmap -u <目标URL> --first=<起始字符位置> [其他操作参数]
• 常用组合场景：

• ⚠注意事项：

• 依赖字段枚举操作：

• 必须与数据提取参数组合使用（如 --dump、--columns），单独使用无效
• 需先通过 --columns 确认字段类型，仅对文本型字段（如 VARCHAR, TEXT）有效

• 字符位置计算：

• 起始位置 --first=N 从 1 开始计数（非 0）
• 若 N 超过字段实际长度，返回空结果

• 与 --last 的优先级：

• 若未指定 --last，默认提取到字段末尾
• 组合 --start/--stop（行范围）时，执行顺序为：先按行筛选 → 再按字符位置截取

• 性能影响：分字符请求会显著增加查询次数，建议配合 --delay 降低请求频率（如 --delay=2）

• 💎 总结：

• 核心价值：--first 是精细化数据窃取的核心参数，尤其适用于绕过 WAF 流量监控或处理大字段
• 最佳实践：

• 预检字段长度：先通过 --sql-query="SELECT LENGTH(column) FROM table" 估算字符总量
• 自动化分片：编写脚本循环调用 --first 和 --last，实现全量数据自动分段导出
• 隐蔽性强化：结合 --proxy 和 --random-agent 隐藏真实 IP 及客户端特征

• 替代方案：

• 若需导出完整字段，直接使用 --dump 并添加 --threads=1 限制并发

• ⚠️法律合规：所有操作需在授权测试范围内进行，未授权使用违反《网络安全法》

• --last：用于 限制数据导出时字符截取范围的参数，通常与 --first 联合使用，控制输出内容的起始和结束字符位置。该参数适用于需要精确提取字段部分内容的场景（如长文本截断、敏感信息脱敏）

• 🔍字符范围限定：

• 截断输出内容：--last 指定输出内容的结束字符位置（从1开始计数），与 --first 组合可提取字段的特定片段
• 避免冗余数据：适用于处理大字段（如 description、content），仅获取关键片段

• 💡典型应用场景：