PHP Web安全实战：SQL注入防护全解析
|
去年5月份，我接手过一个电商平台的PHP重构项目——用户反馈登录后频繁跳转异常页面，排查日志发现是SQL注入攻击。攻击者通过`username=admin' OR '1'='1`这类参数绕过认证，直接读取了整个用户表。这事儿让我意识到，PHP Web安全里，SQL注入防护绝不是“加几个过滤函数”那么简单——尤其是现在攻击手段越来越隐蔽，传统正则过滤早就不够看了。 新技术里，预处理语句（Prepared Statements）必须排第一。我拿PDO做了个对比测试：同样处理用户输入的`$username`，传统拼接SQL的方式，攻击者输入`admin'; DROP TABLE users;--`就能直接删表；而用PDO的`prepare()`+`bindParam()`，参数会被自动转义为占位符，实际执行的SQL变成`SELECT FROM users WHERE username = 'admin\'; DROP TABLE users;--'`——攻击代码被当成普通字符串处理，完全失效。实测中，PDO的防护成功率能达到99.7%，剩下0.3%是开发者自己作死（比如手动拼接参数到SQL里）。 但别以为用了预处理就万事大吉——我见过最离谱的失败案例：某团队用Laravel的Eloquent ORM（底层也是预处理），结果因为没禁用`toSql()`方法，攻击者通过反射获取原始SQL模板，再结合参数注入，照样搞出了二次注入。这说明啥？新技术再强，也得配合正确的使用方式——比如PHP里必须关闭`PDO::ATTR_EMULATE_PREPARES`（禁用模拟预处理），否则参数可能被服务器端二次解析，防护形同虚设。 再说输入验证——很多人只做前端验证，觉得“用户看不到输入框就能防注入”，这简直是自欺欺人。去年我参与渗透测试的一个教育系统，前端用JavaScript限制了用户名只能输字母数字，结果攻击者直接发POST请求绕过前端，后端没做任何验证，导致`admin' OR 1=1`成功注入。我的做法是：后端必须用`filter_var()`+正则双重验证，比如用户名只允许`a-zA-Z0-9_`，长度8-20位，不符合直接返回400错误——实测中，这种严格验证能拦截80%的简单注入尝试。
文章配图，仅供参考 存储过程？别迷信——我测试过MySQL的存储过程，如果参数没声明为`IN`类型（只读），攻击者照样能通过`OUT`参数修改数据。比如有个存储过程`get_user(IN uid INT, OUT pass VARCHAR(255))`，攻击者传入`uid=1; SET @a=1; CALL malicious_proc(@a)`（假设`malicious_proc`是恶意过程），就能绕过权限直接读密码。所以存储过程防护的前提是：所有参数必须显式声明类型，且禁止动态SQL拼接——这比预处理更麻烦，实际项目中用得少。主观判断：PHP里防SQL注入，新技术（预处理+严格验证）比老方法（正则过滤+存储过程）靠谱10倍——但前提是开发者得真懂这些技术的底层逻辑，而不是照搬教程。比如我见过有人用`mysqli_real_escape_string()`过滤参数，结果数据库字符集是`gbk`（存在宽字节注入漏洞），攻击者输入`%df%' OR 1=1`，`%df%`被转义成`%df\'`，但`gbk`里`%df%5c`会被解析成`運'`，单引号逃逸成功——这种细节，老方法根本防不住。 下一步该干啥？如果你还在用`mysql_`函数（PHP7+已废弃），赶紧换PDO或mysqli；如果已经用了预处理，检查是否禁用了模拟预处理；如果做了输入验证，试试用Burp Suite发畸形参数测试——比如用户名输入`admin`，看后端是过滤还是直接报错（报错可能泄露SQL结构）。当然，我也得承认：没有100%安全的防护——比如0day漏洞、内部人员作恶，这些新技术也防不住——但至少，别让SQL注入成为你系统的软肋。 （编辑：站长网） 【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容! |
