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

　　去年八月份那会儿，我原以为SQL注入这种老掉牙的漏洞早该绝迹了——结果运维群里突然炸锅，某PHP项目被扫出高危注入点，直接被甲方勒令下线整改。当时我正对着三十来个浏览器标签改缓存策略，机箱风扇嗡嗡转得跟直升机似的，抬头看了眼消息，差点把水杯打翻——水渍在键盘上洇开，像极了测试环境里那些乱码的SQL报错。

　　后来复盘的时候发现，问题出在一段“祖传”的PHP代码上：用mysql_query直接拼字符串查用户表，参数都没过滤。开发说这代码“用了十年都没事”，我直接怼回去：“十年前大家还在用IE6呢，现在连IE都死了，你跟漏洞讲情怀？”最离谱的是，这项目前年刚从PHP5.4“升级”到7.2，结果连预处理语句都没换——我原以为升级就是改改版本号，结果发现有些人连“升级”俩字都理解错了。

文章配图，仅供参考

　　跟后端争执的时候，我最烦听那句“线上没报错啊”。去年双十一前，某电商项目非要用字符串拼接查订单，我强行要求改预处理，开发说“性能会下降5%”。结果灰度发布当天，安全团队扫出注入点，直接回滚——那5%的性能损失，比不过一次数据泄露的赔偿金。后来我学乖了，直接在CI流程里加SQL注入检测，构建进度条卡在87%的时候，开发自己就会跑来问：“是不是又用了mysql_real_escape_string？”

　　说回PHP的防护精要，其实就三点：第一，用PDO或mysqli的预处理，别手写SQL；第二，参数绑定用命名参数，别用问号占位（省得参数顺序错了自己都发现不了）；第三，最小权限原则，数据库用户只给必要的权限——别用root账号跑应用，这跟把家门钥匙挂在门把手上有什么区别？我见过最离谱的案例，是某项目用MySQL的FILE权限写Webshell，原因就是数据库账号权限没收干净。

　　但最让我后怕的，是那些“看起来没事”的漏洞。去年修复某个项目时，我发现一段代码用intval过滤ID参数，表面看没问题——可要是参数是字符串“123 OR 1=1”呢？intval会把它转成123，但原SQL是“WHERE id=123 OR 1=1”，这注入选都过不了intval这一关？错！如果原SQL是“WHERE id=($id)”，那intval根本没用——因为括号里的内容会被直接拼进SQL。这种“伪防护”比没防护更危险，因为它会让人误以为安全了，结果被黑的时候连日志都找不到。

　　跟设计吐槽的时候，我说现在前端都在搞安全头（CSP、X-XSS-Protection），后端怎么还在纠结SQL注入？设计说：“因为前端漏洞一眼就能看到，后端漏洞得等黑产来扫。”我点头——就像我桌上的数据线，缠成一团的时候没人管，等要充电了才骂“谁又乱放”。上周安全团队扫出某接口用GET传密码，开发说“GET方便调试”——我直接把Postman截图甩群里：“调试用POST，GET参数会留浏览器历史，这都不懂？”

　　现在我最头疼的，是那些“部分防护”的项目。比如用预处理查用户，但分页参数还是拼字符串；或者用PDO但没关模拟预处理（emulate prepares）。去年修复某CMS时，我发现它用PDO::prepare，但MySQL驱动默认开模拟预处理——这相当于用防盗门配了把塑料钥匙，看着安全，一撬就开。后来我强制在配置里加`PDO::ATTR_EMULATE_PREPARES => false`，开发说“这样性能会差”，我回：“差5%总比数据泄露强，你要不乐意，自己跟安全团队解释。”

　　外卖塑料袋响个不停的时候，我突然想到——SQL注入防护其实跟混合云运维有点像：都得防“未知的未知”。你在云上部署应用，得考虑VPC怎么划、安全组怎么配、IAM权限怎么收；你在本地防注入，得考虑输入过滤、输出转义、最小权限。但归根结底，都是“别信任何外部输入”——就像我从来不喝同事递来的水，除非我看着他从饮水机接的。

　　现在我的检查清单就三条：1. 不用mysql_扩展；2. 不用字符串拼接SQL；3. 数据库账号别给FILE/PROCESS权限。要是开发跟我说“这样写方便”，我就回：“方便被黑吗？”上周还遇到个奇葩，非说预处理“影响SQL优化”——我直接把MySQL官方文档甩他脸上：“官方都推荐预处理，你比MySQL开发者还懂？”

　　最后说句实话：SQL注入防护没什么“精要”，就是老老实实用预处理、收权限、过滤输入。那些花里胡哨的“防护技巧”，90%都是自欺欺人。就像我机箱风扇，转了三年没换，结果上周突然罢工——我原以为它能撑到项目下线，结果它用实际行动告诉我：“别侥幸，该换就得换。”

（编辑：站长网）

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