1. 为什么现在还要聊SQL注入SQL注入这三个字放在2024年的技术社区里可能很多人会觉得是老古董。都什么年代了ORM框架一封装、预编译一加持怎么还会有拼接字符串的SQL写法但热搜词里那句“现在还存在SQL注入漏洞吗”恰恰说明这个问题远没有过时。我这两年做过几次蓝队值守也帮朋友企业做过代码审计说实话SQL注入依然是OWASP Top 10里的常客。那些跑在老旧系统上的报表模块、Excel导入工具、搜索框的分词逻辑有些代码甚至是十多年前写的里面到处是字符串拼接出来的SQL语句。另外很多新手学注入的时候有个误区以为学这个就是为了“黑站”。其实不是理解SQL注入的本质是理解**“代码与数据边界”**的最好启蒙课。这篇内容不搞那种纯抄文档、上来就给你一堆payload的写法。我想从一个入门的视角把万能密码绕过的原理、靶场选型、经典注入手法、常见的过滤绕过思路包括像SQL Server 2008这种老库的差异点全部串起来讲一遍。适合刚接触Web安全、准备刷靶场的新手也适合那些已经会跑sqlmap但从不自己拼一遍payload的同学——后者尤其建议好好看看第4和第5节。2. 注入的本质你写的查询语句是人话数据库听的也是“人话”2.1 一个搜索框是怎么被撬开的很多人看注入payload就像看天书比如 or 11 --这种。其实拆开来看特别简单。假设后台有一句用户登录的查询SELECT * FROM users WHERE username $username AND password $password你在用户名框输入admin or 11 --拼进SQL之后整句变成SELECT * FROM users WHERE username admin or 11 -- AND password 任意内容注意最后的--在MySQL、SQL Server里都是注释符它把后面原本的密码判断条件全部“吞掉”了。而or 11这个条件永远为真于是整条查询就等价于SELECT * FROM users WHERE username admin or TRUE这就是所有注入里最“原始”也最核心的一个逻辑你给程序输入了它没预期到的内容改变了SQL语句的结构。要理解这一步得先建立一个概念SQL语句里同时存在代码关键字、表名、字段名和数据你输入的字符串。正常情况下用户的输入应该只被当成“数据”看待。可一旦字符串拼接进查询语句用户输入里的引号一旦闭合了原本的字符串边界输入就从“数据”越权变成了“代码”。2.2 为什么预编译能挡掉这一招参数化查询PreparedStatement最本质的改变是告诉数据库“这个问号代表它是一个值不是语句的一部分。”PreparedStatement ps conn.prepareStatement( SELECT * FROM users WHERE username ? AND password ? ); ps.setString(1, username); ps.setString(2, password);你输入的admin or 11 --传进去之后数据库对这个参数的解读是“一个字符串”字符串里的单引号、or关键字全部是文本不会被当作SQL执行。这就是边界被划清楚了。不过预编译不是银弹。存储过程里的动态SQL拼接、ORDER BY字段的动态排序因为ORDER BY后面不能绑定参数、LIKE模糊查询的百分号转义问题这些位置仍然是注入高发区。所以别觉得项目里用了MyBatis的#{}就百分百安全遇到${}的地方审计时一个都不能放过。2.3 注入的类型地图在正式动手之前先把地图铺开知道自己站在哪分类维度类型典型特征回显方式联合查询注入Union Based页面直接显示查询结果适合union拼接回显方式报错注入Error Based数据库错误信息直接回显在页面回显方式盲注Boolean / Time Based页面不显示数据只能通过真/假或延迟判断数据读取方向有回显注入结果直接显示数据读取方向无回显注入结果不显示需要逐字猜解注入位置GET注入 / POST注入 / Cookie注入 / HTTP头注入参数位置的区别数据库类型MySQL / SQL Server / Oracle / PostgreSQL语法细节不同payload写法不同新手入门时最容易产生困惑的就是“联合查询、报错、盲注”这三者到底怎么选。其实选择标准很简单先看页面有没有把SQL查询结果直接打印出来。有优先试联合查询没有但报错信息很详细可以试试报错注入什么都不显示就得靠盲注。3. 万能密码还要聊吗必须聊它是理解Quote闭合的钥匙3.1 从DVWA的Low级别看注入流程DVWADamn Vulnerable Web Application是入门Web安全绕不开的靶场。在DVWA里把安全级别调到LowSQL Injection模块的源码长这样$query SELECT first_name, last_name FROM users WHERE user_id $id;; $result mysqli_query($GLOBALS[DB], $query) or die(mysqli_error($GLOBALS[DB]));注意用户传进来的$id被直接拼进了SQL字符串而且外层套在单引号里。此时如果你在ID输入框填1 and 11拼出来就是SELECT first_name, last_name FROM users WHERE user_id 1 and 11这是布尔逻辑里“永远成立”的表达式和万能密码一个道理。从这个例子能看出入门阶段最要紧的不是背payload而是搞清楚输入的单引号是怎么和代码里的单引号“配对”的。3.2 引号闭合的三种基本姿势假设原始SQL是WHERE id $id这种单引号包裹的情况你输入的内容相当于在“填格子”。要闭合这个结构常见有三条路单引号闭合 恒真表达式输入 or 11 --单引号先把原SQL中的左引号闭合再用or构造恒真条件注释掉后面的尾巴。单引号闭合 UNION查询输入 union select username,password from users --前提是要知道原查询返回了多少列。整形字段不用引号当SQL写成WHERE id $id连引号都没包直接输入1 or 11就能改变逻辑。这就是为什么有些文章会说“整型注入比字符型注入更简单”。3.3 自己动手在SQLilab上完成第一次完整注入sqlilab平台是专门给SQL注入练习做的靶场它的关卡设计从易到难比DVWA更有“升级打怪”的感觉。以**第一关单引号字符型注入**为例完整流程应该是这样第一步确认注入点。在参数后面加一个单引号http://your-sqlilab/Less-1/?id1页面报错数据库提示You have an error in your SQL syntax这直接暴露了后端是MySQL而且单引号造成了语法问题。第二步判断列数。用order by逐个试http://your-sqlilab/Less-1/?id1 order by 3 -- -注意sqlilab里的注释符我习惯用-- -两个短横线加一个空格这是MySQL兼容性最好的写法。当order by 4报错、order by 3正常时就能确定当前查询一共是3列。第三步联合查询。把id变成不存在的负数让前面的查询结果为空然后让union的查询结果直接显示http://your-sqlilab/Less-1/?id-1 union select 1,2,3 -- -页面把2和3显示出来很多版本显示在页面上两个位置说明这两个字段刚好是回显位。第四步爆数据库名和表名http://your-sqlilab/Less-1/?id-1 union select 1,database(),version() -- -到这里你已经完成了一次标准的联合查询注入。这个过程看起来简单但里面每一步都对应一个“信息论”上的判断报错验证了是否存在注入order by验证了查询列数union验证了回显位。后面所有复杂的注入手法本质上都是这套流程的变形。3.4 写在靶场实战前的一个提醒学注入最怕一件事只在一个靶场里练到滚瓜烂熟。DVWA的低级别、sqlilab的前几关、Pikachu的SQL注入模块都差不多是“明文传输、无过滤”的环境练多了容易产生一种“注入不过如此”的错觉。真正的挑战是一旦后端加了全局过滤函数、一旦参数经过URL编码、一旦WAF开始拦截关键字同样的逻辑就得换着花样重新表达。这就是第5节要讲的绕过思路。4. 靶场这么多到底该刷哪一个现在市面上常见的SQL注入靶场至少有这么几个DVWA、Pikachu、sqlilab、CTFHub技能树、sqli-labs的魔改版。很多新手在群里问“哪个靶场好”其实答案不是选一个而是按阶段依次打通。4.1 DVWA适合建立的“手感”基地DVWA最大的价值是把安全级别分成Low、Medium、High、Impossible四个档位让你直观看到同一句代码在不同防护强度下的表现。刷DVWA的正确姿势不是把Low级别的注入点搞完就撤而是把这四个档位全部过一遍。Medium档加了mysqli_real_escape_string对特殊字符的转义High档改用了参数化查询Impossible档则直接把代码改成“你根本找不到拼接点”。这个渐进的对比本身就是一份很好的“防护体系认知教材”。4.2 sqlilab关数多覆盖面广练的就是量sqlilab的环境搭建比DVWA稍微麻烦一点但完全值得。它的关卡设计非常系统前几关是字符型、数字型的基本注入中间有GET/POST双传参、双注入报错注入、盲注、时间盲注后段还有堆叠注入、宽字节注入、和文件读写相关的注入。这里有个经验sqlilab不要一关一关死磕到底。我见过不少新手卡在第28关的“过滤了单引号和括号”那里一卡就是两三天。正确做法是往前刷15关把基本手法练熟遇到卡关超过30分钟就直接看通关文档把思路抄下来再用自己的话复现一遍。后面回过头来你会发现自己对注入的理解提升了好几个层次。4.3 Pikachu靶场中文语境源码审计两不误Pikachu是国人开发的一个漏洞练习平台它的SQL注入模块不仅包含了字符型、搜索型、XX型等不同注入点还有一个特别好的设计每个漏洞页面都附了源码而且平台本身是用PHP搭的直接就能看到SQL是怎么拼的。对应热搜词里的“pikachu靶场通关sql注入”我的建议是不要只做“通过”而是把每一关的源码和请求过程对应起来看。比如“搜索型注入”那一关SQL是WHERE name like %$name%你先在搜索框输入a% or 11 --思考一下百分号带来的闭合差异。关上源码、自己画一遍拼装过程再打开源码验证。这种训练三十个请求就能做完但比盲目刷五十个payload有用得多。4.4 CTFHub技能树适合查漏补缺CTFHub的技能树里SQL注入那部分关卡是“为比赛设计的”。它的题目偏脑筋急转弯比如整数型注入、字符型注入、报错注入、布尔盲注、时间盲注一关一关过了之后你会对每种情况都留下印象。它的好处是题目短平快、反馈直接适合在通勤路上刷一两道保持手感。不过CTFHub的关卡大多跳过了“手工猜解”的过程有些题甚至一步到位。所以我更建议把CTFHub当字典用不当主教材用。刷完某类题回到sqlilab里找对应关卡再做一遍手工注入你才知道赛题里那些“取巧”的payload背后是怎么一步步推出来的。5. 绕过思路深度拆解过滤了就不是注入了吗热搜词里“sql注入绕过”排在很靠前的位置说明大家卡在过滤规则的比较多。这里先把一个核心观念立起来绕过的本质是“表达方式的等价替换”。后端过滤了什么你就要找到一种不被过滤的写法来完成同样的逻辑。5.1 宽字节注入数据库的编码歧义这个手法主要针对GBK编码的MySQL后端。假如后端做了这么一件事把你输入的单引号前面加上反斜杠变成\在MySQL默认字符集是GBK时如果攻击者输入%bf%27反斜杠\的ASCII码是0x5c%bf%27中的%bf和%5c组合在一起会被解析成一个合法的GBK字符后面的单引号就“逃”出来了。原理是单字节转义被宽字节吃掉了。对应Pikachu里的宽字节注入关卡输入的关键就是URL编码后的%bf%27。现在新版的MySQL和PDO场景里这种手法可能失效因为字符集设置变了但很多老代码里依然能打。理解它的关键在于过滤不是绝对的它依赖数据库、应用层和前端三方的字符集设置。5.2 等价替换从一个函数换个函数开始如果后端过滤了sleep()函数时间盲注就得找替代品。MySQL里能引起延迟的函数至少还有这些BENCHMARK(10000000, SHA1(test))重复计算一个表达式制造延迟SLEEP(5)最经典的延迟函数GET_LOCK(test, 5)在一个连接里加锁等待如果过滤了union网站如果是MySQL还可以尝试union all虽然有时候all也会被拦。过滤了空格那就用/**/代替或者用括号把表达式括起来比如(select(1))。过滤了逗号UNION的列数可以不写逗号吗不行但LIMIT 1 OFFSET 0这种写法里可以用offset绕过逗号的限制。每一种绕过的背后都对应一个“SQL语法手册”级别的理解。5.3 大小写与双写对付“傻瓜式过滤”有些后端的过滤函数写得特别粗糙比如直接用str_replace(select, , $input)过滤之后把“select”删掉。这时候双写seselectlect过滤完剩下的正好是select。再比如只匹配小写的网站你直接写SELECT就绕过去了。这类绕过在真实场景里越来越少因为主流WAF的规则集已经很完善但在靶场和CTF里依然是基本功。我要特别说明一下绕WAF和绕代码过滤是两码事。代码过滤是写在业务层面的逻辑绕的是程序员WAF过滤是流量层面的正则/语义检测绕的是规则。新手阶段先把代码过滤玩明白再去碰WAF绕过否则容易陷入“payload猜谜”的泥潭里。5.4 一个典型的“绕过组合拳”实战假设某个靶场关卡过滤了空格、union、select任务还是查当前数据库名。我们可以组合出这样的payload?id-1/**/un/**/ion/**/sel/**/ect/**/1,database(),3-- -这个payload里/**/代替空格un/**/ion的写法把关键字拆开有些过滤是匹配完整单词的注释符一插入就断了匹配。但注意这种拆字写法在MySQL里不一定每次都有效因为注释符的作用是把后面的内容忽略掉MySQL 5.x的解析器对un/**/ion有特殊容错处理在部分版本是能执行的在另一些版本不行。所以实操时要实时观察页面的反馈。真正的绕过高阶思路不是背一串绕过payload而是理解解析器的容错机制。比如MySQL对/*!50000union*/这种内联注释的支持版本号大于50000时执行理解这个规则后你就可以自己造出各种绕过姿势。这也是为什么我强调刷靶场时多看看数据库版本的官方文档比单纯刷Payload效率高出太多。6. SQL Server 2008注入老数据库里的新问题热搜词里专门有“sql server 2008注入”这个我得单独提一下。虽然SQL Server 2008已经停止支持很久了但国内不少企业的内网系统还在用它跑着老业务系统。低版本SQL Server的默认配置和后来的版本有差异对渗透测试来说反而更有“搞头”对做防御的人来说也更有代入感。6.1 和MySQL的三大语法差异SQL Server的注入逻辑和MySQL基本一致但语法细节有明显差异注释符SQL Server用--后跟空格和/* */不支持#。新手在sqlilab里习惯了MySQL的#注释切到SQL Server靶场就很容易水土不服。获取库名表名字段名MySQL里有database()、information_schema.tablesSQL Server用db_name()、sys.tables、sys.columns这套系统视图。报错注入方式MySQL 5.x常用updatexml()、extractvalue()报错SQL Server可以用convert(int, version)在类型转换的过程中把错误信息带出来。6.2 堆叠查询与存储过程调用SQL Server的**堆叠查询stacked queries**支持比MySQL更“开阔”的玩法。所谓堆叠查询就是分号隔开能够在同一个连接里执行多条SQL语句。MySQL的驱动在很多PHP配置下不允许堆叠但SQL Server对堆叠的支持通常更顺畅。在SQL Server堆叠注入下可以执行的语句包括; exec xp_cmdshell whoami不过xp_cmdshell这个扩展存储过程在SQL Server 2005开始是默认关闭的而且它主要影响的是SQL Server服务账号的权限能不能执行往往受限于数据库账号是否属于sysadmin角色。真正的情况是数据库账号权限才是瓶颈。如果只是一个普通权限的数据库账号堆叠注入能做的事可能仅限于insert、update这类写操作。另外SQL Server里还有几个特殊的存储过程值得在授权测试时留意比如xp_regread读注册表、sp_makewebtask写文件、OPENROWSET跨库查询。这些名字不用全背下来但要知道“SQL Server注入的下半场是存储过程”这个概念。6.3 为什么老库更容易出问题SQL Server 2008时代的老系统有一个通病数据库账号权限给得太大。很多系统为了图方便直接用sa账号连数据库。一旦注入点确认攻击者拿到的就是数据库的最高权限接下来要么命令行、要么写文件、要么挪数据。我在实际审计中见过最典型的案例是一个老ERP系统连接字符串写在配置文件里SQL注入点在报表查询参数上数据库账号是sa结果就是整个内网被端。这段不是说注入有多强而是提醒做系统改造的时候数据库账号的权限收敛和代码修复同样重要甚至更急。7. 一个“问题不大”的漏洞为什么二十年都没死我们回到热搜词里最有价值的那一问“现在还存在SQL注入漏洞吗”我的答案是存在而且比你想象的更普遍。但存在方式已经变了它不再是大摇大摆的门户网站漏洞而是躲在新老代码的缝隙里。7.1 为什么封不掉第一存量代码太多。即便是2020年之后的新项目开发团队也未必能把所有SQL都改成参数化。特别是报表系统、动态查询、类Excel的筛选功能“查询条件太多没法全部绑定参数”这种理由我在需求评审会上听了太多次。第二过滤函数不等于安全函数。有些团队喜欢写一个全局的addslashes、mysql_real_escape_string就觉得自己安全了但这类函数只处理特殊字符对宽字节、二次注入数据先入库再拼进SQL防御力很弱。二次注入是很多人容易忽略的盲区数据库中存的数据本来就是“合法数据”但当它被取出来再次拼进SQL时危险就发生了。第三WAF不是万能挡箭牌。主流的云WAF封装了流量、规则级防御但规则的完备性和业务的定制化需求天然矛盾。开发为了一个功能去调WAF规则、加白名单等于把一个安全设备变成装饰品。这种情况我在真实项目中见到不止一次。7.2 怎么踩好“学注入”的边界学注入一定要有边界意识。所有练习请放到授权的靶场环境里进行。DVWA、sqlilab、Pikachu、CTFHub这些是专门给你练手的地方你随便打。但真实互联网上没有授权的站点你一次SQL注入请求发过去就已经触碰了法律红线。很多安全从业者在这个问题上吃过亏我不想看到读者踩同样的坑。学习路径上我的建议是先手工注入再自动化最后回归手工注入。现在很多人直接从sqlmap开始跑出个数据库名就觉得是学会了。但sqlmap跑不出来的时候比如参数被过滤、绕WAF、特殊业务逻辑你手工注入的功底就是最后的救命稻草。靶场里的手工注入练习不是做一遍就完而是把“为什么会这样”想明白再动手下一步。8. 最后分享一点我在实操中的心得写了这么多最后的最后想聊几句经验层面的东西。我印象最深的是第一次在公司内网做代码审计当时用自动化工具扫出一堆疑似注入点但每一个都需要人工结合业务上下文判断。那时候我才意识到工具能帮你快速发现但真正决定你在这个领域走多远的是你对SQL语句执行机制的理解深度。建议每个学SQL注入的新手准备一个自己的“注入笔记”不是抄payload那种而是为每一类关卡记一张“发生了什么”的表格关卡类型输入内容后端真正拼接出的SQL为什么能成功字符型注入1 and 11WHERE id1 and 11闭合了引号构造恒真条件联合查询-1 union select 1,2,3-- -WHERE id-1 union select...让原查询为空union结果接管返回宽字节注入%bf%27反斜杠被宽字节吞掉单引号逃逸编码转换歧义有了这样一张表等真的遇到一个没见过的注入场景你按同样的思路去分析输入是怎么闭合的、哪部分变成了代码、哪部分还是数据、数据库要怎么解析它。把这三个问题回答清楚SQL注入对你来说就不再是一个个payload而是“你又看穿了程序的意图”。靶场刷几遍不是目的。每一次练习之后能把自己代入开发者的角色反问一句“这段代码如果让我来写我会在哪里偷懒”这才是学Web安全最有趣的部分。