PHP Web安全实战：SQL注入防护精要

去年10月份，我接手了一个PHP老项目的安全重构——用户反馈登录接口偶尔报500错误，排查后发现是某处SQL查询被恶意注入，攻击者通过构造`' OR 1=1--`直接绕过了验证。这事儿让我意识到，即便项目用了十年PHP，安全防护依然是个动态博弈的过程——新技术不断涌现，攻击手段也在升级，防护必须跟上节奏。

SQL注入的核心漏洞，说白了就是开发者把用户输入当“自己人”了。比如这段代码：`$sql = "SELECT FROM users WHERE username = '".$_POST['username']."'";`——攻击者输入`admin' --`，SQL语句就变成`SELECT FROM users WHERE username = 'admin' --'`，注释符`--`后面的条件全被忽略，直接查到了所有用户。更狠的输入`admin' OR '1'='1`，直接让条件恒真，数据库直接“吐”出所有数据——这种漏洞在2010年前的PHP项目中太常见了，我早年写的代码里也踩过坑。

防护的第一招，是参数化查询（Prepared Statements）。PHP里用PDO或MySQLi扩展的预处理语句，能彻底隔离用户输入和SQL逻辑。比如PDO的写法：`$stmt = $pdo->prepare("SELECT FROM users WHERE username = ?"); $stmt->execute([$_POST['username']]);`——用户输入会被当作纯数据，哪怕输入`' OR 1=1--`，也会被转义成字符串，不会影响SQL结构。去年重构时，我把项目里所有直接拼接SQL的地方都改成了PDO预处理，测试时故意输入`admin' AND sleep(5)--`，发现查询时间没变化（原代码会延迟5秒），说明预处理确实生效了。

但参数化查询不是万能的——比如表名、列名这些动态部分，预处理不支持。这时候得用白名单验证。比如用户要查询`users`表，代码里先定义合法表名数组`$allowed_tables = ['users', 'orders'];`，再检查输入是否在数组里：`if (!in_array($_GET['table'], $allowed_tables)) { die('非法操作'); }`。去年我遇到个案例，攻击者通过`?table=users; DROP TABLE users--`试图删表，因为表名没验证，直接执行了——后来加上白名单，这种攻击就失效了。

还有个容易被忽略的细节——存储过程和函数调用。有些开发者觉得“存储过程是安全的”，但实际不然。比如调用`CALL get_user($_POST['id'])`，如果存储过程里又拼接了SQL，照样可能被注入。去年我审计一个电商项目，发现存储过程`get_order_detail`里用了`CONCAT('SELECT FROM orders WHERE id = ', input_id)`，攻击者输入`1; DROP TABLE orders--`，直接删表了——后来改成用参数化调用存储过程，问题解决。

新技术里，我最看好Web应用防火墙（WAF）的AI防护模块。传统WAF靠规则匹配，比如检测到`OR 1=1`就拦截，但攻击者会用变形：`Or 1=1`、`OR 1=1 /`、甚至编码绕过。去年我测试了某云厂商的WAF，它的AI模块能分析SQL语句的语义——比如识别出“恒真条件”或“注释符”，哪怕输入被变形，也能拦截。测试时我输入`admin' OR 'a'='a`，WAF直接返回403；换成`admin' OR (SELECT 1 FROM information_schema.tables)`（更复杂的注入），也被拦了——这种基于语义的防护，比传统规则强太多。

不过，新技术也有局限——比如AI防护需要训练数据，冷启动时可能漏报；参数化查询对老项目改造成本高（尤其是混合了MySQLi和PDO的代码）。去年我重构那个老项目时，光改SQL查询就花了两周——有些地方用了框架的ORM，有些是直接拼接，得逐个检查。最坑的是，有个第三方登录插件，代码是闭源的，没法改SQL逻辑，只能在外层加WAF拦截——这种“黑盒”组件，安全防护真的被动。

文章配图，仅供参考

（编辑：站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!