PHP站长11年实战：SQL注入防护精要
|
去年春天，我接手了一个被SQL注入打瘫的PHP论坛——攻击者通过构造畸形参数，直接从数据库里拖走了20万条用户信息，连管理员密码的哈希值都没放过。这已经是近三年里我遇到的第四起类似事故，每次修复时看着被篡改的表结构、被删除的备份数据，那种无力感比喝十杯咖啡还难受——毕竟，防护SQL注入这事儿，光靠转义特殊字符早不够用了。 我翻出2013年写的第一套防护代码，那会儿还在用mysql_real_escape_string()函数，参数直接拼进SQL语句里，像把生肉往油锅里扔——现在看简直是自杀式编程。后来换了PDO预处理，本以为能高枕无忧，结果去年春天那起事故里，攻击者居然绕过了预处理，通过修改HTTP头里的Content-Type字段，让服务器把POST数据当成了JSON解析，直接把恶意SQL塞进了参数里——这招我之前连听都没听过，修复时查了三小时文档才搞明白原理。
文章配图，仅供参考 现在我的防护体系里，最核心的是三层过滤——第一层在入口处截断所有非预期数据类型，比如用户ID必须是数字，就用ctype_digit()函数硬核校验，不是数字直接返回400错误；第二层用PDO的绑定参数，但必须显式指定数据类型，比如绑定整数就用PDO::PARAM_INT，不能偷懒用默认的PDO::PARAM_STR；第三层是数据库权限最小化，普通查询账号只给SELECT权限，写操作必须换专用账号，连表名都要用白名单校验——去年有个案例，攻击者通过修改表名参数，试图访问information_schema库，结果被白名单直接拦住，日志里只留了条"Invalid table name: '`information_schema`.tables'"的错误记录。新技术里最让我惊喜的是参数化查询的进化——以前用PDO预处理，遇到复杂查询还得手动拼接部分SQL，比如动态排序字段，现在用Laravel的Eloquent ORM，直接写User::orderBy($sortField)->get()，$sortField会被自动转义成合法的列名，连白名单都不用维护。上个月我测试了一个极端案例：把$sortField设为"id; DROP TABLE users--"，结果Eloquent直接把它转义成了字符串，执行的SQL是"SELECT FROM `users` ORDER BY 'id; DROP TABLE users--'"，表安然无恙——这种"防傻"设计，比靠开发者自觉靠谱多了。 但新技术也不是万能的——上个月我帮朋友修复一个老系统，他用了某开源框架的最新版，号称"完全防注入"，结果攻击者通过修改HTTP头里的X-Forwarded-For字段，把恶意IP塞进了日志表，然后利用日志表的写入权限，通过INSERT语句注入了SQL——原来框架只防护了查询参数，没管日志写入这种"非用户输入"场景。这事儿给我提了个醒：防护SQL注入不能只信框架，得自己把所有数据流都捋一遍，连HTTP头、Cookie、文件上传这些"边缘入口"都不能放过。 现在我的防护清单里多了条硬规则：所有动态SQL必须经过两道审核——一道是代码层面的参数校验，一道是数据库层面的权限控制。比如用户注册时，手机号字段先用正则/^1[3-9]\d{9}$/校验，再用PDO绑定参数插入，数据库账号只给INSERT权限，连UPDATE权限都不给——就算攻击者绕过了第一道校验，也没法通过第二道权限限制搞破坏。上个月测试时，我故意把手机号参数改成"13800000000'; DROP TABLE users--"，结果PDO把它转义成了字符串，数据库账号又没DROP权限，执行的SQL是"INSERT INTO `users` (`phone`) VALUES ('13800000000'; DROP TABLE users--')"，表照样好好的——这种"双保险"设计，才是真正的安心。 下一步我打算把防护逻辑抽成独立组件，做成Composer包开源出去——毕竟这11年踩过的坑、攒的经验，不能只自己用。不过我也清楚，SQL注入的攻击手法一直在变，去年流行的JSON注入、HTTP头注入，今年可能又冒出新花样——防护这事儿，没有终点，只有不断更新的"漏洞清单"和"补丁日志"。 （编辑：站长网） 【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容! |
