一、实验目的
- 掌握SQL注入漏洞在Medium、High级别下的防护机制与绕过思路
- 学会通过抓包修改参数进行注入测试
- 完成注入检测、字段数判断、查库、查表、查账号密码
- 对比不同安全等级的防护缺陷，理解安全加固的正确方式
二、实验原理
1.Medium级原理
- 防护：前端下拉框限制输入+单引号转义过滤
- 漏洞类型：数字型注入
- 绕过：抓包修改POST参数，数字注入不需要单引号，可直接绕过过滤
2.High级原理
- 防护：页面跳转+SQL语句增加LIMIT1
- 漏洞类型：数字型注入
- 绕过：使用#注释掉LIMIT1，注入逻辑与Medium一致。
三、实验前置准备
登录DVWA系统。在DVWA Security当中选择medium选项，并提交。
然后选择SQL Injection，在该界面中，只能选择UserID，因此需要通过BurpSuite或者firebug之类工具绕过限制，在此使用BurpSuite绕过这个限制。
启动BurpSuite，使用自带的浏览器重新访问dvwa，并登录，将将DVWA Security等级设置为medium，然后选择SQLInjection。
四、实验步骤及结果
步骤一：Medium级别实验。
在DVWA中尝试提交一个ID，在BurpSuite的repeater中可查看捕获到的提交信息。选择Proxy中的HTTP history，选择一个提交的请求，右键，在弹出的菜单中选择"send to repeater"，使用BurpSuite的repeater模块可以重复发送数据，查看返回数据。打开BurpSuite中的repeater模块：
1. 修改参数值为1' or 1=1 # ，并重新发送
在BurpSuite中的repeater模块中修改发送的数据，将参数值修改为1' or 1=1 #
选择"send"，重新发送**，保存截图并分析结果。**
分析结果：
当前的 Payload 1' or 1=1 # 在 Medium 级别 报错，核心原因是：
- Medium 级别是数字型注入，不是字符型：后端 SQL 语句是 SELECT * FROM users WHERE user_id = [id]，user_id 是数字类型，不需要单引号闭合；
- 单引号被转义：Medium 级别用 addslashes() 函数，把输入的 ' 转成了 \'，导致 SQL 语法直接报错；
- Payload 格式错误：你在 Burp 里写的 id=1' or 1=1 #&Submit=Submit 中，且单引号完全多余。
2. 继续将value值修改为1 or 1=1 # 进行测试。
保存截图并分析结果。
分析结果：
注入原理：Medium 级别为数字型注入，后端 SQL 为SELECT * FROM users WHERE user_id = $id，or 1=1使查询条件恒为真，#注释后续语句，成功绕过限制
3. 注入测试：
分别查询所有数据库名、dvwa中的数据表名、users表中的字段名。
列出查看所有数据库名的payload：
执行结果截图：
查看dvwa中的数据表名的payload：
执行结果截图：
查看users表中的字段名的payload:
执行结果截图：
步骤五、High级别实验。
在High级别的SQL Injection中输入ID后会页面跳转，打开新窗口，但仍传递id参数
注入测试：查询所有数据库名、dvwa中的数据表名
- 查询所有数据库名
保存截图并分析结果。
结果分析
- 在弹窗 session-input.php 中提交 Payload：
plaintext
1' union select 1,group_concat(schema_name) from information_schema.schemata#
- 主页面成功显示：
plaintext
information_schema,dvwa,mysql,performance_schema,sys
- 分析结论：
High 级别虽然采用弹窗输入、并限制 LIMIT 1，但未对 union 语句进行过滤。通过单引号闭合 + # 注释即可绕过限制，成功获取所有数据库名，证明 High 级别防护依然不足。
- dvwa中的数据表名
保存截图并分析结果。
结果分析
- 在弹窗输入 Payload：
1' union select 1,group_concat(table_name) from information_schema.tables where table_schema='dvwa'#
- 主页面显示：
guestbook,users
- 分析结论：
High 级别对字符串输入无有效检测，未使用预编译或严格过滤。攻击者仍可通过 union 联合查询，直接读取库下表结构。注入成功，说明 High 级别防护仍然无法彻底阻止 SQL 注入。
五、实验总结
High 级别注入点依然存在于 id 参数，通过弹窗入口提交 Payload 即可成功执行 union 查询。无论是查数据库名还是查表名，都被成功获取，证明 High 级别只是改变交互方式，并未真正加固 SQL 注入防护。正确防御必须使用参数化查询（预编译语句）。