★ FEATURED ARTICLE 1. 报错注入一张错误提示就把数据库信息抖了出来先聊一个安全测试圈里很经典的话题——SQL注入里的报错注入。如果你接触过Web安全大概率听过这个词。它是SQL注入家族里比较“另类”的一个分支核心思路是正常注入是拿着查询结果去页面里找数据回显而报错注入压根不需要数据回显它靠的是数据库自己“说漏嘴”——当SQL语句触发数据库层面的报错时错误信息会带上部分SQL语句内容而攻击者可以通过精心构造的语句把需要查询的数据塞进错误信息里一起打印出来。听起来很绕但你可以类比成这样一个场景你去柜台办事递给工作人员的纸条上写了句会让系统崩溃的话系统弹了一条详细错误提示把纸条上的部分内容原样显示在屏幕上。报错注入的本质就是想办法让数据库把“你想看的查询结果”当成“错误消息的参数”回显出来页面不需要有正常的数据输出位只要错误提示没被吞掉数据就能被带出来。这个技巧在实战中非常实用尤其是遇到页面没有查询结果回显、只能看到报错信息的场景。CTF题目里也经常考开发人员理解它也有价值——不知道攻击者是怎么利用报错的就很难写出真正安全的防御代码。这篇内容我会把这套东西从原理、常用函数、完整利用流程到踩坑记录展开讲一遍手里有靶场环境、或者想系统理解Web安全的朋友可以直接按步骤实操。2. 为什么数据库会“主动泄密”报错注入的底层机制2.1 报错回显是前提但不是所有报错都好使报错注入能否成立第一前提是目标应用把数据库的报错信息原样返回给了前端。很多生产环境会关闭display_errors或者在框架层面统一捕获异常并返回友好提示页这时候报错注入自然就没法用。但在一些老项目、内部系统、或者开发时开启了debug模式的环境里页面会直接输出SQL语句执行失败时的原始报错这就给报错注入创造了条件。第二个前提是数据库在执行特定函数或操作时会把参数内容拼接到错误信息里。以最常用的MySQL为例当UPDATEXML或EXTRACTVALUE这类函数被传入一个非法的XPath表达式时MySQL会抛出类似“XPATH syntax error: xxx”的错误而xxx就是传入的非法XPath字符串。如果我们把查询数据的语句用concat拼到这个位置数据库在报错的时候就会把查询结果一并输出。你可以构造一个updatexml函数传入~ 查询语句作为参数让它既是非法XPath又能执行子查询错误提示里就带着你要的数据了。2.2 一句话理解报错注入链路报错注入的完整链路可以拆成三环:可控输入点、SQL语句拼接、报错信息回显。站点把用户传入的参数值直接拼接到SQL语句中其中一部分进入了报错函数比如updatexml(1, concat(0x7e, 子查询), 1)子查询的结果会成为报错信息的一部分被数据库打印出来。攻击者需要控制的就是让“子查询”返回的目标数据出现在报错信息里。这里有个容易被忽略的细节报错信息通常有长度限制。MySQL里的updatexml和extractvalue报错信息最长约32个字符一旦查询结果过长就会截断。所以实际利用时要么用group_concat一次拼接多条但控制总数要么配合substr分段取出。很多人第一次用报错注入发现数据不完整十有八九是栽在这个长度限制上。这个限制不是缺陷反而在防御角度有参考价值给错误信息的输出加长度限制、统一脱敏是降低该风险的有效手段。理解了这层原理后面构造payload时自然会避开“一次拖出几百个字符”这种不切实际的操作。3. 报错注入的常用“武器库”几个主流函数逐个拆解3.1 updatexml最稳定的选择UPDATEXML(XML_document, XPath_expr, new_value)本来是MySQL里用来更新XML文档片段数据的函数第一个参数传XML文档第二个传XPath路径第三个传替换内容。它的报错注入特性在于第二个参数的XPath表达式如果格式非法数据库会抛出错误并把非法的表达式片段带入错误消息。经典payload长这样and updatexml(1, concat(0x7e, (select database())), 1)0x7e是波浪号“~”的十六进制表示放在查询结果前面是为了确保整个concat后的字符串不符合XPath格式从而触发报错。子查询select database()返回当前数据库名最终页面上就会出现类似XPATH syntax error: ~test_db的内容库名就泄出来了。我在实际测试里偏好用updatexml因为它可控性强报错稳定不像某些函数那样有概率问题。唯一要注意的就是报错长度截断需要分段读取。构造时也可以用concat(0x7e, (select group_concat(table_name) from information_schema.tables where table_schemadatabase()))但务必估算一下表名总长度别超过32字符一次拉全。3.2 extractvalue同门兄弟参数更简单EXTRACTVALUE(XML_document, XPath_expr)也是MySQL的XML函数作用是提取XML文档中指定路径的节点值。它的报错机制和updatexml几乎一致只是函数设计上少了一个参数整体payload更简洁and extractvalue(1, concat(0x7e, (select user())))这条语句执行后返回的错误信息会带上~当前用户名。updatexml和extractvalue的核心区别在于参数个数和应用场景实际利用时可以用来判断目标数据库到底用的是哪个函数有些场景下WAF或过滤规则只拦了updatexml没拦extractvalue换个函数名就能绕过。这也是我们常说“武器库要备齐全”的原因。3.3 floor(rand(0)*2) group by经典的主键冲突报错这个方案不走XML函数而是利用MySQL在group by和count(*)执行时出现主键重复冲突导致的报错。经典payload如下and (select 1 from (select count(*), concat((select database()), floor(rand(0)*2)) x from information_schema.tables group by x) a)原理有点绕但理解后就不觉得玄了。rand(0)是一个伪随机序列乘以2后取整floor结果只会是0或1。当MySQL执行group by时会尝试把分组的值作为临时表主键插入而rand(0)*2的值在特定次数后会重复触发主键冲突报错报错信息里就带上了concat((select database()), floor(rand(0)*2))的结果。实际测试中这个方案算是“老牌经典”很多教材里都会讲。但我要泼一盆冷水这个方案在实际测试中稳定性较差。它的报错结果依赖伪随机序列的具体计算过程偶发情况下不一定会崩不同MySQL版本行为也有差异。更重要的一点它返回的内容不是完整的查询结果而是被截断后的一部分数据量一多就抓瞎。如果非要用建议只用来获取版本、数据库名这类短数据别指望一次拖出一整张表。3.4 其他报错方式速览exp、geometrycollection这些杂牌军exp()利用exp(~((select * from(select user())x)))之类的写法让该函数参数超过范围后抛出溢出错误。不过新版本中exp报错受限较大实际效果一般。ST_LatFromGeoHash()、GTID相关函数这些是MySQL 5.7等版本才有的更多选择但触发条件更苛刻。NAME_CONST()早期版本可用现在已经基本废弃了。我个人的建议是把updatexml和extractvalue吃透就够应对绝大多数情况了其他函数花时间研究更多是为了在某些过滤环境下换思路绕障碍日常成功率远不如前两者。3.5 不同函数的可控性与风险对比函数名报错信息长度稳定性适用版本备注updatexml约32字符高MySQL 5.1最常用推荐优先使用extractvalue约32字符高MySQL 5.1与updatexml机制类似floorgroup by依赖具体数据中低老版本效果更好有概率不报错exp溢出较短低旧版本新版本已基本失效注意版本差异导致的函数行为不同很常见。实际测试时如果updatexml没有报错可以先看一眼目标数据库版本再决定是否换其他函数不要死磕一种。4. 报错注入完整实操流程从判断注入点到把数据拖出来4.1 第一步确认注入点并判断位置比如目标URL是http://example.com/article.php?id1先用最简单的单引号测试看页面状态变化id1如果页面出现SQL语法错误或者返回行为明显异常基本可以判定存在注入点。接着加一个报错函数看看它能不能生效id1 and updatexml(1, concat(0x7e, (select version())), 1) -- 页面的报错信息里出现了~8.0.13之类的版本信息就说明这个位置可以用报错注入带入查询语句。注意这里的闭合方式如果原始SQL是select * from article where id 1payload里的单引号必须匹配正确后面的-- 负责注释掉余下内容。如果目标是数字型也可以不闭合直接id1 and updatexml(...)。判断字符型还是数字型最直观的方法是看加不加引号对报错结果的影响。有些站点把参数做了整数校验根本进不了SQL拼接环节那就谈不上注入了。还有一些位置在order by、limit、group by等特殊子句里思考方式也略有差异核心规则不变让你可控的部分进入报错函数并能执行子查询即可。4.2 第二步确定查询列数和目标表确认注入点后下一步要弄清楚目标SQL语句查询了多少列常用order by探测id1 order by 5 -- 如果正常返回、到了第6个字段才报错就说明原查询有5列。这一步的意义更多在于了解目标语句结构报错注入本身不依赖列数——你可以直接利用子查询去information_schema里拿数据与列数无关。不同于联合查询报错注入不用你自己构造select的列对齐。当前数据库名称可以直接用id1 and updatexml(1, concat(0x7e, (select database())), 1) -- 结果中会显示“~库名”。如果要看所有数据库用id1 and updatexml(1, concat(0x7e, (select group_concat(schema_name) from information_schema.schemata)), 1) -- 一条数据还好说数据量一大就要控制长度了这也是为什么后面会说分段读取。4.3 第三步爆表名、字段名和数据拿到当前数据库名后查表名就顺理成章了id1 and updatexml(1, concat(0x7e, (select group_concat(table_name) from information_schema.tables where table_schema目标库名)), 1) -- 如果表名很多建议limit分批看比如一次看前10个and updatexml(1, concat(0x7e, (select group_concat(table_name) from information_schema.tables where table_schema目标库名 limit 0,10)), 1)table_schema后面为什么是字符串引号包着因为库名在SQL里本身就是字符串字面量需要引号。如果引号被过滤了可以改成hex编码比如table_schema0x6D796462MySQL会把它当成字符串比较。这一招在遇到引号被拦截时非常实用。表名到手后下一步查目标表的列名and updatexml(1, concat(0x7e, (select group_concat(column_name) from information_schema.columns where table_schema目标库名 and table_name目标表名)), 1)最后一步就是拖数据。假设拿到了用户表的username和password两列and updatexml(1, concat(0x7e, (select concat(username,0x3a,password) from users limit 0,1)), 1)0x3a是冒号的十六进制用来分隔两个字段避免数据混在一起看不清。一次只取一行多行就调整limit偏移量。报错信息截断的话再用substr拆分and updatexml(1, concat(0x7e, substr((select concat(username,0x3a,password) from users limit 0,1),1,30)), 1)上面这段用substr从第一个字符开始取30位再配合offset逐段取完。有人习惯用mid/substring都一样只要能控制截取范围。4.4 一个标准的测试流程速查表阶段目标常用payload核心探测注入点判断是否存在注入单引号、and 11/12确认报错通道判断updatexml是否可用updatexml(1,concat(0x7e,version()),1)获取库名知道当前数据库select database()获取表名知道目标数据在哪information_schema.tables获取列名知道目标字段information_schema.columns获取数据拖出目标值concat字段limitsubstr这个流程可以套用到大多数MySQL报错注入场景。只要前面的通道构建好后面每一步就是换子查询的问题不存在技术门槛。4.5 实操中的细节URL编码、注释符与引号实战中payload直接放URL里会出问题比如单引号可能被浏览器特殊处理空格可能被截断。一般需要URL编码id1%27%20and%20updatexml(1,concat(0x7e,(select%20database())),1)--%20%27%27对应单引号%20对应空格。如果你用的是Burp Suite这类抓包工具直接在原始请求里改也行工具会自动处理。注释符用--会比--更常见因为加号在URL里会被解析成空格而--后面必须有空格才能正确注释--在部分解析环境下更稳定。也有人用#注释但URL里#有特殊含义需要编码成%23。引号被过滤时可以用16进制代替字符串例如table_schema0x6d797462过滤了空格还可以用注释符/**/代替空格分隔关键字。很多WAF和过滤逻辑只是简单替换这种写法有时能钻空子。5. 报错注入常见问题排查与绕过记录5.1 页面就是不报错是注入点的问题还是函数的问题先别急着换payload按顺序排查第一页面是否把数据库错误信息完整展示出来了有的框架会把SQL错误记录到日志但页面只返回500第二注入点是否真的拼接进了SQL尤其参数是JSON或POST类型时单引号测试未必能触发SQL执行第三数据库版本是否过老或过新updatexml等函数在很老的MySQL 4.x上不存在。排查时可以先用最简单的and 11和and 12看页面内容差异如果页面没变化很可能参数根本没进SQL或者根本就不是SQL注入而是其他漏洞类型。这类问题我用过不少时间踩坑最后发现是目标站把id做了二次过滤参数值只能包含数字。这种情况先确认“有没有注入”比“用什么函数”更重要。5.2 报错结果被截断或只显示半个字段原因是前面说过的报错信息约32字符限制。解决办法就是用substr分段取。例如concat(0x7e, substr((select group_concat(table_name) from information_schema.tables where table_schemadatabase()),1,31))取完前31位再改偏移位置取下一段concat(0x7e, substr((select group_concat(table_name) from information_schema.tables where table_schemadatabase()),32,31))这样一段一段拼起来就能还原完整数据。5.3 关键字或函数被过滤常见的过滤玩法有关键字替换和正则过滤。绕过方式没有万能药但有几条思路可以参考大小写混合绕过Select、UpDaTeXml内联注释包裹关键字/*!50000updatexml*/等价函数替换把updatexml换成extractvalue字符串函数变形substr换substringconcat换concat_ws十六进制替代字符串常量和符号这些只是思路不是包过。实际环境的过滤规则五花八门有时候得多试几种组合。某次我遇到过把“updatexml”和“extractvalue”都过滤了的情况最后用floorgroup by的老方案绕过去的虽然不稳定但在那个场景里是唯一可行的办法。5.4 报错注入的防御与自查建议防御层面的核心原则很明确用户输入永远不能拼接到SQL语句中。具体做三件事。第一使用参数化查询或预编译语句这是最本质的解法。无论用户输入是什么SQL语句的结构已经固定不能改变执行逻辑。第二如果因为历史原因必须拼接SQL至少对输入做严格白名单校验比如id字段只能匹配数字字符串字段只能匹配特定字符集和长度而不是黑名单过滤。第三页面不要向用户输出SQL原始报错。生产环境里应该统一错误页把数据库异常记录到日志避免攻击者从报错里收集数据库类型、版本、表结构等信息。我自己在防御角度还有一个心得做安全巡检时优先查全站有多少接口开启了debug和异常堆栈输出这类接口通常是报错注入的重灾区。报错注入的利用门槛低不需要额外搭建数据接收通道一条报错就是一条数据,这也是它这么多年依然活跃的原因。6. 关于报错注入我的几点个人体会最后说几句我自己实操中的感受。报错注入看起来花样多核心其实就是一件事找到数据库会把SQL执行结果带回显的位置。不管是用updatexml还是extractvalue本质都是把查询结果放进一个会被错误消息打印的参数里。理解了这条链路你就不会被某个具体函数绑住遇到过滤也能灵活换思路。新手学这块最容易犯的毛病是直接把payload拿去打生产系统这是非常糟糕的习惯。要练习就用本地靶场或授权环境搭建一个简单的PHPMySQL环境把报错显示开关打开自己构造几个payload跑一遍很快就能建立起直觉。安全测试的前提永远是授权脱离授权谈攻击手段只会给自己惹麻烦。如果你在测试时发现updatexml报了“Illegal mix of collations”这类和字符集相关的错误先别慌这是排序规则冲突给concat的参数加上hex()或者统一转换字符集就能解决。这种小坑文档里很少写但真遇到了能卡很久。报错注入是个老话题但老话题不代表过时它在实际攻防里依然有生存空间。把这个技术吃透能帮你更深刻地理解SQL注入的底层逻辑——为什么拼接危险、为什么参数化安全、为什么报错信息也不能随便漏这些想通了整个Web安全的认知都会上一个台阶。
阅读完成 · 觉得有帮助？
