提到SQL注入很多新手的第一反应还是手工拼单引号可一旦到了实战靶场或者授权测试环境我更习惯让BurpSuiteSQLMap这套组合先开路BurpSuite负责抓包看清请求结构SQLMap负责自动化判别、验证和拉数据。前段时间我在Pikachu靶场上完整跑了一遍这套流程第一次用SQLMap的--dump参数把整张用户表导出来时那种效率上的落差非常直观。这篇文章就把从环境搭建、手工确认注入点到用SQLMap自动注入的完整链路写下来给同样卡在“会手工但不会自动化”阶段的读者做一份可以直接照着操作的路线图。1. 为什么先从Pikachu靶场这套组合开始1.1 Pikachu靶场的设计优势初学者最容易遇到的问题不是不会注入而是没有合法目标可以练。Pikachu靶场是我非常推荐的一个本地训练环境它最大的优点是覆盖了实际渗透测试和CTF里常见的SQL注入形态包括数字型、字符型、搜索型、报错注入、布尔盲注等。同一个站里集中了这么多场景省去了“换一个漏洞点就要重新搭建一套环境”的麻烦。它跟单纯的“漏洞演示页面”不同。很多演示页为了降低门槛直接把数字型注入放在页面上你用and 11就能通练完感觉像走过场。Pikachu至少做了两件事一是把不同SQL语句写法、不同参数位置都拆成独立模块你可以看到同一个注入诉求在不同代码写法下长什么样二是部分模块还模拟了少量输入过滤或特殊闭合方式让你提前接触真实业务里最常见的“不按套路出牌”。从训练节奏来看这套靶场适合从零开始的人也适合做自动化工具复测。你可以在里面放心大胆地把--level5 --risk3这种高参数跑上去因为目标就在本地不需要承担任何业务风险。等你在靶场里把SQLMap的脾气摸清楚了再去真实环境的授权测试里操作心里会踏实得多。1.2 BurpSuite是中间的“翻译官”很多人觉得BurpSuite就是个抓包改包工具实际上在自动化注入流程里它是连接手工分析与SQLMap之间的桥梁。为什么需要它因为SQLMap虽然支持直接用-u传URL可一旦目标接口有登录态、CSRF Token、复杂的JSON请求体或者需要在Header里带特定Cookie时直接拼URL就非常痛苦。BurpSuite可以把完整的请求原样保存下来包含请求行、请求头、请求体SQLMap通过-r参数读取后就是一次“原封不动”的请求发送。这个能力在真实授权测试中价值极大很多注入点都藏在POST表单或者带Session的请求里手工把请求再拼一遍不仅浪费时间还容易因为转义错误产生误判。我习惯把BurpSuite当作“第一道放大镜”。先通过抓包看清楚哪些参数真正进入后端逻辑Cookie里有什么是否有过滤规则返回状态码是否异常。这些信息会直接决定SQLMap扫描时的参数选择。工具可以帮助我们省力但上下文信息还是得靠BurpSuite来提供。1.3 SQLMap负责把“确认可行”变成“全自动”SQLMap的核心能力不只是“注入”它本质上是一个自动化的检测与利用框架。它会自动尝试不同payload、判断闭合方式、识别数据库类型甚至能做文件读写和命令执行。真正吸引人的是它帮你把“重复劳动”接走了。不过自动化不等于无脑跑。你需要给它清晰的输入请求文件、数据库类型、探测深度、是否跳过交互。这也是为什么我不建议新手一上来就只会敲sqlmap -u url --batch因为一旦请求里有动态参数、登录态或者过滤逻辑这条命令大概率扫不出东西。正确思路是先通过BurpSuite确定“这里大概率存在注入”再用SQLMap去做放大验证和数据提取。整个流程的设计逻辑可以概括成一句话BurpSuite给你上下文SQLMap给你效率人工负责判断和把关。2. 环境准备把靶场和工具链跑通2.1 本地靶场部署Pikachu靶场是一个典型的PHPMySQL应用部署方式不复杂。常见的做法是下载源码后解压到Web目录再用PHP集成环境启动服务。别忘了创建数据库并完成初始化配置否则访问页面时会一直卡在数据库连接报错上。PHP版本需要特别注意。太老的版本可能跑不起来太新的版本有时候会提示某些函数已被弃用最好按照项目说明选择一个兼容范围。数据库配置一般在源码的配置文件里字段包括数据库地址、账号、密码、库名。初始化时填错密码是最常见的坑我见过不少次“页面能打开但功能全报错”的情况最后发现就是配置文件里的数据库名写错了。部署完成后进入SQL注入模块页面提交一个正常的参数比如在字符型注入模块输入1并查询确认URL里出现了类似id1的参数同时页面能返回正常结果这套环境才算真正跑通。本地测试环境的价值就是可以随时重置如果改坏了配置重新解压一份源码再初始化即可。2.2 BurpSuite代理与证书细节BurpSuite默认监听127.0.0.1:8080。启动后打开Proxy设置确认代理端口正常再把浏览器的代理指向这个地址。访问纯HTTP页面时不需要证书但访问HTTPS页面时浏览器会报证书不可信需要从BurpSuite导出CA证书并安装到系统信任区。比手动配置浏览器更省事的方式是直接用BurpSuite内置浏览器。在Proxy的Intercept面板点击Open Browser打开的浏览器会自带代理配置第一次访问HTTPS站点时接受证书提示即可。这样能避免日常浏览器长期挂着代理减少“开着代理忘了关结果所有网站打不开”的乌龙。还有一个细节如果你开启了Intercept开关请求会被拦截在BurpSuite里浏览器界面会一直转圈。新手第一次用经常被这个现象吓到其实点一下Forward放行就行或者直接关闭Intercept让所有请求直接通过。2.3 SQLMap的安装与基本自检SQLMap依赖Python环境。命令行输入sqlmap --version如果能正常打印版本号和Python依赖信息说明核心环境没问题。部分系统还需要额外安装依赖库按提示安装即可。启动后可以先做一次“冒烟测试”不要直接上高参数。比如直接指定一个Pikachu的注入URLsqlmap -u http://127.0.0.1/pikachu/vul/sqli/sqli_str.php?id1submitsubmit --batch如果输出里出现了[INFO] testing connection to the target URL后面跟着Parameter id is vulnerable之类的提示说明SQLMap能正常检测到注入点。这一步跑通后后续的正式流程就只是操作层面的问题了。建议先跑一遍这个基础命令确认网络、代理、目标可达性没有问题再通过BurpSuite的请求文件进入更复杂的场景。3. 手工确认注入点自动化之前先看懂请求3.1 在BurpSuite里抓到第一条注入请求进入Pikachu字符型注入模块输入一个正常id并提交。BurpSuite的HTTP history面板里会多出一条请求点击可以看到请求行、请求头、请求体和返回响应。先做三件事第一确认参数名是id还是别的名称是GET参数还是POST参数第二看Content-Type和Cookie这决定了后续复现请求时要不要额外处理第三把这条请求右键保存为文件比如保存成sqli_str.req这就是SQLMap要用的输入。保存请求文件这一步非常关键尤其是后续要在命令行里反复跑SQLMap的场景。手动构造URL只能覆盖GET型简单请求遇到登录状态、POST参数、特殊Header时只有完整请求文件才能原样还原。3.2 用Repeater判断闭合方式把刚才那条请求右键Send to Repeater在Repeater里修改参数来手工验证。先尝试把id改成1发送后如果页面返回数据库语法错误说明单引号被拼进了SQL语句且没有被正确处理。接下来再分两次测试闭合逻辑。第一次改成1 and 11如果页面正常返回数据说明我们构造的恒真条件让SQL语句成立第二次改成1 and 12如果页面返回为空或明显不同就基本确认这是字符型单引号闭合注入。如果直接改1 and 11也有效且不需要引号那可能就是数字型注入。这里有个新手常犯的错误在Repeater里输入1时BurpSuite会自动编码成1%27这没问题后端收到的就是单引号。但如果你在某处提前把%也转义了就会变成双重编码导致后端收到错误字符。所以不要手动对参数乱加一层编码让工具自己处理即可。3.3 一张表理清注入类型判断手工阶段的目标不是“把数据拖出来”而是确认注入点类型和闭合方式。我把常见的判断特征整理成了下面这张表注入类型测试请求示例关键现象数字型注入id1 and 11正常id1 and 12无结果不需要闭合引号字符型单引号闭合id1报错id1 and 11正常需要闭合单引号搜索型注入keywordtest正常keywordtest%报错通配符参与拼接报错注入使用updatexml/extractvalue等报错函数看到错误回显数据库错误信息直接返回页面布尔盲注id1 and 11与id1 and 12页面均无报错但存在差异页面不直接展示数据但布尔状态可区分这张表只是辅助判断真正要掌握的是“看响应差异”的思路。不管返回的是数据行、报错信息还是空页面只要你在两个布尔条件之间稳定地看到差异就说明参数可以被利用。记住这个核心判断方法比背任何表格都重要。4. SQLMap自动化注入从请求文件到数据提取4.1 把BurpSuite请求转成SQLMap输入在BurpSuite的请求列表里右键选择Save item把请求保存成文本文件。这个文件通常包含完整的URL、请求方法、Header和BodySQLMap的-r参数就是为这种文件设计的。除了保存文件BurpSuite还支持复制为cURL命令。把cURL命令粘贴到终端时系统会调用curl发送同样的请求这也能配合SQLMap通过管道方式使用。但说实话Windows环境下复制长cURL命令很容易出现转义问题我更喜欢直接保存文件一劳永逸。拿到请求文件后可以先跑一条基础命令做验证sqlmap -r sqli_str.req --batch --dbmsmysql --level3 --risk2--batch的作用是让SQLMap不要停下来问“是否继续测试这个payload”这类问题全部选择默认选项--dbmsmysql跳过数据库类型指纹识别因为我们已经从Pikachu的环境知道它是MySQL--level3和--risk2决定了探测深度。第一次跑不需要一上来就拉满先用中等参数确认注入点可复现。4.2 扫描参数怎么选SQLMap的--level参数控制测试范围默认是1只会测我们指定的参数。提高到2或3以后会额外测试Cookie、User-Agent、Referer等HTTP头。--risk参数控制payload强度默认是1提高后可能引入基于时间盲注的长时间请求。靶场里我经常用--level5 --risk3跑因为目标就在本地不担心把数据库搞挂。但在真实授权环境中我不建议大家一上来就这么干。满级参数会让SQLMap产生海量请求轻则触发WAF封禁重则拖垮目标数据库。合理的做法是从--level2 --risk1开始扫不到再逐步提级。并发参数--threads也容易让人上头。我见过有人为了追求速度把线程设成10甚至更高结果目标直接丢连接反而拖慢进度。SQLMap默认单线程其实已经足够稳定除非目标响应很快、确认无风险否则不要轻易开高并发。4.3 分步拖数据而不是一把梭确认注入有效后很多人喜欢直接上--dump把整个库导出来。这在靶场里没问题但我建议养成“分步提取”的习惯对真实测试更友好。先看有哪些数据库sqlmap -r sqli_str.req --batch --dbmsmysql --dbs确定目标库后再看库下的表sqlmap -r sqli_str.req --batch --dbmsmysql -D pikachu --tables接着看表的字段结构sqlmap -r sqli_str.req --batch --dbmsmysql -D pikachu -T users --columns最后再提取关键字段sqlmap -r sqli_str.req --batch --dbmsmysql -D pikachu -T users -C id,username,password --dump分步的好处非常明显每一条命令执行时间短输出聚焦不容易因为整个表数据量巨大而卡死。测试报告上记录“哪张表、哪个字段、什么类型”也比“我把整个库都导出来了”要规范得多。靶场里的users表通常不大但你养成的操作习惯会带到以后每个项目里。4.4 多请求批量自动化的小脚本如果一个靶场里有多处疑似注入点可以把多个请求文件集中放到一个目录下然后用循环批量跑。用Shell写很简单for f in /path/to/reqs/*.req; do sqlmap -r $f --batch --level3 --risk2 --output-dir/tmp/sqlmap_out done--output-dir可以把每次扫描的结果分门别类保存到指定目录避免默认输出目录太深不好找。批量跑之前我强烈建议先用手工方式把目录里的每个请求过一遍确认哪些是真正的注入点然后把范围缩小到这几个文件再跑。这样既省时间也避免SQLMap对一堆无关URL做无用功。批量跑还有一个小技巧如果某个请求文件里包含POST表单可以直接把参数放在--data里但需要用-u指定URL。比如sqlmap -u http://127.0.0.1/pikachu/vul/sqli/sqli_str.php?id1 --datasubmitsubmit --batch这种方式适合临时验证但涉及完整登录态时还是建议用请求文件。5. 实战中翻车现场与排查思路5.1 SQLMap连不上目标最典型的场景是BurpSuite代理还开着但SQLMap在终端里并没有走这个代理于是请求发不出去。如果你开着BurpSuite的Intercept同时又想让SQLMap经过它需要额外给SQLMap设置代理参数。但多数时候我们不需要SQLMap经过BurpSuite直接让系统代理保持关闭、目标地址可达即可。还有一种情况是-r请求文件里的Host头指向不对。比如BurpSuite里访问localhost存下来的文件可能还是localhost或127.0.0.1而你的SQLMap运行环境里目标指向不同这时要手动修改请求文件中的Host头和URL保持一致。5.2 数据库类型识别错误Pikachu明确是MySQL直接指定--dbmsmysql可以省掉大量探测请求。如果你不确定目标数据库类型不要盲目指定先跑一次不带--dbms的扫描让SQLMap自己指纹识别。识别错误时最常见的表现是半天都在测试一堆奇怪的payload始终没有稳定结果日志里全是超时。应对办法很简单CtrlC停掉根据页面技术栈或报错特征推断数据库类型然后用--dbms精确指定重新开始。5.3 有简单过滤时怎么绕靶场里有的模块会模拟关键字过滤比如把空格或select替换掉。SQLMap内置了很多tamper脚本最常用的组合是sqlmap -r sqli_str.req --batch --tamperspace2comment,equaltolikespace2comment会把空格替换成注释符绕过部分关键字分割检查equaltolike把等于号替换成like绕一些简单的等于号过滤。注意tamper不是万能钥匙必须先搞清楚后端到底过滤了什么。比如它过滤了or和and那你得选versionedkeywords这类脚本而不是盲猜。除了tamperSQLMap还提供--prefix和--suffix来适配闭合方式。我一般先用BurpSuite Repeater手工确认单引号、双引号还是括号闭合拿个大概再让SQLMap去跑。这样能把误报率压到很低。5.4 出数据不全或编码乱SQLMap默认输出编码通常是UTF-8。但Windows终端直接打开UTF-8的CSV文件经常看到乱码。解决办法不是改SQLMap而是用支持编码转换的编辑器打开或者使用--dump-formatcsv导出后用Excel工具栏里的“自文本导入”按UTF-8读取。数据不全的问题多和请求不稳定有关。SQLMap遇到某个请求超时会选择跳过一部分payload最终输出结果自然会少。此时可以适当提高--timeout和--retries或者降低并发线程数让每个请求都能被可靠处理。5.5 Cookie和CSRF Token场景带登录态的页面请求文件里必须包含有效的Cookie。如果Cookie过期SQLMap会报出一堆401/302跳转根本扫不进注入逻辑。我的习惯是先登录目标再用BurpSuite抓取登录后的业务请求确保Cookie是新鲜的然后保存请求文件直接给SQLMap使用。如果页面有CSRF Token且每次请求都会变化SQLMap支持--csrf-token参数指定Token参数名后会自动从响应中提取新Token并更新请求。在Pikachu部分模块里可以练到这个场景实际项目中很多后台接口也都是这个套路。6. 自动化注入的合规边界与防御视角6.1 先确认授权再动手这套流程在靶场里怎么折腾都行但一旦切换到真实系统必须守住一条底线只有自己拥有的系统、CTF平台、或者已经拿到书面授权的目标才能运行SQLMap这类工具。授权范围要明确到域名、IP、测试时间段而不是“大概测一下”。授权测试里同样要控制扫描强度。不要一上来就--level5 --risk3 --threads10SQLMap的高等级参数会产生大量请求真实环境可能出现数据库连接被打满、接口超时雪崩的情况。测试的目的是发现漏洞不是把目标搞挂。先低参数验证再根据目标反馈决定是否提高强度才是合规又负责的做法。6.2 发现漏洞以后怎么做很多人第一次跑通SQLMap会很兴奋想顺手把整个库导出来看看。这个冲动必须克制。在授权测试中证明漏洞存在的最佳方式是提取最小化数据比如用户表中的用户名和密码长度而不是把整张表拖走。拿到能写进报告的产出后立刻停止扫描并准确上报漏洞位置、影响参数和修复建议。判断尺度很简单如果接下来的操作会让线上用户数据离开目标环境或者可能篡改业务数据就必须先停下来与业务方确认。靶场里可以随意玩真实环境里一次越界操作轻则测试终止重则影响职业生涯。6.3 给防守方的三点建议从攻击视角看过一遍之后再回头看防御会更有针对性。第一参数化查询是根治SQL注入的根本方案。只要用户输入不直接拼进SQL语句绝大多数注入点都会失效。第二输入校验和过滤只能作为纵深防御的一环不能当作唯一防线因为绕过方式永远在更新。第三日志与监控要关注异常特征某个参数短时间内出现大量单引号、and 11这类请求或者同一IP对同一接口高频访问都需要触发告警。自动化工具让攻击变得更廉价但也能在日志里留下更明显的痕迹。防守方的优势不在于“禁用一切工具”而在于能尽早发现测试行为并及时处置。我个人折腾这套流程最大的体会是BurpSuite让你看清请求SQLMap让你跑赢时间但真正能少踩坑的是“先手工确认、再自动放大”这个顺序。每次拿到注入点我都会先在Repeater里花两三分钟把闭合方式和注入类型定下来再让SQLMap去做重复劳动这样误报率会低很多。还有一个自己一直在用的小习惯跑完SQLMap后不要急着删请求文件把命令、参数和输出目录一起存到测试报告里下次遇到同类场景直接复用。这套组合在靶场上练熟之后面对大部分常规注入场景就已经够用了。 
长河君 · 2026/10/17 7:38:50 · 阅读 1.2k 从Pikachu靶场到SQLMap自动化：SQL注入检测实战指南
提到SQL注入很多新手的第一反应还是手工拼单引号可一旦到了实战靶场或者授权测试环境我更习惯让BurpSuiteSQLMap这套组合先开路BurpSuite负责抓包看清请求结构SQLMap负责自动化判别、验证和拉数据。前段时间我在Pikachu靶场上完整跑了一遍这套流程第一次用SQLMap的--dump参数把整张用户表导出来时那种效率上的落差非常直观。这篇文章就把从环境搭建、手工确认注入点到用SQLMap自动注入的完整链路写下来给同样卡在“会手工但不会自动化”阶段的读者做一份可以直接照着操作的路线图。1. 为什么先从Pikachu靶场这套组合开始1.1 Pikachu靶场的设计优势初学者最容易遇到的问题不是不会注入而是没有合法目标可以练。Pikachu靶场是我非常推荐的一个本地训练环境它最大的优点是覆盖了实际渗透测试和CTF里常见的SQL注入形态包括数字型、字符型、搜索型、报错注入、布尔盲注等。同一个站里集中了这么多场景省去了“换一个漏洞点就要重新搭建一套环境”的麻烦。它跟单纯的“漏洞演示页面”不同。很多演示页为了降低门槛直接把数字型注入放在页面上你用and 11就能通练完感觉像走过场。Pikachu至少做了两件事一是把不同SQL语句写法、不同参数位置都拆成独立模块你可以看到同一个注入诉求在不同代码写法下长什么样二是部分模块还模拟了少量输入过滤或特殊闭合方式让你提前接触真实业务里最常见的“不按套路出牌”。从训练节奏来看这套靶场适合从零开始的人也适合做自动化工具复测。你可以在里面放心大胆地把--level5 --risk3这种高参数跑上去因为目标就在本地不需要承担任何业务风险。等你在靶场里把SQLMap的脾气摸清楚了再去真实环境的授权测试里操作心里会踏实得多。1.2 BurpSuite是中间的“翻译官”很多人觉得BurpSuite就是个抓包改包工具实际上在自动化注入流程里它是连接手工分析与SQLMap之间的桥梁。为什么需要它因为SQLMap虽然支持直接用-u传URL可一旦目标接口有登录态、CSRF Token、复杂的JSON请求体或者需要在Header里带特定Cookie时直接拼URL就非常痛苦。BurpSuite可以把完整的请求原样保存下来包含请求行、请求头、请求体SQLMap通过-r参数读取后就是一次“原封不动”的请求发送。这个能力在真实授权测试中价值极大很多注入点都藏在POST表单或者带Session的请求里手工把请求再拼一遍不仅浪费时间还容易因为转义错误产生误判。我习惯把BurpSuite当作“第一道放大镜”。先通过抓包看清楚哪些参数真正进入后端逻辑Cookie里有什么是否有过滤规则返回状态码是否异常。这些信息会直接决定SQLMap扫描时的参数选择。工具可以帮助我们省力但上下文信息还是得靠BurpSuite来提供。1.3 SQLMap负责把“确认可行”变成“全自动”SQLMap的核心能力不只是“注入”它本质上是一个自动化的检测与利用框架。它会自动尝试不同payload、判断闭合方式、识别数据库类型甚至能做文件读写和命令执行。真正吸引人的是它帮你把“重复劳动”接走了。不过自动化不等于无脑跑。你需要给它清晰的输入请求文件、数据库类型、探测深度、是否跳过交互。这也是为什么我不建议新手一上来就只会敲sqlmap -u url --batch因为一旦请求里有动态参数、登录态或者过滤逻辑这条命令大概率扫不出东西。正确思路是先通过BurpSuite确定“这里大概率存在注入”再用SQLMap去做放大验证和数据提取。整个流程的设计逻辑可以概括成一句话BurpSuite给你上下文SQLMap给你效率人工负责判断和把关。2. 环境准备把靶场和工具链跑通2.1 本地靶场部署Pikachu靶场是一个典型的PHPMySQL应用部署方式不复杂。常见的做法是下载源码后解压到Web目录再用PHP集成环境启动服务。别忘了创建数据库并完成初始化配置否则访问页面时会一直卡在数据库连接报错上。PHP版本需要特别注意。太老的版本可能跑不起来太新的版本有时候会提示某些函数已被弃用最好按照项目说明选择一个兼容范围。数据库配置一般在源码的配置文件里字段包括数据库地址、账号、密码、库名。初始化时填错密码是最常见的坑我见过不少次“页面能打开但功能全报错”的情况最后发现就是配置文件里的数据库名写错了。部署完成后进入SQL注入模块页面提交一个正常的参数比如在字符型注入模块输入1并查询确认URL里出现了类似id1的参数同时页面能返回正常结果这套环境才算真正跑通。本地测试环境的价值就是可以随时重置如果改坏了配置重新解压一份源码再初始化即可。2.2 BurpSuite代理与证书细节BurpSuite默认监听127.0.0.1:8080。启动后打开Proxy设置确认代理端口正常再把浏览器的代理指向这个地址。访问纯HTTP页面时不需要证书但访问HTTPS页面时浏览器会报证书不可信需要从BurpSuite导出CA证书并安装到系统信任区。比手动配置浏览器更省事的方式是直接用BurpSuite内置浏览器。在Proxy的Intercept面板点击Open Browser打开的浏览器会自带代理配置第一次访问HTTPS站点时接受证书提示即可。这样能避免日常浏览器长期挂着代理减少“开着代理忘了关结果所有网站打不开”的乌龙。还有一个细节如果你开启了Intercept开关请求会被拦截在BurpSuite里浏览器界面会一直转圈。新手第一次用经常被这个现象吓到其实点一下Forward放行就行或者直接关闭Intercept让所有请求直接通过。2.3 SQLMap的安装与基本自检SQLMap依赖Python环境。命令行输入sqlmap --version如果能正常打印版本号和Python依赖信息说明核心环境没问题。部分系统还需要额外安装依赖库按提示安装即可。启动后可以先做一次“冒烟测试”不要直接上高参数。比如直接指定一个Pikachu的注入URLsqlmap -u http://127.0.0.1/pikachu/vul/sqli/sqli_str.php?id1submitsubmit --batch如果输出里出现了[INFO] testing connection to the target URL后面跟着Parameter id is vulnerable之类的提示说明SQLMap能正常检测到注入点。这一步跑通后后续的正式流程就只是操作层面的问题了。建议先跑一遍这个基础命令确认网络、代理、目标可达性没有问题再通过BurpSuite的请求文件进入更复杂的场景。3. 手工确认注入点自动化之前先看懂请求3.1 在BurpSuite里抓到第一条注入请求进入Pikachu字符型注入模块输入一个正常id并提交。BurpSuite的HTTP history面板里会多出一条请求点击可以看到请求行、请求头、请求体和返回响应。先做三件事第一确认参数名是id还是别的名称是GET参数还是POST参数第二看Content-Type和Cookie这决定了后续复现请求时要不要额外处理第三把这条请求右键保存为文件比如保存成sqli_str.req这就是SQLMap要用的输入。保存请求文件这一步非常关键尤其是后续要在命令行里反复跑SQLMap的场景。手动构造URL只能覆盖GET型简单请求遇到登录状态、POST参数、特殊Header时只有完整请求文件才能原样还原。3.2 用Repeater判断闭合方式把刚才那条请求右键Send to Repeater在Repeater里修改参数来手工验证。先尝试把id改成1发送后如果页面返回数据库语法错误说明单引号被拼进了SQL语句且没有被正确处理。接下来再分两次测试闭合逻辑。第一次改成1 and 11如果页面正常返回数据说明我们构造的恒真条件让SQL语句成立第二次改成1 and 12如果页面返回为空或明显不同就基本确认这是字符型单引号闭合注入。如果直接改1 and 11也有效且不需要引号那可能就是数字型注入。这里有个新手常犯的错误在Repeater里输入1时BurpSuite会自动编码成1%27这没问题后端收到的就是单引号。但如果你在某处提前把%也转义了就会变成双重编码导致后端收到错误字符。所以不要手动对参数乱加一层编码让工具自己处理即可。3.3 一张表理清注入类型判断手工阶段的目标不是“把数据拖出来”而是确认注入点类型和闭合方式。我把常见的判断特征整理成了下面这张表注入类型测试请求示例关键现象数字型注入id1 and 11正常id1 and 12无结果不需要闭合引号字符型单引号闭合id1报错id1 and 11正常需要闭合单引号搜索型注入keywordtest正常keywordtest%报错通配符参与拼接报错注入使用updatexml/extractvalue等报错函数看到错误回显数据库错误信息直接返回页面布尔盲注id1 and 11与id1 and 12页面均无报错但存在差异页面不直接展示数据但布尔状态可区分这张表只是辅助判断真正要掌握的是“看响应差异”的思路。不管返回的是数据行、报错信息还是空页面只要你在两个布尔条件之间稳定地看到差异就说明参数可以被利用。记住这个核心判断方法比背任何表格都重要。4. SQLMap自动化注入从请求文件到数据提取4.1 把BurpSuite请求转成SQLMap输入在BurpSuite的请求列表里右键选择Save item把请求保存成文本文件。这个文件通常包含完整的URL、请求方法、Header和BodySQLMap的-r参数就是为这种文件设计的。除了保存文件BurpSuite还支持复制为cURL命令。把cURL命令粘贴到终端时系统会调用curl发送同样的请求这也能配合SQLMap通过管道方式使用。但说实话Windows环境下复制长cURL命令很容易出现转义问题我更喜欢直接保存文件一劳永逸。拿到请求文件后可以先跑一条基础命令做验证sqlmap -r sqli_str.req --batch --dbmsmysql --level3 --risk2--batch的作用是让SQLMap不要停下来问“是否继续测试这个payload”这类问题全部选择默认选项--dbmsmysql跳过数据库类型指纹识别因为我们已经从Pikachu的环境知道它是MySQL--level3和--risk2决定了探测深度。第一次跑不需要一上来就拉满先用中等参数确认注入点可复现。4.2 扫描参数怎么选SQLMap的--level参数控制测试范围默认是1只会测我们指定的参数。提高到2或3以后会额外测试Cookie、User-Agent、Referer等HTTP头。--risk参数控制payload强度默认是1提高后可能引入基于时间盲注的长时间请求。靶场里我经常用--level5 --risk3跑因为目标就在本地不担心把数据库搞挂。但在真实授权环境中我不建议大家一上来就这么干。满级参数会让SQLMap产生海量请求轻则触发WAF封禁重则拖垮目标数据库。合理的做法是从--level2 --risk1开始扫不到再逐步提级。并发参数--threads也容易让人上头。我见过有人为了追求速度把线程设成10甚至更高结果目标直接丢连接反而拖慢进度。SQLMap默认单线程其实已经足够稳定除非目标响应很快、确认无风险否则不要轻易开高并发。4.3 分步拖数据而不是一把梭确认注入有效后很多人喜欢直接上--dump把整个库导出来。这在靶场里没问题但我建议养成“分步提取”的习惯对真实测试更友好。先看有哪些数据库sqlmap -r sqli_str.req --batch --dbmsmysql --dbs确定目标库后再看库下的表sqlmap -r sqli_str.req --batch --dbmsmysql -D pikachu --tables接着看表的字段结构sqlmap -r sqli_str.req --batch --dbmsmysql -D pikachu -T users --columns最后再提取关键字段sqlmap -r sqli_str.req --batch --dbmsmysql -D pikachu -T users -C id,username,password --dump分步的好处非常明显每一条命令执行时间短输出聚焦不容易因为整个表数据量巨大而卡死。测试报告上记录“哪张表、哪个字段、什么类型”也比“我把整个库都导出来了”要规范得多。靶场里的users表通常不大但你养成的操作习惯会带到以后每个项目里。4.4 多请求批量自动化的小脚本如果一个靶场里有多处疑似注入点可以把多个请求文件集中放到一个目录下然后用循环批量跑。用Shell写很简单for f in /path/to/reqs/*.req; do sqlmap -r $f --batch --level3 --risk2 --output-dir/tmp/sqlmap_out done--output-dir可以把每次扫描的结果分门别类保存到指定目录避免默认输出目录太深不好找。批量跑之前我强烈建议先用手工方式把目录里的每个请求过一遍确认哪些是真正的注入点然后把范围缩小到这几个文件再跑。这样既省时间也避免SQLMap对一堆无关URL做无用功。批量跑还有一个小技巧如果某个请求文件里包含POST表单可以直接把参数放在--data里但需要用-u指定URL。比如sqlmap -u http://127.0.0.1/pikachu/vul/sqli/sqli_str.php?id1 --datasubmitsubmit --batch这种方式适合临时验证但涉及完整登录态时还是建议用请求文件。5. 实战中翻车现场与排查思路5.1 SQLMap连不上目标最典型的场景是BurpSuite代理还开着但SQLMap在终端里并没有走这个代理于是请求发不出去。如果你开着BurpSuite的Intercept同时又想让SQLMap经过它需要额外给SQLMap设置代理参数。但多数时候我们不需要SQLMap经过BurpSuite直接让系统代理保持关闭、目标地址可达即可。还有一种情况是-r请求文件里的Host头指向不对。比如BurpSuite里访问localhost存下来的文件可能还是localhost或127.0.0.1而你的SQLMap运行环境里目标指向不同这时要手动修改请求文件中的Host头和URL保持一致。5.2 数据库类型识别错误Pikachu明确是MySQL直接指定--dbmsmysql可以省掉大量探测请求。如果你不确定目标数据库类型不要盲目指定先跑一次不带--dbms的扫描让SQLMap自己指纹识别。识别错误时最常见的表现是半天都在测试一堆奇怪的payload始终没有稳定结果日志里全是超时。应对办法很简单CtrlC停掉根据页面技术栈或报错特征推断数据库类型然后用--dbms精确指定重新开始。5.3 有简单过滤时怎么绕靶场里有的模块会模拟关键字过滤比如把空格或select替换掉。SQLMap内置了很多tamper脚本最常用的组合是sqlmap -r sqli_str.req --batch --tamperspace2comment,equaltolikespace2comment会把空格替换成注释符绕过部分关键字分割检查equaltolike把等于号替换成like绕一些简单的等于号过滤。注意tamper不是万能钥匙必须先搞清楚后端到底过滤了什么。比如它过滤了or和and那你得选versionedkeywords这类脚本而不是盲猜。除了tamperSQLMap还提供--prefix和--suffix来适配闭合方式。我一般先用BurpSuite Repeater手工确认单引号、双引号还是括号闭合拿个大概再让SQLMap去跑。这样能把误报率压到很低。5.4 出数据不全或编码乱SQLMap默认输出编码通常是UTF-8。但Windows终端直接打开UTF-8的CSV文件经常看到乱码。解决办法不是改SQLMap而是用支持编码转换的编辑器打开或者使用--dump-formatcsv导出后用Excel工具栏里的“自文本导入”按UTF-8读取。数据不全的问题多和请求不稳定有关。SQLMap遇到某个请求超时会选择跳过一部分payload最终输出结果自然会少。此时可以适当提高--timeout和--retries或者降低并发线程数让每个请求都能被可靠处理。5.5 Cookie和CSRF Token场景带登录态的页面请求文件里必须包含有效的Cookie。如果Cookie过期SQLMap会报出一堆401/302跳转根本扫不进注入逻辑。我的习惯是先登录目标再用BurpSuite抓取登录后的业务请求确保Cookie是新鲜的然后保存请求文件直接给SQLMap使用。如果页面有CSRF Token且每次请求都会变化SQLMap支持--csrf-token参数指定Token参数名后会自动从响应中提取新Token并更新请求。在Pikachu部分模块里可以练到这个场景实际项目中很多后台接口也都是这个套路。6. 自动化注入的合规边界与防御视角6.1 先确认授权再动手这套流程在靶场里怎么折腾都行但一旦切换到真实系统必须守住一条底线只有自己拥有的系统、CTF平台、或者已经拿到书面授权的目标才能运行SQLMap这类工具。授权范围要明确到域名、IP、测试时间段而不是“大概测一下”。授权测试里同样要控制扫描强度。不要一上来就--level5 --risk3 --threads10SQLMap的高等级参数会产生大量请求真实环境可能出现数据库连接被打满、接口超时雪崩的情况。测试的目的是发现漏洞不是把目标搞挂。先低参数验证再根据目标反馈决定是否提高强度才是合规又负责的做法。6.2 发现漏洞以后怎么做很多人第一次跑通SQLMap会很兴奋想顺手把整个库导出来看看。这个冲动必须克制。在授权测试中证明漏洞存在的最佳方式是提取最小化数据比如用户表中的用户名和密码长度而不是把整张表拖走。拿到能写进报告的产出后立刻停止扫描并准确上报漏洞位置、影响参数和修复建议。判断尺度很简单如果接下来的操作会让线上用户数据离开目标环境或者可能篡改业务数据就必须先停下来与业务方确认。靶场里可以随意玩真实环境里一次越界操作轻则测试终止重则影响职业生涯。6.3 给防守方的三点建议从攻击视角看过一遍之后再回头看防御会更有针对性。第一参数化查询是根治SQL注入的根本方案。只要用户输入不直接拼进SQL语句绝大多数注入点都会失效。第二输入校验和过滤只能作为纵深防御的一环不能当作唯一防线因为绕过方式永远在更新。第三日志与监控要关注异常特征某个参数短时间内出现大量单引号、and 11这类请求或者同一IP对同一接口高频访问都需要触发告警。自动化工具让攻击变得更廉价但也能在日志里留下更明显的痕迹。防守方的优势不在于“禁用一切工具”而在于能尽早发现测试行为并及时处置。我个人折腾这套流程最大的体会是BurpSuite让你看清请求SQLMap让你跑赢时间但真正能少踩坑的是“先手工确认、再自动放大”这个顺序。每次拿到注入点我都会先在Repeater里花两三分钟把闭合方式和注入类型定下来再让SQLMap去做重复劳动这样误报率会低很多。还有一个自己一直在用的小习惯跑完SQLMap后不要急着删请求文件把命令、参数和输出目录一起存到测试报告里下次遇到同类场景直接复用。这套组合在靶场上练熟之后面对大部分常规注入场景就已经够用了。