1. SQL注入漏洞初探从Pikachu靶场开始第一次接触SQL注入时我完全被这种通过输入框就能控制数据库的神奇攻击方式震惊了。在Pikachu靶场这个专为Web安全学习设计的实验环境中我们可以安全地体验各种SQL注入攻击手法。不同于真实网站的违法风险这里可以放心大胆地练习。SQL注入的本质就是攻击者通过构造特殊输入改变原有SQL语句的逻辑。比如一个简单的登录场景开发者原本的SQL可能是SELECT * FROM users WHERE username输入的用户名 AND password输入的密码但如果用户在用户名输入admin--SQL就变成了SELECT * FROM users WHERE usernameadmin-- AND password任意密码--后面的内容被注释掉系统直接返回admin用户的信息完全绕过了密码验证。在Pikachu靶场中这种基础注入场景被设计得非常直观特别适合新手理解原理。2. 数字型注入实战Burp Suite配合攻击2.1 环境准备与请求捕获首先启动Pikachu靶场的数字型注入模块我习惯用Burp Suite这个神器来拦截请求。配置好浏览器代理后在靶场页面随便输入个数字点击查询Burp的Proxy模块就会立即捕获到这个POST请求。右键发送到Repeater模块这里可以反复修改和发送请求是测试注入的绝佳场所。2.2 确定字段数量的技巧在Repeater中修改id参数为1 order by 4点击Send发现报错说明字段数少于4。逐步降低数字测试当order by 3时报错但order by 2正常时就确定了字段数是2。这个步骤就像在黑暗中摸索房间的大小通过不断试探边界来获取信息。2.3 信息提取全流程接下来用union select确定回显位我常用的payload是id1 union select 1,2看到页面显示数字1和2的位置后就可以在这些位置替换我们需要的信息。比如获取数据库名id1 union select 1,database()要获取表名时这个payload特别实用id1 union select 1,group_concat(table_name) from information_schema.tables where table_schemapikachu记得第一次成功爆出表名时那种原来数据库这么透明的震撼感至今难忘。之后用同样的方法获取users表的列名和数据整个过程就像剥洋葱一样层层深入。3. 字符型注入的闭合技巧3.1 识别闭合方式字符型注入最大的特点就是需要处理引号闭合。在Pikachu的GET型注入点输入1时页面报错但加上注释符后1--页面恢复正常这就确定了闭合符号是单引号。不同场景下可能是双引号、括号等组合测试时要耐心尝试。3.2 URL编码的注意事项由于是通过URL传参特殊字符需要编码。比如空格变成%20单引号是%27注释符--后面要加空格用--表示。实际攻击时我经常犯的错就是忘记编码导致payload不生效。经过多次踩坑后现在我会先用浏览器开发者工具观察自动编码的效果。3.3 联合查询实战构造URL时完整的注入过程如下爆列数name1%27%20order%20by%202-- 看显位name1%27%20union%20select%201,2-- 爆数据name1%27%20union%20select%20username,password%20from%20users--GET型注入的优势是所见即所得所有操作直接在URL中完成非常适合演示SQL注入原理。但实际环境中POST型注入更为常见。4. 搜索型与XX型注入的独特之处4.1 搜索型注入的百分号陷阱搜索型注入的闭合符号通常包含百分号%这是最容易被忽略的细节。在Pikachu靶场中输入1报错显示%附近有语法错误就提示我们需要用%来闭合。正确的payload形如name1%%27union select 1,2,3--这种注入在电商网站的商品搜索等功能中很常见开发者容易忽视对百分号的过滤。4.2 XX型注入的括号难题XX型注入最大的特点是闭合时需要处理括号。输入1报错但1)正常时说明闭合符是)。这类注入常出现在存储过程调用等场景payload需要特别注意括号匹配name1%27)union select 1,2--在实际渗透测试中遇到报错信息一定要仔细阅读里面往往藏着关键的闭合提示。5. Insert/Update注入的隐蔽攻击5.1 注册功能的注入利用Pikachu靶场的insert注入模块模拟了用户注册场景。注册时用Burp拦截请求在用户名参数插入or updatexml(1,concat(0x7e,database()),1)or这个payload利用了XML函数报错回显的特性。0x7e是波浪号~的十六进制作为分隔符使回显更明显。当数据库名出现在报错信息中时就实现了信息泄露。5.2 数据截断的解决方案由于updatexml函数只能显示32位数据当需要获取更长信息时需要用substring函数分段获取。例如获取表名or updatexml(1,substring(concat(0x7e,(select group_concat(table_name) from information_schema.tables where table_schemapikachu)),1,32),1)or然后修改substring的起始位置获取剩余内容。这种注入方式不需要回显位在盲注场景特别有用。5.3 个人信息修改的update注入在用户修改资料功能处同样可以用updatexml进行报错注入。我常用的测试方法是先正常修改一次信息拦截请求后在各参数尝试插入单引号观察哪个参数存在注入点。Update注入的危害往往更大因为它可以直接修改数据库内容。6. SQL注入防御的实战方案6.1 参数化查询的绝对优势防御SQL注入最有效的方式就是使用参数化查询。以PHP为例对比危险代码和安全代码// 危险写法 $query SELECT * FROM users WHERE id $_GET[id]; // 安全写法 $stmt $pdo-prepare(SELECT * FROM users WHERE id ?); $stmt-execute([$_GET[id]]);参数化查询将输入数据严格作为参数处理从根本上避免了SQL拼接的风险。我在项目中迁移到参数化查询后注入漏洞报告直接归零。6.2 输入验证的二重防护虽然参数化查询是首选但额外的输入验证仍不可或缺。比如数字型参数应该用is_numeric()验证日期参数检查格式合法性。在Pikachu靶场的防御练习中我习惯采用白名单机制只允许预期的字符模式通过。6.3 最小权限原则数据库账户应该遵循最小权限原则。Web应用使用的数据库账号不应该有DROP TABLE、FILE等危险权限。在Pikachu的防御实验中创建一个只有SELECT权限的专用账号即使发生注入也能限制损害范围。6.4 安全工具的辅助WAF(Web应用防火墙)可以作为最后一道防线。在测试环境中部署开源的ModSecurity配置SQL注入规则集后能拦截大部分自动化攻击。但要注意WAF可能存在绕过风险不能替代代码层面的安全开发。