一叶扁jiang刷SQLi-Labs大概是每个做Web安全或者写后端接口的人迟早都会经历的事。我第一次自己搭起这个靶场的时候，前面less1到less4打得顺风顺水，union select一把梭，差点以为SQL注入就这么点东西。结果到了less5，页面突然不给你回显数据库内容了，只在报错信息里露一点数据，我当时愣了半天，才意识到前面几关只是热身，后面从报错注入到盲注、从GET到POST、从参数到Header、再到各种花式过滤绕过，才是一整套完整的攻防思维训练。这篇就围绕less1到less32的完整通关过程，把每一阶段的判断逻辑、关键payload思路、以及我踩过的坑全部梳理一遍。如果你正在刷这个靶场，或者在开发中想搞明白注入到底是怎么发生的，这篇应该可以帮你少走不少弯路。
SQLi-Labs这个靶场的价值不在于"打过去"，而在于它把SQL注入这个大类拆成了非常细致的子场景：字符型、整型、闭合方式变化、报错注入、布尔盲注、时间盲注、POST注入、Header注入、二次注入、过滤绕过、HTTP参数污染、宽字节注入。less1到less32恰好覆盖了绝大多数你能在真实系统里碰到的注入形态。下文按关卡阶段来讲，每个阶段会先说清楚"这段在练什么"，再给实际的判断方法和操作路径。
1. 环境准备与工具链：先把靶场跑起来，少踩三个坑
我一直觉得，刷靶场第一步不是研究SQL语法，而是把环境搭对。很多人卡在less5、less7这种关卡，其实不是不会注入，而是环境有问题——要么报错函数不生效，要么文件写入失败，要么PHP版本太新把旧函数废了。所以先花点篇幅讲环境，这比多刷三关更值。
1.1 环境搭建中最容易翻车的三个细节
SQLi-Labs是基于PHP和MySQL的，最常见的组合是在Windows上用phpstudy拉一个Apache环境，把源码丢到网站根目录，再改一下数据库连接配置就能跑。但有几个细节非常容易踩雷。
第一个是PHP和MySQL的版本选择。按照我的个人经验，PHP用5.x或7.x的低版本比较稳，MySQL用5.5或5.7都可以。因为SQLi-Labs很多关卡是基于MySQL报错函数来设计的，比如extractvalue、updatexml，这两个函数在MySQL 5.1.5以上才存在，MySQL 8.0里虽然也有，但很多报错行为已经变了，加上新旧版本对rand()、group by报错的处理有差异，less5和less6这类双查询注入的体验会差很多。如果用的是高版本MySQL，遇到报错注入打不出来的情况，优先怀疑版本问题，不用怀疑自己水平。
第二个是数据库报错信息是否可见。SQLi-Labs有一类关卡专门靠数据库的报错信息来传递数据，如果phpstudy或MySQL配置里把报错显示关了，那extractvalue这类函数即使执行成功，你也什么都看不到，会误以为自己payload写得不对。建议在MySQL配置里临时打开display_errors或者在PHP文件里加上error_reporting(E_ALL)，让报错信息能直观地展示出来。这一条对less5、less6、less13、less14都至关重要。
第三个是less7涉及的文件导出问题。这一关要用into outfile写webshell，能不能成功不仅取决于你有没有FILE权限，还取决于MySQL的secure_file_priv参数是否限制了导出目录。如果是Windows环境，secure_file_priv经常默认是NULL，也就是完全禁止导出，这时候需要在my.ini里设置一个允许导出目录并重启MySQL。另外，写入之前必须知道网站绝对路径，SQLi-Labs的默认路径一般是C:\phpstudy_pro\WWW\sql-labs\这样的目录，先通过报错注入或查看源码确认路径，再构造select '一句话木马' into outfile '绝对路径/webshell.php'才有效。这里必须强调一句：写webshell这种操作，只在本地靶场或者授权测试里才有意义，真实系统里这是严重违法行为，千万不能越界。
1.2 正式开刷前，先把这些工具和测试思路准备好
很多人刷靶场全程只靠浏览器地址栏手改URL，能刷到less10已经很牛了，但一旦进入POST注入和Header注入关卡，纯靠浏览器就不够用了，所以工具链得提前配好。
我常用的工具就三个：Burp Suite、浏览器开发者工具、hackbar插件。Burp Suite主要用来改包，尤其是less18之后的User-Agent、Referer、Cookie注入，必须拦截请求然后修改HTTP头，没有Burp的话操作效率会非常低。hackbar在Firefox上比较方便，能快速构造GET和POST请求，但到了后面几关你会发现，hackbar对Header头的控制还是不够灵活，最终还是要回到Burp。sqlmap也可以装一个，但我个人的建议是：前32关尽量用手工注入打完，不要一上来就跑工具。因为SQLi-Labs最大的价值是让你建立"判断注入点类型"的本能，这个本能只能靠手工一关一关喂出来。工具是后面提升效率用的，不是替代思考用的。
还有一点测试思路要提前说清楚——每一次注入，大脑里都要走一遍这四步：第一，参数是谁、以什么方式到后端；第二，参数最终被拼进什么类型的SQL语句；第三，SQL语句的闭合方式是什么；第四，执行结果通过什么渠道反馈到页面。带着这个框架去刷每一关，你会发现所有关卡本质上都是这四个问题的排列组合。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. less1-10：从回显注入到盲注的进化路线
less1到less10是一个完整的递进序列，它先把最常见的注入形式给你看一遍，然后一步步抽掉"回显"这个最容易利用的条件。如果你能把这十关理解透，SQL注入的底层逻辑基本就立住了。
2.1 less1-4：四组闭合方式，先学会从报错里"读"出规则
less1到less4外在表现很像，都是在URL的id参数上传值，页面会把数据库的查询结果显示出来，注入手法也都可以用union select解决。它们唯一的区别在于SQL语句的闭合方式不一样，而闭合方式恰恰是注入的第一步：你得先知道怎么把单引号、括号这些符号凑成一个语法成立的SQL语句。
less1是单引号字符型，后端SQL大概长这样select * from users where id='$id'，你传id=1'，多出来的单引号会让SQL报错，或者你直接构造id=1' order by 3--+来测列数；less2是整型，SQL长这样where id=$id，不需要闭合单引号，直接id=1 order by 3--+就行；less3是单引号加右括号，SQL是where id=('$id')，所以payload要写成id=1') order by 3--+；less4是双引号加右括号，SQL是where id=("$id")，得用id=1") order by 3--+。
这四关我建议用排除法去测，不要背答案。先输入一个单引号，看页面报错信息里SQL语句残缺的位置，这能直接告诉你闭合符号是什么。比如less3报错信息里会露出('1'')这种形态，你一眼就能看出它外面套了个括号。明白了闭合方式，后面所有关卡都是围绕"怎么把我们的查询语句合法地接到原始SQL后面"来展开。为了便于记忆，我把这四关的闭合情况整理成了表格：
| 关卡 | 注入类型 | 闭合特征 | 典型探测payload |
|---|---|---|---|
| less1 | 字符型 | 单引号 | id=1' |
| less2 | 整型 | 无引号 | id=1 |
| less3 | 字符型 | 单引号加右括号 | id=1') |
| less4 | 字符型 | 双引号加右括号 | id=1") |
这里还有个容易忽略的点：很多教程里习惯在payload末尾加--+，有些人以为--就是注释符，+是某种特殊语法。其实在MySQL里-- 后面必须跟一个空格才算注释，URL里的+经过URL解码后会变成空格，所以--+的作用就是提供一个合法的注释结尾，把原始SQL后半段的多余符号屏蔽掉。如果你用Burp发原始包，直接写-- 也是可以的。
2.2 less5-7：失去回显位之后，用报错和文件读写拿数据
less5开始，玩法突然变了。你输入id=1' union select 1,2,3--+，页面并不会把2和3显示出来，它只说"Your Login name: xxxx"，只显示第一条记录的第一个字段。这就是所谓的"没有回显位"，union联合查询的方案在这里失灵了。我当初就在这关卡了很久，后来才意识到，既然查询结果不能直接显示，那就想办法让数据库把数据通过报错信息带出来。
less5和less6用的是双查询报错注入，常见的手法是用extractvalue来构造XPATH错误：id=1' and extractvalue(1,concat(0x7e,(select database()),0x7e))--+。这里concat(0x7e,(select database()),0x7e)是把数据包在一对波浪号中间，extractvalue因为第二个参数不是合法XPATH表达式而报错，报错信息里就会带出我们的查询结果。less5和less6结构上一模一样，差别只在闭合符号，less6是双引号闭合。这一类的替换思路同样适用于updatexml，两个函数的报错原理是相通的：目标路径格式错误时MySQL会把路径内容回显出来，我们只要把SQL查询构造在路径里就成了。
除了extractvalue和updatexml之外，less5还经常被用来演示floor(rand(0)*2)的分组报错方式。核心payload类似id=1' union select 1,count(*),concat((select database()),floor(rand(0)*2))x from information_schema.tables group by x--+。这个方法的原理稍微绕一点：rand(0)产生的序列是确定的，group by在计算分组键时会对floor(rand(0)*2)重复求值，前后两次值不一致导致主键冲突，MySQL会把冲突信息显示出来，查询的数据也就跟着出去了。不用把原理背多熟，但至少要知道报错注入不是只有一条路，而是围绕"让数据库在错误信息里带出数据"这个思路可以变出很多工具。
less7是文件读写关卡，利用id=1')) union select 1,2,3 into outfile "绝对路径/xxx.php"--+把一段内容写进网站目录。这关需要注意的前提我前面已经说了：文件权限、secure_file_priv目录限制、绝对路径，三者缺一不可。如果你在靶场里写文件成功，进webshell看一眼，然后一定要把测试文件删除掉，不要留着当靶场里的"战利品"，养成好习惯。
2.3 less8-10：布尔盲注与时间盲注的猜解思路
less8到less10又是一次条件收紧。less8里你输入任何错误的id，页面都不会报错，也不显示数据库内容，唯一的差别是正确时页面上有两个不同的文案：在SQLi-Labs里，条件为真时页面显示类似"You are in"的内容，条件为假时什么都显示不出来。这就是布尔盲注：你无直接回显，但可以利用"真/假"两种页面状态来一比特一比特地猜数据。
布尔盲注的基本逻辑很简单：先构造一个条件语句，比如id=1' and left(database(),1)>'a'--+，如果页面显示正常，说明条件为真；如果页面空白，说明条件为假。然后配合substr、ascii、ord这些函数逐字符逼近：先用二分法判断字符范围，再精确到具体字符。手工一个个试会非常痛苦，我一般是先在脑子里把思路走通，写一个简单的Python脚本自动跑。脚本的思想其实就三行：循环字符位置、循环候选字符、根据页面内容判断真假。等你能把这个脚本写出来，说明你已经真正理解布尔盲注在干什么了，而不是在背payload。
less9更进一步，连页面显示的真假差异都没有了——你输入什么都显示同样的结果。这时候只能用时间盲注，思路是让SQL语句根据条件决定是否执行sleep()：id=1' and if(ascii(substr(database(),1,1))>97,sleep(3),0)--+。如果页面响应明显延迟了，说明条件为真，否则为假。less10只是把闭合符号换成了双引号，判断方法完全一样。时间盲注在实际测试里比布尔盲注更依赖网络环境的稳定性，如果目标服务器响应本身就在抖动，光靠"有没有延迟"判断会有很大误差，所以判断条件时最好把sleep的时间设长一点，比如3秒，并且多次重试确认。
盲注这一段，我的核心建议是：理解判定的层次，高优先顺序是从页面内容差异到响应时间差异。页面有差异优先布尔盲注，页面无差异才上时间盲注，不要一上来就sleep。而且不管哪种盲注，你都要能写出自动化脚本，哪怕只是临时用requests库写几十行，也能大幅提升效率，还能帮你验证自己的逻辑是否正确。
3. less11-22：从GET到POST，从参数到Header
从less11开始，注入点从URL参数转移到了POST请求体，再从POST的登录表单转移到了HTTP头部的User-Agent、Referer和Cookie。这个阶段的意义在于告诉你：SQL注入的本质是"用户的输入被拼进了SQL"，而输入并不只存在于URL地址栏里，数据进入后端的渠道比你想的多得多。
3.1 less11-16：登录框只是换了个注入位置
less11到less16都是POST型注入，后端处理的是登录表单里的uname和passwd。环境改变之后，你唯一需要调整的是把payload放在POST请求体里，而不是URL上。less11是最经典的POST单引号注入，在用户名框里填admin' or '1'='1，密码随便填，就能登录成功。这就是常说的万能密码，它实际上是把整个WHERE条件变成了username='admin' or '1'='1'，恒为真，于是绕过了密码校验。
less12到less16的思路，和GET型那一批是对应关系，只是POST参数换成了表单字段。less12是双引号加右括号闭合，less13是单引号加括号但没有回显位，要配合报错注入，less14是双引号配合报错注入，less15和less16则是POST型盲注，尤其less16是双引号加括号的盲注。这一批关卡如果你在GET型部分已经把闭合方式的判断逻辑练熟了，这里你只需要在Burp里把请求方法改成POST，把payload填进uname字段，剩下的判断流程完全一致。
这里我要强调一个很多人会忽视的问题：用hackbar发POST数据确实方便，但它改不了请求头，也不便于观察完整的请求报文，所以我个人建议从现在开始就把Burp的Repeater当作主战场。点击浏览器里的目标链接，打开Burp历史，找到这条POST请求，右键发到Repeater，然后在uname=xxx&passwd=xxx这种格式的请求体里改参数，响应结果在右侧面板直接看。这样你才能同时看到请求和响应的完整结构，不容易漏掉细节。
3.2 less17：藏在修改密码流程中的UPDATE注入
less17是很多人第一次接触"注入点不在SELECT语句里"的关卡。这个页面的逻辑是：先输入用户名，再输入新密码，提交后后台会执行类似update users set passwd='$passwd' where username='$uname'这样的UPDATE语句。注入点虽然在$uname字段，但你不能用union select直接查数据，因为UPDATE语句根本没有查询结果的回显渠道。
less17的常规打法是报错注入：在用户名里构造admin' and extractvalue(1,concat(0x7e,(select database()),0x7e))#这样的payload，让UPDATE在更新过程中触发XPATH报错，把数据带出来。这里最需要注意的是闭合和注释符的位置：你在$uname里结束单引号后，必须用注释符把原始SQL后面的'和where之后的内容处理掉，否则整个UPDATE语句会因为语法问题直接失败，连报错都未必是你要的那个。另外，这一关也提醒了一个很重要的防御视角：不只是查询接口有注入风险，凡是把用户输入直接拼进SQL的地方都会有，包括更新、删除、插入语句，而后者的危害往往更直接。
3.3 less18-22：User-Agent、Referer、Cookie与Base64编码
less18开始，注入点跑到了HTTP头里。less18检查的是User-Agent字段，页面会显示你的IP和UA信息，后端把UA拼进了INSERT或SELECT语句里，所以你在UA字段里注入比在URL参数里注入更有效。测试方法是：用Burp拦截请求，把User-Agent: xxx改成User-Agent: 1' and extractvalue(1,concat(0x7e,(select database()),0x7e))#，观察响应。判断流程和之前的报错注入完全一样，唯一的区别是输入的位置变了。
less19是Referer字段注入，less20是Cookie字段注入。less19的Referer字段通常就是当前页面的URL，改包时在Referer: 页面URL后面接注入语句即可。less20则要特别注意：Cookie的格式是uname=admin; passwd=xxx这种分号分隔的结构，注入时要针对uname和passwd两个字段测试，而且Cookie里经常带有PHP的会话标识PHPSESSID，改包时不要把会话标识删了，否则可能影响登录状态。
到了less21和less22，Cookie的值被加了一层Base64编码。这关让很多新手抓狂——在Cookie里直接写uname=admin' and extractvalue(...),不仅注不进去，整个登录状态都可能异常。正确思路是：先用工具或在线解码函数看一下原来的Cookie值，发现uname的值是Base64编码后的结果，那就把你构造好的payload整段做一次Base64编码，再填回Cookie里。less21是单引号闭合，less22是双引号加括号闭合，先解码看原始格式再决定payload，这个顺序不能乱。
4. less23-32：过滤规则下的绕过实战
到了less23，靶场开始模拟真实系统里的"防护代码"。这些关卡不会直接告诉你规则是什么，你要通过报错和反馈去推断服务端过滤了哪些字符，然后想办法绕过。从这开始，刷靶场的重心从"注入能不能成"转为"在特定规则约束下注入怎么写"，这对后续分析真实系统非常有帮助。
4.1 less23-26：注释符、逻辑词、空格被过滤后的写法
less23过滤的是注释符，#、--+、-- 这些统统被替换了。很多人一上来就懵，因为SQL语句里的尾部闭合全靠注释符来处理。这一关的解法是转个思路：不靠注释屏蔽后半句，而是构造一个逻辑上自洽的表达式。比如less23是单引号闭合，原始SQL是where id='$id'，你构造id=1' or '1'='1，最终SQL变成where id='1' or '1'='1'，后半段多出来的'被'1'的最后一个引号合法地接收了，整个语句语法成立。顺着这个思路，union注入也可以写：id=-1' union select 1,database(),3 or '1'='1，后面的or '1'='1是负责收尾的。
less24是二次注入，单独放一节讲，因为它太值得单独说了。less25过滤的是or和and，不区分大小写，直接整段替换为空。但这过滤写得很粗糙，经典绕过方法就是双写：oorr被替换or和and后，中间的or被删掉一个，剩下的or就还原了。举个例子，id=1' oorr '1'='1经过代码preg_replace('/or/i','',...)之后变成id=1' or '1'='1，完美绕过。另外还可以用大小写变体Or、oR，或者用符号替代||、&&。
less26过滤的是空格和注释符。空格被过滤后，SQL里的词与词之间怎么分隔？MySQL里可以用括号、Tab、换行（URL编码的%0a）、或者/**/来替代空格。比如id=1'%0aunion%0aselect%0a1,database(),3||'1'='1这种写法。这一关的体验很像在做文字游戏，但核心思想非常重要：过滤规则再强也总有没考虑到的替代字符。开发者在做安全防护时也要明白，过滤黑名单是永远不可靠的，只有参数化查询、预编译语句、白名单校验这些方式才能根治问题。
4.2 less24：二次注入，入库时不发作，使用时才引爆
less24是SQLi-Labs里极有代表性的一关，因为它模拟的是二次注入的完整链路。你在注册页面上填写用户名的时候，后端是用了转义函数把输入中的引号转义后才写入数据库的，所以注册阶段并没有注入发生。但这个被转义后的数据是被原样存进数据库的，比如你注册的用户名是admin'#，数据库里存的也是admin'#。等你登录这个账号后，再进入修改密码的页面，后台会直接把这个用户名拼进UPDATE语句里，却没有再转义一次——这时候问题就爆发了。
具体来说，修改密码的SQL类似update users set passwd='新密码' where username='$uname'，当$uname是admin'#时，整条语句变成update users set passwd='x' where username='admin'#'，#把后面所有内容注释掉了，实际上更新的就是admin这个账号的密码。于是，你只需要注册一个admin'#的恶意用户名，然后登录它去修改密码，就可以把真正的管理员密码改掉。我在刷这关的时候最大的感触是：二次注入的危害不在于攻击者"当场"做了什么，而在于数据被"信任"地存储下来后，在另一个模块被不安全地使用。它说明单点防御不可靠，整个数据流链路里任何一段拼接SQL，都可能是突破口。
4.3 less27-31：union/select过滤与HTTP参数污染
less27和less28过滤的核心词是union和select，less27直接把这两个词大小写不敏感地替换为空，less28则把union select这个组合当成一个整体来过滤，试图阻止联合查询。面对大小写敏感过滤，绕过方式很简单：UnIoN SeLeCt、UNION SELECT这些变体就足够了。面对less28那种把union select组合整体替换的过滤，可以用内联注释拆分：un/**/ion sel/**/ect，因为MySQL支持在关键字中间插入注释，解析时un/**/ion会被识别成union，而过滤正则匹配的是完整的字面量union select，中间的注释让它匹配不上。
less29到less31进入了HTTP参数污染（HPP）的场景，这三关的真实背景是：前端系统用Java/Tomcat解析请求时，如果URL里出现重复参数?id=1&id=2，Tomcat取前一个；而PHP解析时取后一个。所以WAF层在拦截请求时可能只检查Tomcat看到的参数值，而PHP最终拼接进SQL的却是后一个参数值——两边看到的东西不一样，就产生了绕过空间。在SQLi-Labs里，这三关模拟了带WAF的登录校验层和实际处理SQL的业务层，你需要在URL里同时传两个id：第一个是给WAF看的无害值，第二个才是真正注入的payload，比如?id=1&id=1' union select 1,database(),3--+。less29是单引号闭合，less30是双引号闭合，less31是双引号加右括号。这一类漏洞在真实的复杂系统架构里确实存在，尤其是多语言混合开发的场景，理解"不同组件对同一请求的解析差异"比单纯记payload重要得多。
4.4 less32：宽字节注入，一次字符集层面的"打包放行"
less32是我认为整个前32关里最值得反复琢磨的一关，因为它的绕过逻辑不在SQL语法层面，而在字符集编码层面。这个关卡的代码用了mysql_real_escape_string这类函数，把输入里的单引号自动转义成\'——也就是在单引号前加一个反斜杠，试图让单引号失去字符串边界作用。你直接输入1'，后端会把它变成1\'，单引号被反斜杠转义，注入失效。
但问题是，如果MySQL连接的字符集是GBK，而输入里带着%df这样的字节，情况就变了。%df%5c在GBK编码下会被解析成一个汉字字符"運"，因为GBK是双字节编码，第一个字节0xdf和第二个字节0x5c（也就是反斜杠的ASCII码）组合成了一个合法的汉字。我们的单引号的URL编码是%27，后端转义时会在它前面插入反斜杠%5c，整个序列变成%df%5c%27。MySQL用GBK解读这段字节流时，前两个字节%df%5c被识别成一个汉字，剩下的%27仍然是一个独立的单引号——转义失败了。
用一个生活化的类比来理解：好比安检员检查行李时，规定"看到危险品就把它单独扣下"，但如果危险品和另一个普通物品被胶带粘在一起，安检员把它们当一个整体放行了，等到行李进了内部，危险品才被拆出来生效。%df就是这个"胶带"，反斜杠和它绑在一起被当成了普通汉字，单引号就逃过了检查。验证这个方法很简单，直接在MySQL里执行select hex(convert('%df%5c' using gbk))，看看结果是不是两个字节的汉字编码，你就明白为什么%df'能绕过转义了。
less32给你的教训非常深刻：安全过滤函数不是万能的，它的有效性取决于数据库字符集与过滤逻辑之间的配合关系。这也是为什么现在的主流方案都强调参数化查询，因为只要SQL结构预编译好，数据部分再怎么编码，也不可能改变语句语义。
5. 32关刷完后的思维升级：从"背 payload"到"建模型"
less1到less32全部走完一遍之后，如果你只是记住了每关的payload，那收获很有限。真正的变化应该体现在思维方式上：看到任何一个参数，你能快速回答四个问题——输入在哪里、被拼到哪类SQL、闭合规则是什么、结果怎么反馈。我复盘整个靶场后，最大的体会是可以把打法归纳成一个通用流程，以后遇到陌生目标也能快速套用。
5.1 一套通用的注入点识别流程
从less1到less32，所有关卡的判断步骤可以压缩成下面这条链路，按顺序执行，基本不会漏判：
- 输入一个单引号和一个双引号，分别观察页面是否报错、报错位置在哪里，这决定了注入类型和闭合符号。注意区分字符型、整型和各种加括号的变体。
- 判断是否有回显位。尝试union select几个占位数字，看页面是否显示查询结果。能显示就继续联合查询，不能显示就进入下一步。
- 判断报错信息是否可见。如果数据库报错能直接显示出来，就可以用
extractvalue、updatexml这类报错函数把查询结果带出来。 - 如果页面没有报错、没有回显，就需要走盲注路线。先观察条件真和条件假时页面是否有内容差异，有差异就布尔盲注；没有差异就只能时间盲注。
- 如果常规的引号被过滤，尝试宽字节、双写、大小写、内联注释、等价符号替换等方式，前提是搞清楚过滤器到底过滤了什么规则。
- 如果注入点不在URL参数里，就扩展到POST参数、Cookie、User-Agent、Referer等所有输入渠道。
把这条链路带到每一关里去跑，你会发现less5到less10的"难"只是在第3步和第4步之间选了不同的路，less11到less22的"新"只是换了输入渠道，less23之后的"绕"只是给第5步加了料。框架其实始终没有变。
5.2 靶场之外，这些思路如何帮你做防御判断
刷完靶场之后再回看代码，你会发现以前看不懂的"为什么大家都说参数化查询"现在变得非常直观——因为注入发生的本质是"数据被当成了代码去解析"，参数化查询把数据和SQL结构彻底分开，无论输入什么字符，它都只是数据，不再有改变SQL语义的能力。除了预编译，另一个重要认知是把错误信息脱敏，不要让数据库的原始报错直接暴露给用户，否则等于给攻击者报点和反馈，less5到less7以及less17这类报错注入关卡能成立，完全依赖于报错可见。再一个是要对所有输入渠道一视同仁，Cookie、Header、表单、JSON体，任何一个位置都可能成为注入的入口，less18到less22就是最好的例子。
综合来看，SQLi-Labs less1到less32的价值，不在于让你"多会几种绕过姿势"，而在于建立一种可迁移的分析模型。你以后不管遇到什么系统、什么框架、什么过滤器，只要还能保持"输入从哪里来、拼到哪、什么闭合、怎么回显"这个追问习惯，就不会在攻防两端吃大亏。我自己刷完这一轮之后，再去看一些开源系统的代码，明显能更快地捕捉到可疑的字符串拼接点，也能更清楚地解释为什么某些修复方案有效、某些修复方案只是在自欺欺人。这大概就是这个靶场留给一个人最持久的东西。