dvwa之sql注入

DVWA的注入SQL Injection页面，输入框里敲一个 1'，注入页面直接甩回来一条MySQL报错。注入这就是注入最原始的注入点——用户输入被拼进SQL语句，数据库把错误信息原样吐给浏览器。注入很多人第一次看到这个报错，注入反应是注入“哦，有注入”，注入但真正该注意的注入是：报错本身说明后端没有做任何过滤，连基本的注入转义都没有。

DVWA默认安全等级是注入Low，源码大概长这样：$id = $_GET['id']; $query = "SELECT first_name,注入 last_name FROM users WHERE user_id = '$id';"。变量直接嵌在单引号里，注入闭合单引号就能改写查询逻辑。注入输入 1' OR '1'='1，注入整张users表的所有记录都会被拉出来。这不是什么高级技巧，就是字符串拼接的必然结果。

我习惯先测列数。 1' ORDER BY 1-- 正常，1' ORDER BY 2-- 正常，1' ORDER BY 3-- 报错，说明查询返回两列。接着用 1' UNION SELECT 1,2-- 确认回显位置，页面上会显示数字1和2，代表两个字段都能输出到前端。把2换成 database()，当前库名就出来了——通常是 dvwa。

有人到这里就停了，觉得拿到库名就算完成。实际渗透中，库名只是起点。DVWA的MySQL版本较老，没有information_schema的限制，可以直接查表：1' UNION SELECT 1,table_name FROM information_schema.tables WHERE table_schema='dvwa'-- 。结果会列出 guestbook 和 users 两张表。users表里有什么？继续查列名：1' UNION SELECT 1,column_name FROM information_schema.columns WHERE table_name='users'-- 。user、password、first_name、last_name，一目了然。

密码字段是MD5存的。DVWA的users表里，admin的密码哈希是 5f4dcc3b5aa765d61d8327deb882cf99，对应明文 password。你可以用 1' UNION SELECT user,password FROM users-- 直接把所有用户名和哈希拖出来，然后丢进cmd5或者hashcat跑。Low级别下，整个过程不需要任何绕过，因为压根没有防护。

切到Medium级别，源码变了：$id = mysql_real_escape_string($id);。单引号被转义，1' 变成 1\'，闭合不了。但DVWA的Medium有个特点——前端是下拉框，后端却仍然接受GET参数。用Burp抓包改 id=1' OR '1'='1，发现还是能注入。为什么？因为 mysql_real_escape_string 只转义单引号，不处理数字型注入。如果查询是 WHERE user_id = $id（没有引号包裹），那么 1 OR 1=1 直接生效，压根不需要引号。DVWA Medium的源码里，id确实被单引号包着，但转义函数在特定字符集下可能被绕过，比如GBK宽字节。不过更简单的思路是：Medium的SQL查询用了 mysql_real_escape_string，但没过滤 -- 注释符和 UNION 关键字，所以 1' UNION SELECT 1,2-- 依然能跑通，只是单引号需要处理。实际测试中，Medium级别直接输入 1' UNION SELECT user,password FROM users-- 会失败，因为单引号被转义。但改成 1 UNION SELECT user,password FROM users-- 呢？不行，因为原查询是 WHERE user_id = '1'，数字型拼接不成立。所以Medium的注入点其实需要结合Burp改包，利用 1' 被转义后变成 1\'，而 \ 在MySQL里是转义符，导致后面的单引号被“吃掉”，查询结构错位。具体利用方式这里不展开，但核心是：转义函数不是万能药。

High级别用了 LIMIT 1 加预处理语句？不，DVWA High的源码是 $id = $_GET['id']; $query = "SELECT first_name, last_name FROM users WHERE user_id = '$id' LIMIT 1;"。看起来和Low差不多，但页面变成弹窗输入，且只返回第一行。这时候 UNION SELECT 依然可用，只是需要把 LIMIT 1 注释掉或者用 # 截断。输入 1' UNION SELECT user,password FROM users#，注意 # 后面要跟一个空格或者换行，否则可能被浏览器截断。High级别下，回显只有一行，但你可以用 GROUP_CONCAT 把所有用户名密码拼成一列输出：1' UNION SELECT 1,GROUP_CONCAT(user,0x3a,password) FROM users#。这样一次性拿到全部数据。

Impossible级别就不用试了，源码里用了PDO预处理， $stmt->bindParam(':id', $id, PDO::PARAM_INT)，输入被强制转成整数，注入点彻底消失。从Low到Impossible，DVWA把SQL注入的防御演进路线摆得很清楚：字符串拼接→转义→限制回显→预处理。每一级的绕过方式不同，但根子都在于“用户输入是否被当作代码执行”。

实际挖洞时，DVWA的报错信息帮了大忙，但真实环境往往关闭了错误回显。那时候就得靠盲注——布尔盲注或者时间盲注。布尔盲注靠页面差异判断真假，时间盲注靠 SLEEP() 延迟。DVWA的Low级别也能测盲注，比如 1' AND SLEEP(5)-- ，页面卡5秒说明注入成功。不过有回显的时候，没人愿意用盲注，太慢。

最后提一句：DVWA的SQL注入页面，输入框里敲 1' 报错，敲 1'-- 正常，这个差异就是注入存在的铁证。别急着上sqlmap，先手动跑一遍，理解每一步为什么能成，比工具跑出来的结果有价值得多。

(责任编辑：娱乐)