1. DVWA靶场与SQL注入基础认知第一次接触DVWA(Damn Vulnerable Web Application)这个靶场时我就被它精心设计的漏洞环境所吸引。作为一款专为安全测试人员设计的PHP/MySQL漏洞演练平台DVWA将常见Web漏洞集成在一个系统中其中SQL注入模块尤其值得深入研究。SQL注入(SQL Injection)作为OWASP Top 10长期占据榜首的漏洞类型其本质是通过构造特殊输入改变原有SQL语句的逻辑结构。在DVWA的SQL注入关卡中我们可以观察到典型的数字型注入场景——当用户在输入框提交用户ID时后端执行的SQL语句大致是SELECT first_name, last_name FROM users WHERE user_id $input这种直接将用户输入拼接到SQL语句中的做法就是注入漏洞的根源。通过输入1 or 11这样的特殊字符串攻击者可以获取整个users表的数据。我在本地搭建的DVWA 1.10版本上测试时发现随着安全等级从Low到High的变化防护措施也在逐步增强这正是一个绝佳的学习梯度。注意搭建DVWA环境时务必使用隔离的网络环境我通常在VirtualBox中配置Kali Linux Docker的隔离环境避免意外影响真实系统。2. Low安全级别的注入实战分析将DVWA安全级别调至Low后我们面对的是最基础的注入场景。页面仅有一个简单的用户ID输入框没有任何防护措施。通过Burp Suite抓包可以看到输入值直接以GET参数形式传递http://dvwa.test/vulnerabilities/sqli/?id1SubmitSubmit2.1 基础注入检测首先输入单引号测试1页面返回SQL语法错误这确认了注入点的存在。接着使用经典的永真条件测试1 or 11 --这个输入会构造出SELECT ... WHERE user_id 1 or 11 -- --是MySQL的单行注释符它使得后续的引号被注释掉避免语法错误。在我的测试中这个payload成功返回了所有用户信息。2.2 使用UNION注入获取数据更高级的UNION注入可以获取数据库的敏感信息。首先需要确定查询返回的列数通过ORDER BY子句逐步测试1 order by 2 -- # 正常 1 order by 3 -- # 报错确认列数为2后构造UNION查询获取数据库版本和当前用户1 union select version(), user() --在我的测试环境中这返回了MySQL版本5.7.36-0ubuntu0.18.04.1 当前用户dvwalocalhost实操心得UNION注入时要注意前后查询的列数必须一致否则会报错。我常用null作为占位符来匹配列数。3. Medium安全级别的绕过技巧将安全级别调至Medium后发现输入框变成了下拉菜单。查看源码发现使用了PHP的mysql_real_escape_string()对输入进行处理同时参数传递方式变为POST。3.1 绕过前端限制虽然前端使用了下拉菜单但通过Burp Suite拦截请求后可以直接修改POST参数id1 or 11SubmitSubmit由于Medium级别没有使用引号包裹输入而是直接将输入作为数字处理所以不需要闭合引号。成功执行后返回所有用户信息。3.2 使用UNION注入的技巧在Medium级别下UNION注入需要稍作调整1 union select 1,concat_ws(0x3a,user(),database()) --这里0x3a是冒号的十六进制表示用于分隔多个字段。在我的测试中这个payload返回了1 rootlocalhost:dvwa4. High安全级别的挑战与突破High级别采用了更严格的防护措施输入被限制在单独的弹窗页面且使用了预处理语句的雏形。4.1 利用Cookie注入查看源码发现虽然对输入进行了转义但通过Cookie传递的id参数存在注入点。使用HackBar等工具修改Cookie1 union select null,concat(user(),0x3a,database()) --这个注入成功返回了数据库用户和名称证明即使在前端做了严格限制后端实现不当仍会导致漏洞。4.2 盲注技术应用当页面不直接显示数据时可以使用基于时间的盲注。例如1 AND IF(SUBSTRING(database(),1,1)d,sleep(3),0) --如果数据库名的第一个字母是d页面响应会延迟3秒。在我的测试中这个技术成功验证了数据库名的首字母。5. Impossible级别的安全机制分析将安全级别调至Impossible后可以看到完善的防护措施使用PDO预处理语句严格的输入类型检查最小权限原则用户必须登录才能操作查看源码可以看到关键的安全实现$data $db-prepare(SELECT first_name, last_name FROM users WHERE user_id (:id) LIMIT 1;); $data-bindParam(:id, $id, PDO::PARAM_INT);这种参数化查询从根本上杜绝了SQL注入的可能是开发中必须采用的安全实践。6. 防御SQL注入的最佳实践根据DVWA各个安全级别的对比我总结出以下防御措施参数化查询始终使用PDO或MySQLi的预处理语句输入验证对输入类型、格式、范围进行严格检查最小权限数据库用户只赋予必要权限错误处理避免显示详细的数据库错误信息安全编码整数参数强制类型转换(int)$input字符串参数使用预处理避免动态拼接SQL在我的实际开发中还会额外添加Web应用防火墙(WAF)规则定期的安全扫描自动化测试用例覆盖注入场景7. 常见问题与解决方案Q1UNION注入时出现列数不匹配错误A先通过ORDER BY确定列数不足的用NULL补全。例如1 union select null,null,database() --Q2过滤了空格如何绕过A使用注释符/**/或号代替空格1/**/union/**/select/**/1,2--Q3如何快速获取数据库表结构A通过information_schema查询1 union select table_name,column_name from information_schema.columns where table_schemadatabase()--Q4DVWA返回空白页面怎么办A检查以下几点PHP版本是否兼容建议5.4-7.4配置文件config.inc.php中的数据库连接信息目录权限是否正确是否完成了数据库初始化Q5实际渗透测试中与DVWA有何不同A实际环境中还会遇到WAF拦截需要绕过编码/加密参数需要处理更复杂的过滤规则需要保持隐蔽性在真实项目中我通常会结合自动化工具和手动测试。先使用sqlmap进行初步探测再针对特殊过滤手动构造payload。同时会特别注意避免对系统造成实际影响测试前务必备份数据。