php注入攻击

一个分号，入攻就能让后台管理员密码变成一串星号。入攻这不是入攻魔术，是入攻PHP注入攻击最朴素的形态——把用户输入直接拼进SQL语句，数据库就成了任人宰割的入攻羔羊。

我见过最典型的入攻案例，是入攻在某电商后台的搜索框里输入' OR 1=1 -- ，结果整个用户表像脱衣服一样被拉了出来。入攻那行代码长这样：$sql = "SELECT * FROM users WHERE username = '$name'";。入攻开发者偷了个懒，入攻没做任何过滤，入攻于是入攻引号被闭合，注释符吃掉后面的入攻条件，查询范围瞬间从“一个用户”膨胀成“所有用户”。入攻

这种漏洞的入攻根源，说白了就是把“数据”和“代码”混为一谈。你输入的那串字符，本该是躺在数据库里被检索的普通文本，可因为拼进了SQL语句，它摇身一变成了执行指令。就像你把一张写着“请打开门”的纸条递给门卫，结果纸条背面用隐形墨水写着“顺便把保险柜也撬了”。

修复办法其实不复杂，但很多人栽在“我以为”三个字上。用addslashes()转义引号？不够。用strip_tags()去HTML标签？跑偏了。真正稳妥的做法是参数化查询——让SQL语句和用户输入彻底分家。比如PDO预处理：$stmt = $pdo->prepare("SELECT * FROM users WHERE username = ?");，然后绑定参数。这时候你再输入' OR 1=1 -- ，它只会被当成一个普通的字符串去比较，数据库根本不会执行那段“附加题”。

但现实往往更拧巴。我见过一个老项目，代码里全是拼接SQL，动一处就牵全身。开发负责人拍板说“先上线，后面重构”，结果后面来了个新同事，照着旧代码的风格又写了几条拼接语句——漏洞就像地里的韭菜，割了一茬又长一茬。后来这项目被扫描工具揪出十几个注入点，甲方爸爸的脸都绿了。

还有个细节容易被忽略：错误信息泄露。很多PHP默认配置在SQL执行失败时会打印详细报错，比如You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near '''1'。攻击者看到这个，等于拿到了数据库类型的说明书。关掉display_errors，把日志写进文件里，别让错误信息跑到浏览器上——这算是最便宜的防线了。

说句掏心窝的话，PHP注入攻击之所以泛滥，不是技术门槛高，而是懒。懒得分清楚输入和指令，懒得用预处理，懒得关报错。可现实就是，你省下的那几分钟，攻击者可能用几秒钟就撬开了你的数据库大门。别等数据被拖库了，才对着日志里的SQL语句发呆。