sqli-labs是我见过最适合练SQL注入手感的靶场没有之一。它不像某些综合漏洞环境那样追求大而全而是把每一种注入类型拆成一课一课的关卡从最简单的GET单引号注入一路做到二次注入、宽字节、堆叠难度曲线非常平滑。这篇内容我重点讲第11到45关覆盖了POST注入、HTTP头部注入、关键字过滤绕过、宽字节和堆叠注入这几个核心模块也是整个靶场里最能锻炼思路的一段路程。适合两类人看一类是刚过完前十关、准备往进阶走的初学者另一类是已经接触过一些真实渗透项目、想回来把基础打扎实的开发或测试人员。看完你会发现后面这些关卡教的不只是某个姿势而是当你面前只剩一条句子的其余部分时怎么把它变成一条能用的注入语句。1. 从GET到POST的思维切换Lessons 11-17核心思路1.1 为什么POST注入要先看参数传递前10关全都是GET型注入很多初学者形成了条件反射看到URL里有?id1就想往后面拼参数。到了第11关页面换成了一个登录表单URL干干净净第一反应应该是打开Burp抓包看请求体。因为POST参数在请求体里SQL语句拼装的入口变成了表单字段不再是地址栏。这个思维切换是11到17关里最重要的一步如果还习惯性地在URL后面加参数可能折腾半天都找不到注入点。在真实项目里我也遇到过不少类似情况很多业务系统的查询接口都是用POST提交表单数据开发图省事直接在后台把参数拼进了SQL语句。所以在靶场里练POST注入练的就是你看请求体时能像看URL一样敏感哪个字段看起来是和数据库交互的就往哪里试闭合符。拿到一个登录框、一个搜索框、一个查询接口第一件事别急着输账号密码先问自己这个字段进没进SQL。1.2 手动闭合思路与Union注入流程以第11关为例第11关的注入点在登录框的username字段。我先输入一个正常的账号密码比如admin/123登录失败这反而说明逻辑走到了数据库查询那一步。然后在username处输入admin -- -密码随便填就能绕过登录。这里有个细节要注意POST参数里加号会被解析成空格所以注释符不能写成--那种用在URL里的形式POST里更稳的是-- -也就是两个减号加一个空格再加一个减号确保MySQL能正确识别注释。我见过不少人在POST里照搬GET的payload结果一直报语法错误其实差别就在和空格的编码处理上。拿到闭合方式之后下一步确定查询列数。用order by N逐级试order by 3报错order by 2正常说明原查询只有两列。接着用union select 1,2构造联合查询把id位置换成一个不存在的值比如-1这样前面的查询结果为空union后面的数据就能回显出来。页面上用户名位置出现数字2密码位置出现数字1两个回显点就确定了剩下的就是常规的查库名、查表名、查字段、拖数据流程。第12关把闭合符从单引号换成了双引号其他套路完全一样。我在练习时的习惯是每一关先问自己两个问题输入的哪个参数被拼进了SQL它是用什么符号闭合的这两个问题搞清楚后面的payload基本就水到渠成了。1.3 双查询报错注入为何能成为无回显时的破局点13到17关第13、14关换了玩法页面不再回显查询结果但是会把SQL报错信息打印出来。这种场景下联合查询没用了得用报错注入。靶场里用的是双查询注入原理上更准确地说是当count(*)和group by产生冲突时MySQL会把子查询的报错信息一并输出到页面上。我用的payload是admin AND extractvalue(1,concat(0x7e,(select user()),0x7e)) -- -或者用updatexmladmin AND updatexml(1,concat(0x7e,(select database()),0x7e),1) -- -这两个函数都是报错注入的常用函数。0x7e是波浪号~的十六进制编码加上它主要是为了在报错结果里做一个可见的分隔符方便从一堆报错文本里快速定位我们想要的数据。报错注入的本质是让MySQL在执行查询时触发报错并且在报错信息中携带我们要的数据。所以注入点要能被MySQL当成一个合法的表达式去执行这就要求要么把整段payload拼在原始SQL语句的前半段并用注释符吞掉后面要么利用函数让报错信息中带上子查询结果。很多新手在这两关翻车是因为忘记了注释符留下了多余的单引号导致SQL一直报语法错误而不是出现目标报错。第15、16关又变成了盲注页面既不回显也不报错只能用布尔真假来判断。第15关是单引号闭合payload比较模板化admin AND (SELECT substr(database(),1,1))s -- -用二分法逐字符猜测库名。第16关是双引号加括号的闭合我第一次测的时候在闭合上卡了很久后面形成了一套通用方法先输入一个单引号如果报错就说明闭合结构不同再试双引号再试双引号加括号逐个试总会碰到对的。第17关比较特殊它是一个密码重置功能的注入。注入点不在查询条件里而是在更新的SET子句里也就是改密码的时候password字段直接拼进了UPDATE语句。这种情况下要用的是基于更新的报错注入admin AND updatexml(1,concat(0x7e,(select group_concat(table_name) from information_schema.tables where table_schemadatabase()),0x7e),1) -- -第17关整体上比前面都要难一档因为它是UPDATE语句的注入很多人习惯了SELECT语句的注入遇到UPDATE就不知道怎么拼了。核心思路是找到需要闭合的地方用注释符把后面不需要的SQL吃掉再让报错函数在SET子句中执行。第17关还有个细节username字段用了转义函数单引号会被转义但password字段没有防护所以切入点非常明确直接找没防护的字段下手。这个思想在真实渗透中特别重要系统防护往往是不均匀的总有某个点被开发者遗漏。2. 隐蔽战场HTTP头部注入的三种姿势Lessons 18-222.1 User-Agent与Referer注入的利用点第18关开始进入HTTP头注入的领域。页面会记录访客的User-Agent后台很可能直接把UA字符串拼进了INSERT语句或者UPDATE语句。这种注入点在真实项目中其实挺常见很多统计系统、日志系统会把请求头原样记到数据库里如果这些信息没有过滤就存在注入风险。第18关的解法很直接在Burp里把UA改成 AND extractvalue(1,concat(0x7e,(select version()),0x7e)) -- -要注意的是改完UA后请求还要能正常走到SQL查询所以POST表单的其余字段需要保留Content-Type也不能乱改。如果报错信息里带出了MySQL版本号说明UA确实拼进了SQL且闭合符是单引号。第19关换成了Referer字段注入思路完全一样只是把输入点从UA头换到了Referer头。这类头注入的坑在于改完头之后页面有时候会提示你的IP已经被记录很多人会以为功能没走数据库其实后台的功能就是记录访问者信息到数据库所以你输入的头部信息就是被拼进SQL的那一半。换句话说越是有日志记录功能的页面越可能在你看不到的地方藏着注入点。2.2 Cookie注入与Base64编码绕过的组合应用20到22关第20关把注入点挪到了Cookie。用Burp抓包把Cookie里的uname参数改成unameadmin AND extractvalue(1,concat(0x7e,(select table_name from information_schema.tables where table_schemadatabase() limit 0,1),0x7e)) -- -;这里有个容易混淆的点Cookie中的特殊字符和HTTP头一样需要注意编码和格式。单引号直接放上去通常没问题但有些中间件会处理特殊字符所以建议在Burp的Repeater里观察原始请求不要用浏览器控制台去改Cookie否则很容易被编码问题干扰明明payload是对的就是不出结果。第21、22关是Cookie注入的进阶后台会把Cookie值先做Base64解码再拼进SQL。所以我们的payload要先Base64编码一次再放进Cookie。起初我直接把第20关的payload编码后用结果试了很久都失败后来才意识到第21关后台自带Base64解码我需要把整个Cookie值替换成编码后的内容而不只是替换其中一小段。反复看源码才找到问题所在。第22关又是闭合符的小变化把单引号换成了双引号payload结构不变先编码再放Cookie就过了。这三关连起来传达了一个核心观点真实场景里数据在进入SQL之前往往还要经过一层解码逻辑比如URL解码、Base64解码、JSON解析。绕过这些逻辑之后再找注入点比直接蛮猜要高效得多。3. 过滤规则下的花式绕过Lessons 23-28是正则对抗的必修课3.1 注释符被过滤之后的闭合与收尾技巧第23关模拟的是开发者把--和#都过滤掉的情况。注释符没了注入语句后面多余的SQL就无法直接吞掉了这种情况下需要想办法让整条语句在语法上过得去。最常用的思路是用闭合符凑成合法语句。比如得知原查询是SELECT * FROM users WHERE id$id LIMIT 0,1输入?id1 AND 11拼出来就是SELECT * FROM users WHERE id1 AND 11 LIMIT 0,1单引号成对闭合后面的LIMIT自然成为合法语法不需要注释符。这个手法在真实渗透中也经常用它要求你在获得闭合方式之后自己补一个恒真表达式把引号闭合相当于让SQL自己闭合自己。第23关另一个考法是union select怎么写。既然注释符被过滤就要把union select后面的部分填在剩下的闭合适配里。payload类似id1 UNION SELECT 1,2,3 AND 11拼出来SELECT * FROM users WHERE id1 UNION SELECT 1,2,3 AND 11 LIMIT 0,1MySQL对AND优先级的处理虽然可能让union查询的列数和类型不合但在很多版本中依然能返回结果。建议遇到这关时多试几种闭合组合找到能正常回显的那条这也是很多做安全的朋友说的闭合的艺术。3.2 空格被过滤时的替代方案注释符与编码字符的实际用法第26关把空格、注释符都过滤了。没有空格的SQL语句很难直接读解决办法其实有好几种。最常见的思路是用/**/替代空格比如?id1/**/union/**/select/**/1,2,3/**/--但第26关把/*、#一起过滤了所以更实用的替代方案是用TAB。在URL编码里TAB是%09payload可以写成?id1%09union%09select%091,2,3%09--很多初学者在Burp里直接敲键盘上的TAB是没效果的必须用编码后的%09。另外MySQL还允许用换行符%0a和回车符%0d当间隔但不同数据库行为有差异在靶场里实测下来用%09最稳。第26关还会把括号给滤掉所以函数名后面不能直接跟括号如果确实需要函数就要用变量赋值之类的替代方案。我第一次做这关的时候用的是联合查询直接绕过发现不需要函数所以空格替代和闭合处理就够了。这关真正练的是过滤规则变了你的payload的每一部分都要跟着变不能一套打天下。3.3 Union与Select关键字过滤的组合拳25、27、28关第25关过滤的是OR和AND这个过滤是大小写不敏感的但绕过方式并不难用||代替OR用代替AND。MySQL支持这种符号形式的逻辑运算符所以?id1 || 11 -- -这种payload就能绕过去。写payload时注意URL里符号是参数分隔符想用必须编码成%26%26否则会被解析成新参数。第27关过滤的是Union和Select关键字但过滤的时候没有做递归过滤只是把它们替换成空字符串。所以最简单的绕法是写成UNunionION或者SELselectECT替换掉中间的union或select之后剩下的正好是UNION和SELECT。这种递归不彻底的过滤在真实代码里太常见了很多过滤器只做了一次替换忽略了对替换结果的二次检查。第28关把空格和union、select一起过滤了解法就是内联注释加大小写混淆的组合?id1/*!50000union*/%09/*!50000select*/%091,2,3%09--MySQL特有的版本号注释/*!50000union*/在MySQL中会被当成union执行但在很多正则匹配的眼里它只是一个注释不会触发规则。这是MySQL指纹识别和绕过规则中非常经典的一招靶场里练的是思路到了真实场景还能再配合编码手段组合使用。3.4 服务端架构差异带来的参数污染29到31关第29到31关模拟的是WAF部署场景后端有两层服务器第一层是带过滤逻辑的WAF设备第二层才是真正处理请求的应用服务器。HTTP参数污染HPP就是利用两层服务器对同名参数的处理差异来绕过防护。举个例子构造?id1idunion select...第一层服务器可能只取第一个参数1直接放行第二层服务器可能会把两个参数拼接或者取第二个参数于是攻击语句就绕过了WAF进入了SQL查询。不同中间件对同名参数的解析差异非常大有的取第一个有的取最后一个有的拼接成一个数组后由后端代码决定。这个环节在本地跑的时候会遇到环境问题很多人发现页面行为跟资料描述不一致。我当时的处理是仔细读靶场源码看它到底是从哪个参数取数据然后手动构造重复参数观察哪一层生效。这种思路不依赖具体靶场版本实战里反而是理解WAF绕过最有价值的部分。第30、31关换汤不换药只是把参数位置换了一下核心都是同名参数的覆盖顺序问题。4. 编码层面的攻防博弈宽字节注入与二次注入Lessons 24, 32-374.1 宽字节注入是怎么产生的GBK编码与转义函数的冲突第32关到37关是宽字节注入也叫GBK双字节注入。出现这个漏洞的环境一般会把MySQL连接的字符集设置成GBK同时对输入用了addslashes或类似函数来转义单引号。addslashes会在单引号前面加上反斜杠变成\。问题的关键在编码本身GBK是双字节编码一个汉字占两个字节而且GBK的第二个字节范围是0x40到0xFE反斜杠0x5C恰好落在这个范围内。如果我输入一个高位字节比如%df它和反斜杠%5c拼在一起会被MySQL当作一个合法的GBK汉字来解释于是反斜杠就消失了单引号也就逃逸出来了。这就是宽字节注入的根本原因。用一句话总结转义函数只防住了ASCII没防住多字节编码的边界特性。这就像门锁只防君子遇到用双字节拆锁的就直接洞开。搞懂了这一点后面所有关卡的payload都只是应用方式的变化。4.2 GET与POST场景下的宽字节注入利用32到37关第32关是GET型宽字节payload就是?id-1%df union select 1,2,3--。这里的%df经过addslashes后物理上变成了%df%5c而MySQL用GBK解码时%df%5c拼成一个汉字单引号孤零零地露出来就变成了正常的字符串闭合符。实测时用这个形式就能回显。第33关把转义函数换成了mysql_real_escape_string这个函数功能更强但同样绕不过宽字节因为问题出在字符集上而不是转义函数本身。第34、35关把场景搬到了POSTpayload形式一样只不过要放在POST参数里比如username-1%df union select 1,2,3--。在POST里如果直接放原始字节%df有些表单会自动把它当成普通字符所以还是建议用Burp来发请求确保编码不被二次转换。第36关和第37关把转义函数换成了另一个版本利用思路不变依旧用%df去吞掉反斜杠。这两关连在一起实际上是在告诉你转义函数只是表象字符集才是根因。只要底层连接是GBK换多少个转义函数都挡不住宽字节注入。二次注入在第24关。它的核心不是绕过滤而是把一个坏数据先存入数据库等下次某个查询再把它取出来拼进SQL时触发攻击。比如注册一个用户名为admin -- -的账号注册时addslashes把单引号转义了不能直接注入但数据存进MySQL时下一次后台把这个用户名拼进某个SQL语句执行时数据库会把反斜杠当转义符单引号变成有效语法注入就实现了。这类漏洞在真实业务里出现在用户改密码、改昵称后管理员后台查看的流程中非常隐蔽。做第24关最需要注意的是注册时输入的内容要考虑到后续SQL的上下文而不是随便一个union select就能用。我当时的做法是注册用户名admin -- -然后修改密码修改密码的SQL大概是UPDATE users SET password... WHERE usernameadmin -- -注释符把后面的内容全部吃掉影响到的记录就是admin用户相当于把admin的密码改成了我们自己设置的密码。这个场景在真实业务里可以演变成任意用户密码重置危害很大。5. 高权限玩家的新大陆堆叠注入完全拆解Lessons 38-455.1 堆叠注入与联合注入的本质区别第38关开始进入堆叠注入的模块。联合注入是把一次SELECT的结果合并到现有查询里它要求前后两个SELECT的列数一致。而堆叠注入是用分号把两条SQL语句分隔开让数据库依次执行比如?id1; SELECT 1,2,3 --分号后面的SQL是全新的一条语句不要求列数与原查询一致。如果数据库连接驱动支持多语句执行堆叠注入就能执行更新、删除、插入甚至调用存储过程。真实场景里MySQL的PHP驱动和mysqli默认就支持这是堆叠注入能存在的基础。但这并不代表堆叠注入比联合注入更万能很多情况下它的回显是不完整的第二句SQL如果没有嵌入到页面渲染中结果你是看不到的通常只能配合报错、盲注或者直接写文件来确认结果。所以碰到堆叠场景一定不要只会堆SELECT要思考目标是什么要拿数据就继续报错要删数据就update/delete要写文件就用into outfile。5.2 报错型堆叠与盲注型堆叠的处理方式39到45关第39、40、41关都是GET堆叠区别在于闭合符和是否报错回显。第39关是单引号报错型堆叠payload写成?id1;update users set passwordhack where usernameadmin --就能直接修改数据。第40关是单引号加括号第41关是双引号加括号本质一样。第42到45关都是POST堆叠注入点在登录的username字段。payload直接写usernameadmin;update users set password123456 where usernameadmin-- -但不一定能立即看到回显需要靠后续登录来验证用新密码123456去登录如果成功了说明堆叠的update执行了。这个利用业务逻辑验证注入效果的思路很值得学很多注入场景下数据库本身不直接给你返回结果你得靠外层功能的反馈来推断。第43、45关分别在闭合符上做了变化有的用单引号有的用双引号加括号有的配上报错函数。我在练习时踩过一个坑报错注入和堆叠注入在同一请求里往往是互斥的。如果同时用了updatexml和堆叠分号报错会打断后面SQL的执行后面的update根本没执行到。所以选一种方式就好别想着既要报错又要堆叠这关教训很深刻。堆叠模块这几关最值得练的是对执行顺序和回显方式的判断力。请求发出去之后你无从知道语句有没有成功只能通过登录状态、页面差异、时间延迟来反推。这种经验在真实渗透项目里比分发payload拿回显要重要得多。6. 环境配置与常见问题排查实录6.1 靶场环境的搭建与常见报错第一次跑sqli-labs的时候最大的坑其实是环境问题。我用的是某套常见的PHP集成环境除了版本选择还要把PHP的display_errors打开否则报错注入的页面根本看不到报错信息盲注只能靠时间判断体验会差很多。数据库连接配置上有几个重点MySQL的账号密码要和靶场的db.php保持一致字符集最好设置成GBK这样才能复现宽字节注入的场景。有些朋友本地跑的时候发现第32关宽字节不好使大概率就是连接字符集不对直接改配置或者SQL语句里set names gbk就能解决。另外要注意的是PHP版本太新也可能有问题某些版本去掉了旧的mysql扩展靶场自带的写法在新版本会有兼容性问题建议用较老但稳定的环境组合。这套搭配虽然老但跟靶场最贴合实际上也说明这套靶场活了这么多年依然在安全圈里被当作业练习来用确实有它的价值。6.2 找不准注入点时的通用排查方法我在练习和带朋友玩的时候总结了一套找注入点的通用流程。第一步把所有可输入的参数列出来包括GET参数、POST字段、Cookie、HTTP头第二步逐个用一对单引号去测观察页面是否有SQL报错或者行为异常第三步有报错就用报错函数带出数据和确认列数没报错就继续试布尔盲注和时间盲注第四步把闭合方式搞清楚看是单引号、双引号、还是括号组合第五步根据回显方式选择联合、报错、盲注或堆叠。这套流程对付sqli-labs第11到45关完全够用对付真实项目的常规注入点也基本够用。工具方面Burp Suite是必装的SQLMap也可以用来验证结论但我建议至少在前几遍手注的时候坚持纯手工因为自动化工具只会告诉你这里有注入不会告诉你这里为什么能注入。亲手把每一步的SQL拼回去思考这个积累是工具替代不了的。还有个小建议做每一关之前先猜一下后台SQL长什么样然后写下来再验证。比如第11关猜SELECT username,password FROM users WHERE username输入内容 AND password...第17关猜UPDATE users SET password... WHERE username输入内容。猜对了再复杂的过滤你也知道该往哪里绕。这套先建模型再验证的做法是我玩这套靶场最大的收获。常见问题速查表现象可能原因排查方向报错注入无报错回显PHP display_errors未开启检查php.ini配置宽字节注入无效连接字符集不是GBK检查数据库连接配置POST注入注释符不生效使用了URL里的--形式改为-- -或#Cookie注入被编码干扰浏览器或工具二次编码用Burp Repeater发原始请求堆叠注入语句不执行报错函数打断了执行避免同时使用报错和堆叠如果让我说玩完11到45关之后最深的体会那就是SQL注入从来不是一个payload走天下它考验的是对SQL上下文的理解和对数据库特性的熟悉程度。sqli-labs把每一种可能的情况都拆成了单独的关卡你在里面多花的时间到了真实项目里都会变成排查问题时的那种直觉。最后再分享一个小技巧我复盘的时候会把每一关的闭合方式、过滤规则、注入方法、回显方式整理成一个表后面遇到真实项目里的注入点直接拿表对照特征定位思路快得多。这个习惯坚持下来你也会发现注入的世界其实就那几件事找入口、测闭合、拼语句、拿回显只是变换组合而已。
sqli-labs是我见过最适合练SQL注入手感的靶场没有之一。它不像某些综合漏洞环境那样追求大而全而是把每一种注入类型拆成一课一课的关卡从最简单的GET单引号注入一路做到二次注入、宽字节、堆叠难度曲线非常平滑。这篇内容我重点讲第11到45关覆盖了POST注入、HTTP头部注入、关键字过滤绕过、宽字节和堆叠注入这几个核心模块也是整个靶场里最能锻炼思路的一段路程。适合两类人看一类是刚过完前十关、准备往进阶走的初学者另一类是已经接触过一些真实渗透项目、想回来把基础打扎实的开发或测试人员。看完你会发现后面这些关卡教的不只是某个姿势而是当你面前只剩一条句子的其余部分时怎么把它变成一条能用的注入语句。1. 从GET到POST的思维切换Lessons 11-17核心思路1.1 为什么POST注入要先看参数传递前10关全都是GET型注入很多初学者形成了条件反射看到URL里有?id1就想往后面拼参数。到了第11关页面换成了一个登录表单URL干干净净第一反应应该是打开Burp抓包看请求体。因为POST参数在请求体里SQL语句拼装的入口变成了表单字段不再是地址栏。这个思维切换是11到17关里最重要的一步如果还习惯性地在URL后面加参数可能折腾半天都找不到注入点。在真实项目里我也遇到过不少类似情况很多业务系统的查询接口都是用POST提交表单数据开发图省事直接在后台把参数拼进了SQL语句。所以在靶场里练POST注入练的就是你看请求体时能像看URL一样敏感哪个字段看起来是和数据库交互的就往哪里试闭合符。拿到一个登录框、一个搜索框、一个查询接口第一件事别急着输账号密码先问自己这个字段进没进SQL。1.2 手动闭合思路与Union注入流程以第11关为例第11关的注入点在登录框的username字段。我先输入一个正常的账号密码比如admin/123登录失败这反而说明逻辑走到了数据库查询那一步。然后在username处输入admin -- -密码随便填就能绕过登录。这里有个细节要注意POST参数里加号会被解析成空格所以注释符不能写成--那种用在URL里的形式POST里更稳的是-- -也就是两个减号加一个空格再加一个减号确保MySQL能正确识别注释。我见过不少人在POST里照搬GET的payload结果一直报语法错误其实差别就在和空格的编码处理上。拿到闭合方式之后下一步确定查询列数。用order by N逐级试order by 3报错order by 2正常说明原查询只有两列。接着用union select 1,2构造联合查询把id位置换成一个不存在的值比如-1这样前面的查询结果为空union后面的数据就能回显出来。页面上用户名位置出现数字2密码位置出现数字1两个回显点就确定了剩下的就是常规的查库名、查表名、查字段、拖数据流程。第12关把闭合符从单引号换成了双引号其他套路完全一样。我在练习时的习惯是每一关先问自己两个问题输入的哪个参数被拼进了SQL它是用什么符号闭合的这两个问题搞清楚后面的payload基本就水到渠成了。1.3 双查询报错注入为何能成为无回显时的破局点13到17关第13、14关换了玩法页面不再回显查询结果但是会把SQL报错信息打印出来。这种场景下联合查询没用了得用报错注入。靶场里用的是双查询注入原理上更准确地说是当count(*)和group by产生冲突时MySQL会把子查询的报错信息一并输出到页面上。我用的payload是admin AND extractvalue(1,concat(0x7e,(select user()),0x7e)) -- -或者用updatexmladmin AND updatexml(1,concat(0x7e,(select database()),0x7e),1) -- -这两个函数都是报错注入的常用函数。0x7e是波浪号~的十六进制编码加上它主要是为了在报错结果里做一个可见的分隔符方便从一堆报错文本里快速定位我们想要的数据。报错注入的本质是让MySQL在执行查询时触发报错并且在报错信息中携带我们要的数据。所以注入点要能被MySQL当成一个合法的表达式去执行这就要求要么把整段payload拼在原始SQL语句的前半段并用注释符吞掉后面要么利用函数让报错信息中带上子查询结果。很多新手在这两关翻车是因为忘记了注释符留下了多余的单引号导致SQL一直报语法错误而不是出现目标报错。第15、16关又变成了盲注页面既不回显也不报错只能用布尔真假来判断。第15关是单引号闭合payload比较模板化admin AND (SELECT substr(database(),1,1))s -- -用二分法逐字符猜测库名。第16关是双引号加括号的闭合我第一次测的时候在闭合上卡了很久后面形成了一套通用方法先输入一个单引号如果报错就说明闭合结构不同再试双引号再试双引号加括号逐个试总会碰到对的。第17关比较特殊它是一个密码重置功能的注入。注入点不在查询条件里而是在更新的SET子句里也就是改密码的时候password字段直接拼进了UPDATE语句。这种情况下要用的是基于更新的报错注入admin AND updatexml(1,concat(0x7e,(select group_concat(table_name) from information_schema.tables where table_schemadatabase()),0x7e),1) -- -第17关整体上比前面都要难一档因为它是UPDATE语句的注入很多人习惯了SELECT语句的注入遇到UPDATE就不知道怎么拼了。核心思路是找到需要闭合的地方用注释符把后面不需要的SQL吃掉再让报错函数在SET子句中执行。第17关还有个细节username字段用了转义函数单引号会被转义但password字段没有防护所以切入点非常明确直接找没防护的字段下手。这个思想在真实渗透中特别重要系统防护往往是不均匀的总有某个点被开发者遗漏。2. 隐蔽战场HTTP头部注入的三种姿势Lessons 18-222.1 User-Agent与Referer注入的利用点第18关开始进入HTTP头注入的领域。页面会记录访客的User-Agent后台很可能直接把UA字符串拼进了INSERT语句或者UPDATE语句。这种注入点在真实项目中其实挺常见很多统计系统、日志系统会把请求头原样记到数据库里如果这些信息没有过滤就存在注入风险。第18关的解法很直接在Burp里把UA改成 AND extractvalue(1,concat(0x7e,(select version()),0x7e)) -- -要注意的是改完UA后请求还要能正常走到SQL查询所以POST表单的其余字段需要保留Content-Type也不能乱改。如果报错信息里带出了MySQL版本号说明UA确实拼进了SQL且闭合符是单引号。第19关换成了Referer字段注入思路完全一样只是把输入点从UA头换到了Referer头。这类头注入的坑在于改完头之后页面有时候会提示你的IP已经被记录很多人会以为功能没走数据库其实后台的功能就是记录访问者信息到数据库所以你输入的头部信息就是被拼进SQL的那一半。换句话说越是有日志记录功能的页面越可能在你看不到的地方藏着注入点。2.2 Cookie注入与Base64编码绕过的组合应用20到22关第20关把注入点挪到了Cookie。用Burp抓包把Cookie里的uname参数改成unameadmin AND extractvalue(1,concat(0x7e,(select table_name from information_schema.tables where table_schemadatabase() limit 0,1),0x7e)) -- -;这里有个容易混淆的点Cookie中的特殊字符和HTTP头一样需要注意编码和格式。单引号直接放上去通常没问题但有些中间件会处理特殊字符所以建议在Burp的Repeater里观察原始请求不要用浏览器控制台去改Cookie否则很容易被编码问题干扰明明payload是对的就是不出结果。第21、22关是Cookie注入的进阶后台会把Cookie值先做Base64解码再拼进SQL。所以我们的payload要先Base64编码一次再放进Cookie。起初我直接把第20关的payload编码后用结果试了很久都失败后来才意识到第21关后台自带Base64解码我需要把整个Cookie值替换成编码后的内容而不只是替换其中一小段。反复看源码才找到问题所在。第22关又是闭合符的小变化把单引号换成了双引号payload结构不变先编码再放Cookie就过了。这三关连起来传达了一个核心观点真实场景里数据在进入SQL之前往往还要经过一层解码逻辑比如URL解码、Base64解码、JSON解析。绕过这些逻辑之后再找注入点比直接蛮猜要高效得多。3. 过滤规则下的花式绕过Lessons 23-28是正则对抗的必修课3.1 注释符被过滤之后的闭合与收尾技巧第23关模拟的是开发者把--和#都过滤掉的情况。注释符没了注入语句后面多余的SQL就无法直接吞掉了这种情况下需要想办法让整条语句在语法上过得去。最常用的思路是用闭合符凑成合法语句。比如得知原查询是SELECT * FROM users WHERE id$id LIMIT 0,1输入?id1 AND 11拼出来就是SELECT * FROM users WHERE id1 AND 11 LIMIT 0,1单引号成对闭合后面的LIMIT自然成为合法语法不需要注释符。这个手法在真实渗透中也经常用它要求你在获得闭合方式之后自己补一个恒真表达式把引号闭合相当于让SQL自己闭合自己。第23关另一个考法是union select怎么写。既然注释符被过滤就要把union select后面的部分填在剩下的闭合适配里。payload类似id1 UNION SELECT 1,2,3 AND 11拼出来SELECT * FROM users WHERE id1 UNION SELECT 1,2,3 AND 11 LIMIT 0,1MySQL对AND优先级的处理虽然可能让union查询的列数和类型不合但在很多版本中依然能返回结果。建议遇到这关时多试几种闭合组合找到能正常回显的那条这也是很多做安全的朋友说的闭合的艺术。3.2 空格被过滤时的替代方案注释符与编码字符的实际用法第26关把空格、注释符都过滤了。没有空格的SQL语句很难直接读解决办法其实有好几种。最常见的思路是用/**/替代空格比如?id1/**/union/**/select/**/1,2,3/**/--但第26关把/*、#一起过滤了所以更实用的替代方案是用TAB。在URL编码里TAB是%09payload可以写成?id1%09union%09select%091,2,3%09--很多初学者在Burp里直接敲键盘上的TAB是没效果的必须用编码后的%09。另外MySQL还允许用换行符%0a和回车符%0d当间隔但不同数据库行为有差异在靶场里实测下来用%09最稳。第26关还会把括号给滤掉所以函数名后面不能直接跟括号如果确实需要函数就要用变量赋值之类的替代方案。我第一次做这关的时候用的是联合查询直接绕过发现不需要函数所以空格替代和闭合处理就够了。这关真正练的是过滤规则变了你的payload的每一部分都要跟着变不能一套打天下。3.3 Union与Select关键字过滤的组合拳25、27、28关第25关过滤的是OR和AND这个过滤是大小写不敏感的但绕过方式并不难用||代替OR用代替AND。MySQL支持这种符号形式的逻辑运算符所以?id1 || 11 -- -这种payload就能绕过去。写payload时注意URL里符号是参数分隔符想用必须编码成%26%26否则会被解析成新参数。第27关过滤的是Union和Select关键字但过滤的时候没有做递归过滤只是把它们替换成空字符串。所以最简单的绕法是写成UNunionION或者SELselectECT替换掉中间的union或select之后剩下的正好是UNION和SELECT。这种递归不彻底的过滤在真实代码里太常见了很多过滤器只做了一次替换忽略了对替换结果的二次检查。第28关把空格和union、select一起过滤了解法就是内联注释加大小写混淆的组合?id1/*!50000union*/%09/*!50000select*/%091,2,3%09--MySQL特有的版本号注释/*!50000union*/在MySQL中会被当成union执行但在很多正则匹配的眼里它只是一个注释不会触发规则。这是MySQL指纹识别和绕过规则中非常经典的一招靶场里练的是思路到了真实场景还能再配合编码手段组合使用。3.4 服务端架构差异带来的参数污染29到31关第29到31关模拟的是WAF部署场景后端有两层服务器第一层是带过滤逻辑的WAF设备第二层才是真正处理请求的应用服务器。HTTP参数污染HPP就是利用两层服务器对同名参数的处理差异来绕过防护。举个例子构造?id1idunion select...第一层服务器可能只取第一个参数1直接放行第二层服务器可能会把两个参数拼接或者取第二个参数于是攻击语句就绕过了WAF进入了SQL查询。不同中间件对同名参数的解析差异非常大有的取第一个有的取最后一个有的拼接成一个数组后由后端代码决定。这个环节在本地跑的时候会遇到环境问题很多人发现页面行为跟资料描述不一致。我当时的处理是仔细读靶场源码看它到底是从哪个参数取数据然后手动构造重复参数观察哪一层生效。这种思路不依赖具体靶场版本实战里反而是理解WAF绕过最有价值的部分。第30、31关换汤不换药只是把参数位置换了一下核心都是同名参数的覆盖顺序问题。4. 编码层面的攻防博弈宽字节注入与二次注入Lessons 24, 32-374.1 宽字节注入是怎么产生的GBK编码与转义函数的冲突第32关到37关是宽字节注入也叫GBK双字节注入。出现这个漏洞的环境一般会把MySQL连接的字符集设置成GBK同时对输入用了addslashes或类似函数来转义单引号。addslashes会在单引号前面加上反斜杠变成\。问题的关键在编码本身GBK是双字节编码一个汉字占两个字节而且GBK的第二个字节范围是0x40到0xFE反斜杠0x5C恰好落在这个范围内。如果我输入一个高位字节比如%df它和反斜杠%5c拼在一起会被MySQL当作一个合法的GBK汉字来解释于是反斜杠就消失了单引号也就逃逸出来了。这就是宽字节注入的根本原因。用一句话总结转义函数只防住了ASCII没防住多字节编码的边界特性。这就像门锁只防君子遇到用双字节拆锁的就直接洞开。搞懂了这一点后面所有关卡的payload都只是应用方式的变化。4.2 GET与POST场景下的宽字节注入利用32到37关第32关是GET型宽字节payload就是?id-1%df union select 1,2,3--。这里的%df经过addslashes后物理上变成了%df%5c而MySQL用GBK解码时%df%5c拼成一个汉字单引号孤零零地露出来就变成了正常的字符串闭合符。实测时用这个形式就能回显。第33关把转义函数换成了mysql_real_escape_string这个函数功能更强但同样绕不过宽字节因为问题出在字符集上而不是转义函数本身。第34、35关把场景搬到了POSTpayload形式一样只不过要放在POST参数里比如username-1%df union select 1,2,3--。在POST里如果直接放原始字节%df有些表单会自动把它当成普通字符所以还是建议用Burp来发请求确保编码不被二次转换。第36关和第37关把转义函数换成了另一个版本利用思路不变依旧用%df去吞掉反斜杠。这两关连在一起实际上是在告诉你转义函数只是表象字符集才是根因。只要底层连接是GBK换多少个转义函数都挡不住宽字节注入。二次注入在第24关。它的核心不是绕过滤而是把一个坏数据先存入数据库等下次某个查询再把它取出来拼进SQL时触发攻击。比如注册一个用户名为admin -- -的账号注册时addslashes把单引号转义了不能直接注入但数据存进MySQL时下一次后台把这个用户名拼进某个SQL语句执行时数据库会把反斜杠当转义符单引号变成有效语法注入就实现了。这类漏洞在真实业务里出现在用户改密码、改昵称后管理员后台查看的流程中非常隐蔽。做第24关最需要注意的是注册时输入的内容要考虑到后续SQL的上下文而不是随便一个union select就能用。我当时的做法是注册用户名admin -- -然后修改密码修改密码的SQL大概是UPDATE users SET password... WHERE usernameadmin -- -注释符把后面的内容全部吃掉影响到的记录就是admin用户相当于把admin的密码改成了我们自己设置的密码。这个场景在真实业务里可以演变成任意用户密码重置危害很大。5. 高权限玩家的新大陆堆叠注入完全拆解Lessons 38-455.1 堆叠注入与联合注入的本质区别第38关开始进入堆叠注入的模块。联合注入是把一次SELECT的结果合并到现有查询里它要求前后两个SELECT的列数一致。而堆叠注入是用分号把两条SQL语句分隔开让数据库依次执行比如?id1; SELECT 1,2,3 --分号后面的SQL是全新的一条语句不要求列数与原查询一致。如果数据库连接驱动支持多语句执行堆叠注入就能执行更新、删除、插入甚至调用存储过程。真实场景里MySQL的PHP驱动和mysqli默认就支持这是堆叠注入能存在的基础。但这并不代表堆叠注入比联合注入更万能很多情况下它的回显是不完整的第二句SQL如果没有嵌入到页面渲染中结果你是看不到的通常只能配合报错、盲注或者直接写文件来确认结果。所以碰到堆叠场景一定不要只会堆SELECT要思考目标是什么要拿数据就继续报错要删数据就update/delete要写文件就用into outfile。5.2 报错型堆叠与盲注型堆叠的处理方式39到45关第39、40、41关都是GET堆叠区别在于闭合符和是否报错回显。第39关是单引号报错型堆叠payload写成?id1;update users set passwordhack where usernameadmin --就能直接修改数据。第40关是单引号加括号第41关是双引号加括号本质一样。第42到45关都是POST堆叠注入点在登录的username字段。payload直接写usernameadmin;update users set password123456 where usernameadmin-- -但不一定能立即看到回显需要靠后续登录来验证用新密码123456去登录如果成功了说明堆叠的update执行了。这个利用业务逻辑验证注入效果的思路很值得学很多注入场景下数据库本身不直接给你返回结果你得靠外层功能的反馈来推断。第43、45关分别在闭合符上做了变化有的用单引号有的用双引号加括号有的配上报错函数。我在练习时踩过一个坑报错注入和堆叠注入在同一请求里往往是互斥的。如果同时用了updatexml和堆叠分号报错会打断后面SQL的执行后面的update根本没执行到。所以选一种方式就好别想着既要报错又要堆叠这关教训很深刻。堆叠模块这几关最值得练的是对执行顺序和回显方式的判断力。请求发出去之后你无从知道语句有没有成功只能通过登录状态、页面差异、时间延迟来反推。这种经验在真实渗透项目里比分发payload拿回显要重要得多。6. 环境配置与常见问题排查实录6.1 靶场环境的搭建与常见报错第一次跑sqli-labs的时候最大的坑其实是环境问题。我用的是某套常见的PHP集成环境除了版本选择还要把PHP的display_errors打开否则报错注入的页面根本看不到报错信息盲注只能靠时间判断体验会差很多。数据库连接配置上有几个重点MySQL的账号密码要和靶场的db.php保持一致字符集最好设置成GBK这样才能复现宽字节注入的场景。有些朋友本地跑的时候发现第32关宽字节不好使大概率就是连接字符集不对直接改配置或者SQL语句里set names gbk就能解决。另外要注意的是PHP版本太新也可能有问题某些版本去掉了旧的mysql扩展靶场自带的写法在新版本会有兼容性问题建议用较老但稳定的环境组合。这套搭配虽然老但跟靶场最贴合实际上也说明这套靶场活了这么多年依然在安全圈里被当作业练习来用确实有它的价值。6.2 找不准注入点时的通用排查方法我在练习和带朋友玩的时候总结了一套找注入点的通用流程。第一步把所有可输入的参数列出来包括GET参数、POST字段、Cookie、HTTP头第二步逐个用一对单引号去测观察页面是否有SQL报错或者行为异常第三步有报错就用报错函数带出数据和确认列数没报错就继续试布尔盲注和时间盲注第四步把闭合方式搞清楚看是单引号、双引号、还是括号组合第五步根据回显方式选择联合、报错、盲注或堆叠。这套流程对付sqli-labs第11到45关完全够用对付真实项目的常规注入点也基本够用。工具方面Burp Suite是必装的SQLMap也可以用来验证结论但我建议至少在前几遍手注的时候坚持纯手工因为自动化工具只会告诉你这里有注入不会告诉你这里为什么能注入。亲手把每一步的SQL拼回去思考这个积累是工具替代不了的。还有个小建议做每一关之前先猜一下后台SQL长什么样然后写下来再验证。比如第11关猜SELECT username,password FROM users WHERE username输入内容 AND password...第17关猜UPDATE users SET password... WHERE username输入内容。猜对了再复杂的过滤你也知道该往哪里绕。这套先建模型再验证的做法是我玩这套靶场最大的收获。常见问题速查表现象可能原因排查方向报错注入无报错回显PHP display_errors未开启检查php.ini配置宽字节注入无效连接字符集不是GBK检查数据库连接配置POST注入注释符不生效使用了URL里的--形式改为-- -或#Cookie注入被编码干扰浏览器或工具二次编码用Burp Repeater发原始请求堆叠注入语句不执行报错函数打断了执行避免同时使用报错和堆叠如果让我说玩完11到45关之后最深的体会那就是SQL注入从来不是一个payload走天下它考验的是对SQL上下文的理解和对数据库特性的熟悉程度。sqli-labs把每一种可能的情况都拆成了单独的关卡你在里面多花的时间到了真实项目里都会变成排查问题时的那种直觉。最后再分享一个小技巧我复盘的时候会把每一关的闭合方式、过滤规则、注入方法、回显方式整理成一个表后面遇到真实项目里的注入点直接拿表对照特征定位思路快得多。这个习惯坚持下来你也会发现注入的世界其实就那几件事找入口、测闭合、拼语句、拿回显只是变换组合而已。
平方复杂度无法被常规优化消除｜TaoToken 统一 Key 通道实测)
