Less-24二次注入实战：从注册到改密，一次搞懂SQL注入的隐藏玩法

1. 拿到Less-24先别急着跑这关考的是思路sqli-labs刷到Less-24很多新手会卡一下。前23关大部分是“参数拼进SQL导致报错、盲注、布尔、时间盲注”这种直来直去的路子到了这一关突然变了个玩法页面干干净净登录框摆在眼前用户名密码一提交就完事SQL注入好像消失了。其实这一关是经典的二次注入Second Order Injection考的不是“你能不能找到注入点”而是“你能不能把注入载荷先存进去再在另一个功能里把它引爆”。我在带人刷靶场的时候经常说一句话Less-24不是给你练手速的是给你练“数据流思维”的。后面很多真实站点的漏洞都长这样——你看到的输入点并不是最终执行SQL的地方。所以这关值得单独写一篇从攻击链路、源码分析、实操步骤到常见坑一次性讲清楚。这一关适合谁来刷如果你是SQL注入刚入门、已经刷到Less-10以后的选手这关是提升思路的关键节点。如果你做渗透测试想理解二次注入的原理这关也是最精简的复现环境。下面我会先把整个关卡的页面逻辑拆开再带你走一遍完整攻击流程最后把源码贴出来逐行解释让你知道攻击载荷到底是怎么一步步变成SQL语句的。2. 页面只有两个功能但攻击面藏在逻辑缝里2.1 登录页与新用户注册页的常规操作Less-24打开之后是登录界面上面有用户名、密码输入框还有个“忘记密码”的链接。翻到页面底部或者根据题目提示能发现还有一个新用户注册入口。注册页面需要的字段很简单用户名、密码有的版本还有确认密码和邮箱但核心攻击不依赖后两者。先做个最基础的动作注册一个普通的测试用户比如用户名叫“test123”密码“pass123”。注册完直接登录登录成功后你会被带到一个“修改密码”的页面里面有当前登录用户名、新密码、确认新密码三个字段。这里要注意修改密码的行为不是简单的UPDATE语句而是先把当前会话的用户名拼进SQL里这就成了二次注入的引爆点。2.2 真正埋雷的地方注册用户名的字符没有过滤这关最阴的地方在于注册用户名的时候后端代码几乎不过滤任何特殊字符。你输入单引号、双引号、减号、井号它都原样存进数据库。表面上注册成功了页面看起来一切正常但这个恶意用户名已经躺在数据表里等着“修改密码”功能把它捞出来拼SQL。我打个比方你就懂了注册功能只是“存钱”修改密码才是“取钱时验钞”。你存了一张假钞进去当时没人发现等银行柜台取钱的时候验钞机把假钞识别成真钱整笔账就乱了。二次注入的攻击逻辑就是这个恶意数据先入库在另一个功能点被当作可信数据直接使用中间没有任何参数化查询的缓冲。2.3 为什么说“修改密码”是二次注入的天然引爆点修改密码这个功能在多数Web程序里都有一个标准SQL写法UPDATE users SET password新密码 WHERE username当前用户名。如果开发直接把当前用户名用字符串拼接塞进SQL就会产生一个可利用的注入点。而当前用户名来自哪里就来自你登录时使用的用户名。一旦你在注册时把用户名写成注入载荷登录后修改密码就必然触发payload。从攻击者的视角看攻击路径非常清晰注册恶意用户名 → 登录该用户 → 进入修改密码页面 → 提交新密码 → 后端在WHERE条件中拼接恶意用户名 → SQL注入执行。这也是Less-24和前面所有关卡的本质区别前面是“输入即执行”这里是“存储后间接执行”所以必须完整走通整条业务链路才能触发。3. 攻击链路推演恶意用户名的三次“变形记”3.1 第一次变形用户名写成注入片段并被存入数据库我先演示一个最经典的payload。注册新用户时用户名这一栏填写admin#密码随便填比如“hack”。提交注册后insert语句大概是这样的INSERT INTO users (username, password) VALUES (admin#, hack)因为在MySQL里井号是注释符#后面的内容全部被注释掉所以这条语句实际执行的效果是把用户名的值写成了“admin’”密码字段无论你填了什么都不会进数据库注释符直接把后面的语法结构掐断了。等一下这里有个容易搞混的细节INSERT语句里注入是存数据不是查询所以核心目标是让库里的username字段值包含特殊的单引号和注释符。注册成功之后你去数据库看一眼那行数据里username的值就是“admin#”。这里有人会问单引号不是会把INSERT语句搞报错吗为什么还能注册成功这就是因为井号注释符把后面的闭合引号给注释掉了。你写入的值虽然怪异但SQL语法上没有报错数据就顺利入库了。很多新手在这一步会犹豫觉得“这能成功吗”实测下来就是能成功这也是为什么二次注入的载荷经常长得像脏数据。3.2 第二次变形登录时后端按原样取出用户名注册完恶意用户之后用“admin#”这个用户名和“hack”密码去登录。这里有个前提条件登录查询也是拼接SQL。正常情况下登录查询是SELECT * FROM users WHERE usernameadmin# AND passwordhack井号把后面的条件注释掉这条SQL实际上只校验了用户名密码直接被忽略了。更关键的是查询结果里username字段的值仍然是“admin#”这个值会被后端程序拿去干什么如果你登录成功多数实现会把username存进session然后跳到修改密码页面时再从session里取出来放进表单里。但注意我这套流程是演示标准环境下的行为。有的版本后端在登录后会把session里的username取出来用于修改密码SQL拼接有的版本则直接从数据库重新查一次。无论哪种最终进入修改密码SQL的值都带单引号和井号这才是关键的第二次变形。3.3 第三次变形修改密码SQL里的致命拼接登录成功后进入修改密码页面页面上的当前用户名显示着“admin#”。当前端提交新密码时后端会把新密码和当前用户名拼成一条UPDATE语句。攻击者的实际输入是当前用户名“admin#”新密码“123456”。拼接出来的SQL长这样UPDATE users SET password123456 WHERE usernameadmin#翻译成人话就是把用户名等于admin的那条记录的密码改成123456。井号注释掉了后面的单引号SQL语法完整浏览器和数据库都不报错。攻击完成admin用户的密码已经被你改成了123456你拿着它去登录真正的管理员账户就行。这一步是整个攻击的核心注入载荷成功入库又成功出库最后在UPDATE语句里改变语义。所以理解Less-24重点不是背payload而是理解同一条数据在不同SQL语句中“身份”的变化——它在INSERT里是值在UPDATE里却变成了语法结构的一部分。4. Less-24完整实操步骤从注册到提权一条龙4.1 准备环境sqli-labs本地靶场启动与数据库重置Less-24需要在本地搭建sqli-labs环境搭建方式不复杂但要确保数据库已初始化。我建议你在开始动手前先重置一下数据库免得上一个人留下的脏数据干扰你判断。重置方法访问sqli-labs的setup页面点击“Create Database”按钮重新建库或者手动执行项目里提供的sql文件。我用的是PHPMySQL经典环境Windows下用小皮面板或者直接装WAMP都行。刷靶场前记得打开数据库错误显示这样方便观察SQL执行状况。如果是Linux环境记得给项目目录写权限不然有些版本写入session文件会报错。环境准备好之后先建立对Less-24的基础认知它模拟的是一个“用户注册登录修改密码”的业务系统。这套业务逻辑在现实里太常见了很多老的CMS、论坛、教务系统都有这个结构所以Less-24的实战参考价值非常高。4.2 具体攻击步骤与关键参数选择详细步骤我直接列出来照着做就能打通第一步访问注册页面用户名填写admin#密码填写任意值例如“hack”。提交注册系统会提示注册成功。这里注意很多版本不需要邮箱字段如果有必填邮箱就随便填一个不影响攻击。第二步用你注册的用户名登录也就是输入admin#密码“hack”。登录成功后页面会跳到修改密码界面界面上会回显当前用户名。第三步在修改密码页面输入新密码比如“123456”确认密码也填“123456”提交。页面可能提示密码修改成功也可能无提示直接刷新。第四步退出当前登录回到登录界面。用用户名“admin”、密码“123456”登录。如果成功进入管理员界面说明二次注入攻击已经生效admin的密码被你篡改了。这里关键参数只有两个注册用户名必须是admin#新密码随意但你要记住。为什么用户名必须是admin呢因为你的目标是修改admin的密码。如果你想把张三的密码改了就把用户名写成zhangsan#SQL语义完全一致。4.3 登录验证时遇到“用户名不存在”怎么处理有一种情况比较常见注册admin#之后登录时却提示用户名不存在或密码错误。这是因为某些版本的登录逻辑里做了用户名trim或转义处理。遇到这种情况不要慌先回数据库确认用户是否真的插入成功。打开数据库看看users表里有没有一行username是“admin#”的记录。如果有说明注册阶段成功问题出在登录环节。登录查询拼接时如果后端代码在拼SQL前把单引号转义了比如用addslashes函数你的载荷就会失效。这种情况下就得另想办法比如看Less-24的源码确认登录是否可绕过。标准环境里这步是没问题的我建议你先把源码读完再动手。4.4 实战中值得注意的替换方案如果admin#因为某种原因不能生效你可以尝试另一个变体admin --用户名写成admin --注意--后面有个空格利用MySQL的减号注释符。效果和井号一样都是为了注释掉闭合单引号。MySQL要求--注释符后面至少跟一个空白字符所以很多payload写作admin--或者admin--加号在URL解码后会变成空格。这个变体在实战中也很好用建议你两个都试一遍。还有更进一步的玩法如果你不只是想改管理员密码而是想在UPDATE语句里追加字段可以尝试admin, emailattackertest.com#这条载荷会让UPDATE变成同时修改password和email两个字段。在真实环境中某些业务系统的敏感字段都可以用这种方式一并篡改。Less-24本身不涉及但理解了这个扩展思路你的二次注入水平就不仅仅是会抄payload了。5. 源码复盘Less-24的漏洞到底埋在哪几行5.1 注册功能的源码分析与过滤缺失点先看注册文件一般是login_create.php。核心SQL大致长这样$username $_POST[username]; $password $_POST[password]; $sql INSERT INTO users (username, password) VALUES ($username, $password); $result mysqli_query($conn, $sql);注意这个实现直接把POST参数原文拼进SQL没有做任何过滤、转义、参数化处理。你用admin#做用户名时SQL变成INSERT INTO users (username, password) VALUES (admin#, hack)。井号注释掉后面所有内容插入的值就是admin这几乎是教科书级的二次注入存储点。实际源码里可能还有对用户名长度的限制但admin#这7个字符完全在允许范围内所以不会触发长度限制。有些版本有用户名唯一性约束这就要注意如果表里已经有admin了你再插入admin#不会冲突因为两个字符串不相等。5.2 登录功能与session处理的关键逻辑登录文件一般是login.php。它的SQL大致是$sql SELECT * FROM users WHERE username$username AND password$password; $row mysqli_fetch_array($result); $_SESSION[username] $row[username];这里有个非常关键的细节登录成功后存入session的不是你输入的那个字符串而是从数据库查出来的username字段值。也就是说即使你输入的是admin#数据库里那行的username也是admin#session里存的就是这个值。后续修改密码功能从session里取用户名时取到的就是带注入载荷的完整字符串这是攻击能闭环的胜负手。登录SQL本身因为井号注释符也等于只校验了用户名不校验密码。这就是为什么攻击流程里你要用admin#这个用户名和任意密码都能登录成功。5.3 修改密码功能的致命代码核心漏洞文件一般是pass_change.php。源码关键部分如下$username $_SESSION[username]; $newpass $_POST[newpassword]; $sql UPDATE users SET password$newpass WHERE username$username;这就是二次注入的引爆点。session里的用户名在初登录时是可信的吗在开发者看来可能是可信的因为用户已经通过了登录校验。但实际上这个“可信”数据里藏了攻击载荷当它被拼进UPDATE语句时单引号改变了整个SQL语义。你以为开发只要过滤了输入框就安全了Less-24最生动的一课就是如果数据会在不同SQL上下文中被拼接那“入库前过滤”是不足以保证安全的。你必须在每个SQL执行点都使用参数化查询或者在写入数据库时就严格校验字段内容格式。5.4 从源码看二次注入的两个必要条件复盘源码之后你会发现二次注入要成立必须同时满足两个条件第一注入载荷被原样保存到数据库存储阶段不报错、不转义第二被保存的载荷在另一个SQL查询中被当作可信数据直接拼接执行。Less-24刚好同时满足了这两个条件。这两个条件在真实系统里也经常出现。比如用户注册时用户名允许带特殊字符评论区功能允许输入表情符号然后后台管理界面在搜索、排序、导出Excel时直接把含特殊字符的字段拼进SQL二次注入就出现了。很多安全测试工具只能扫描出“直接反射型”的注入点对二次注入往往无能为力就是因为工具看不见跨请求的数据流。6. 刷这关最常见的坑与排查技巧6.1 数据库里插进去的用户名带上了转义反斜杠这是Windows环境下最多人遇到的现象。明明注册填的是admin#去数据库看却变成了admin\#多了一个反斜杠。这是因为PHP的magic_quotes_gpc配置在旧版本里默认开启所有POST参数里的单引号、双引号、反斜杠都会被自动加转义符。这会让注入载荷失效。排查方法很简单先在项目里写个phpinfo页面查看magic_quotes_gpc状态如果是On就在php.ini里改成Off并重启服务。现在的PHP 7以上版本这个配置已经移除如果你用的是高版本PHP环境基本不会遇到这个问题。但如果你维护的老系统还跑在PHP 5.x上这坑就非常常见。6.2 用了admin#登录却跳不回修改密码页面还有一种情况注册成功但登录之后页面空白或者依然是登录页。这多半是登录逻辑里的SQL查询出了语法错误。你要想一下登录SQL在拼接之后是SELECT * FROM users WHERE usernameadmin# AND passwordhack在MySQL里井号注释符要求后面直接到行尾这条SQL是合法的。但有些数据库版本或者PHP框架的数据库驱动会执行“预处理”逻辑把井号后面的内容当作真实参数处理导致查询结果为空。如果你遇到这种情况换成admin--变体再试试往往就能解决。另外我建议你打开MySQL的通用日志看看实际执行的SQL语句长什么样。通用日志会记录所有到达MySQL服务器的语句这样你能直观看到注释符是否生效、拼接结果是否符合预期。Windows下修改my.ini开启general_logLinux下修改/etc/mysql/mysql.conf.d/mysqld.cnf这招排查SQL注入类问题特别好用。6.3 想改别人的密码但不知道对方用户名是什么Less-24的payload里写的是admin但实际上你可以改任何一个已知用户的密码。如果你只知道用户名不知道密码没关系二次注入的payload不需要你登录目标用户。你要做的是自己注册一个带载荷的账号登录自己的账号然后通过修改密码功能去改目标用户的密码。比如说你要改用户“test”的密码注册用户名就写test#新密码填“hacked”攻击完成后test用户的密码就变成“hacked”。这个思路在现实中可以直接用来横向移动知道管理员用户名但是登不进去就注册一个admin#账号改掉admin密码再登录。这个技巧背后反映出的实战经验是二次注入不需要你拥有目标身份只要系统里存在一个用户可控、且会被拼进SQL的字段就能利用。现实中类似的有“忘记密码”功能、用户资料更新、头像上传后文件名回显等功能都是二次注入的潜在地。6.4 数据库重置后第一次登上不去的玄学问题刷sqli-labs的时候我还遇到过一个很诡异的现象重置数据库之后第一次访问Less-24登录页面提交任何账号密码都提示错误再刷一次页面又正常了。后来排查发现是浏览器缓存了登录前的会话session没有正常清理。遇到这个问题清掉浏览器cookie或者换无痕窗口就解决了别花时间在源码里找毛病。另一个相关的小坑是如果你用admin#登录之后修改密码页面显示的当前用户名是admin#但你去数据库看那一行的username变成了admin井号消失了这是数据库客户端工具显示时把注释符处理掉的假象实际上库里的数据没变。直接通过命令行工具查询确认不要被图形化工具误导。7. 从Less-24延伸到防御方这个洞到底怎么修7.1 最简单粗暴的修复参数化查询如果这套代码是我负责维护的第一件事就是把所有用户输入的执行语句全部改成参数化查询。以PHP的mysqli为例$stmt $conn-prepare(UPDATE users SET password? WHERE username?); $stmt-bind_param(ss, $newpass, $username); $stmt-execute();改成参数化查询之后无论session里的username带多少单引号和井号它都只是一个普通字符串不会影响SQL语法结构。这是治本的办法apply以后Less-24的这套攻击直接失效。参数化查询的原理类似格式化打印SQL骨架先固定好参数单独传送给数据库引擎。数据库引擎在知道哪个位置是数据、哪个位置是SQL结构的前提下根本不会把参数里的内容解析成语法。这也是为什么业界一直强调“参数化查询能抵御绝大多数SQL注入”。7.2 纵深防御白名单校验也不能省我见过不少团队觉得“用了参数化查询就万事大吉”这不对。参数化能防SQL注入但防不了业务逻辑上的漏洞。比如用户名这种字段本质上应该有字符集限制。用户名就是用户名它没必要包含单引号、井号、减号更不应该包含SQL关键字。正确的做法是在注册阶段就做白名单校验if (preg_match(/^[a-zA-Z0-9_]{3,20}$/, $username)) { // 允许注册 } else { // 拒绝注册 }这样直接从源头上卡死了恶意载荷的入库路径比只靠执行层面的防御更可靠。我在现实中做安全加固时一向主张“写入时严格校验、执行时参数化绑定”双管齐下。7.3 安全测试的视角除了看输入点还要看数据流从防御角度看Less-24最大的收获是安全测试不能只盯着每个输入框测一遍注入就收工还要跟踪数据在系统里的流动路径。用户输入的数据会存到哪个表、又被哪个功能读取、读取之后会不会被拼进SQL或HTML、会不会被当作文件路径使用这一条完整链路才是安全评估的核心。现代Web应用越来越复杂微服务架构下数据在服务间流转二次注入的检测更加困难。你可以在注册功能、资料修改功能、搜索功能、导出功能等所有涉及数据读取和展示的模块里都检查是否有动态拼接SQL的行为。如果业务上无法避免拼接也要确保每个拼接点都做了参数化处理。8. 刷完Less-24之后的进阶路线Less-24的价值不在于让你背会一条admin#的payload而在于让你建立“数据流”的思维模型。刷完这一关我强烈建议你继续做三个事情第一把Less-24的注册、登录、修改密码三个源码文件逐行走读标注每一个SQL拼接点尝试自己去修漏洞第二在真实环境里找一个类似“修改密码”的功能用同样思路测试是否存在二次注入注意务必获得授权第三学习UpdateXML报错注入和布尔盲注在二次注入场景里的变形因为现实中并不是每个UPDATE语句都会在页面上回显执行结果。有一个值得尝试的扩展实验如果你在Less-24里用报错注入的方式会不会有输出比如注册用户名时直接写admin AND (SELECT 1 FROM (SELECT COUNT(*), CONCAT((SELECT database()), FLOOR(RAND(0)*2)) x FROM information_schema.tables GROUP BY x) a)#这需要数据库开启报错显示。原生环境里页面回显逻辑可能看不到数据库报错但你可以改一下源码让它打印mysqli_error这样就能直观看到报错注入的效果。这一步做完你对SQL注入的理解会整体上一个台阶。二次注入在真实漏洞库里从来不缺案例很多耳熟能详的CMS漏洞、OA系统漏洞都栽在这上面。sqli-labs用一座迷你靶场把这个漏洞最精简地复现出来你在这里踩过的坑和打通链路之后建立的直觉将来在真实渗透和代码审计里都能直接用上。还是那句话靶场刷关是为了长思路不是为了刷数字。Less-24你是真的学到了还是只是跟着文章跑了一遍流程区别就在于你能否独立讲清楚那些单引号和井号在每个步骤里到底扮演了什么角色。