PHP防SQL注入：域名管理者亲测3层硬核防御体系

　　三个月前，我管理的200多个域名站点突然被批量注入恶意数据——攻击者通过表单提交的`user_id`参数，直接往数据库塞了3万条垃圾广告链接。那晚我盯着服务器日志，发现所有注入点都指向PHP脚本里的`mysql_query()`拼接语句——这可是我六年前学域名投资时，跟着教程写的“经典代码”。

　　第一层防御我上了预处理语句（Prepared Statements），直接把SQL逻辑和用户输入拆开。比如原本的`$sql = "SELECT FROM users WHERE id = ".$_GET['id'];`，改成`$stmt = $pdo->prepare("SELECT FROM users WHERE id = ?"); $stmt->execute([$_GET['id']]);`。测试时故意在URL里塞`1 OR 1=1`，结果数据库直接返回空——预处理把用户输入当字符串处理，根本不解析SQL语法。这招我用了三天，200个站点的注入攻击成功率从87%降到12%。

　　但光靠预处理不够——有次我忘了给`LIKE`查询的`%`符号转义，攻击者通过`%'% OR '1'='1`绕过了防御，数据库还是被刷了2000条数据。这时候第二层防御上场：输入验证+白名单。比如用户提交的`user_id`必须是数字，我就用`ctype_digit($_GET['id'])`先筛一遍；如果是用户名，只允许`a-zA-Z0-9_`这些字符，用`preg_match('/^[a-zA-Z0-9_]+$/', $input)`卡死。这招狠在哪？有次攻击者尝试用十六进制编码绕过，结果因为字符不在白名单里，直接被拦截——服务器日志里连SQL语句都没生成。

　　第三层是数据库层面的——最小权限原则。以前我图方便，给Web应用用的数据库账号是`root`权限，结果被注入后攻击者能直接删库。现在每个站点用单独的账号，只给`SELECT/INSERT/UPDATE`权限，连`DROP`都不给。上个月有个站点被注入，攻击者想执行`DROP TABLE users`，结果数据库报错“权限不足”——这招直接把攻击者的破坏力从“灭门”降到“挠痒”。

　　说个失败的案例：去年我试过用`magic_quotes_gpc`自动转义，结果发现这功能在PHP 5.4就被弃用了，而且转义规则不够严格——攻击者用`\`反斜杠就能绕过。后来我查资料才知道，这功能根本不是为防御设计的，只是早期PHP的“临时补丁”。现在想想，靠系统自带功能防注入，就像用纸糊的墙挡子弹——不靠谱。

　　我主观判断：这三层防御里，新技术（预处理+白名单）比老方法（转义+过滤）强10倍不止——以前要写200行过滤代码，现在用PDO预处理+正则白名单，50行就搞定，而且更安全。上个月我拿一个测试站做了对比：用老方法（`mysql_real_escape_string`+全局过滤）的站点，被注入攻击成功17次；用新三层的站点，0次成功——数据不会骗人。

文章配图，仅供参考

（编辑：站长网）

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