前言在近期的Web安全课程学习中我们接触到了OWASP Top 10中的头号杀手——SQL注入SQL Injection。虽然老师在课堂上讲解了理论但“纸上得来终觉浅”。为了真正掌握这一核心漏洞我搭建了本地靶场环境如DVWA或Pikachu对SQL注入进行了全流程的复现与测试。本文将详细记录我从判断注入点、猜解字段数到获取数据库敏感信息的完整思路并总结相应的防御策略。一、 什么是SQL注入简单来说SQL注入就是攻击者将恶意的SQL命令插入到Web表单提交或输入域名或页面请求的查询字符串中最终欺骗服务器执行恶意的SQL命令。其根本原因在于代码与数据未分离。后端程序没有对用户输入的数据进行严格的过滤或转义直接将其拼接到SQL语句中执行。二、 靶场环境搭建与测试本次实战我使用了经典的 Pikachu 靶场中的“数字型注入”模块作为测试对象。1. 寻找注入点首先我在搜索框中输入 1页面正常返回了用户 lucy 的信息。接着我尝试输入 1单引号页面报错提示 SQL 语法错误。这一步非常关键它证明了后端确实将我的输入拼接进了数据库查询语句中且单引号破坏了原有的SQL结构。2. 构造Payload进行测试确认存在注入点后我开始使用联合查询Union Select进行利用。- 第一步判断字段数我使用 ORDER BY 语句来猜测当前查询的列数。输入1 order by 3 # - 页面正常。输入1 order by 4 # - 页面报错。由此推断当前查询结果包含 3个字段。- 第二步确定回显位利用 UNION SELECT 语句查看哪一列的数据会显示在页面上。输入1 union select 1, 2, 3 #页面在对应位置显示了数字 2 和 3说明这两个位置是我们可以控制的“回显位”。三、 深入利用获取敏感数据确定了回显位后我们就可以像剥洋葱一样获取数据库信息了。1. 获取当前数据库名Payload: 1 union select 1, database(), 3 #结果显示当前数据库名为 pikachu。2. 获取表名我们需要查询 information_schema.tables 系统表。Payload: 1 union select 1, group_concat(table_name), 3 from information_schema.tables where table_schemapikachu #这里用到了 group_concat 函数将所有表名连接成一个字符串显示出来我成功看到了 users, member 等关键表名。3. 获取列名与数据最后针对 users 表我查出了 username 和 password 字段并最终拖取了所有用户的账号密码哈希值。四、 遇到的困难与解决在测试过程中我也遇到了一些阻碍。例如在使用 group_concat 时如果数据量过大可能会因为长度限制显示不全。通过查阅资料我了解到了可以通过修改 MySQL 配置 group_concat_max_len 来解决或者使用 LIMIT 分页获取数据。这让我意识到渗透测试不仅是技术的比拼更是耐心和细心程度的考验。五、 防御策略思考一课一得作为未来的安全从业者不仅要会“攻”更要懂“防”。针对SQL注入我认为最有效的防御手段有以下几点1. 使用预编译语句Prepared Statements这是根治SQL注入的方法。通过将SQL逻辑与数据分离无论用户输入什么数据库都只将其视为数据而非指令。在Java中使用 PreparedStatement在PHP中使用 PDO 均可实现。2. 严格的输入验证对用户的输入进行白名单校验例如ID字段必须为纯数字。3. 最小权限原则数据库连接账号不应拥有 DROP、GRANT 等高危权限防止攻击者进一步提权。六、 总结通过这次对SQL注入的实战演练我深刻理解了“数据即代码”的危险性。从最初的一个单引号报错到最后获取整个数据库权限每一步都需要严密的逻辑推理。这次项目不仅巩固了我的SQL语法基础更培养了我的安全思维。在未来的学习中我将继续探索XSS、CSRF等其他Web漏洞努力成为一名合格的Web安全工程师。
