php mysql 注入危害大吗？真实案例告诉你怎么避免踩坑！

发布日期： 2025-10-22 阅读量： 作者： admin

今天就来聊聊我捣鼓 PHP 和 MySQL 注入这事儿的经历，算是自己动手实践的一个记录。

起因是前段时间翻看自己以前写的一些老旧 PHP 项目代码。那时候图方便，很多地方从网页接收到用户输入，比如搜索关键词，用户登录的账号密码，都没怎么仔细处理，就直接拼到 SQL 查询语句里头去了。类似 `SELECT FROM users WHERE username = '$username'` 这种写法，当时觉得能跑就行，没想太多。

发现问题，有点后怕

现在回头看，真是捏了把汗。我看到网上很多人都在讲 SQL 注入的风险，说攻击的人可以通过输入一些特殊构造的字符串，像什么 `' OR '1'='1` 之类的，就能绕过验证，甚至拿到数据库里的敏感数据，或者干脆把数据给删了。这可不是闹着玩的。

我就想，我那些老代码会不会也有这个问题？得亲自试试才知道。

动手实践，模拟注入

于是我就找了个测试环境，把我那段有问题的登录代码跑起来。然后在用户名输入框里，没输正经用户名，而是试着输了类似 `admin' OR '1'='1' -- ` 这样的东西。这个 `-- ` 在 SQL 里是注释符，后面的密码判断就被忽略了。

你猜怎么着？ 居然真的登录成功了！当时心里咯噔一下，后背有点发凉。这意味着，如果这段代码真在线上跑，那真是门户大开，谁都能轻易混进来。我又试了试其他的注入语句，发现也能查到一些不该看到的数据。

寻找解决办法

这下不敢怠慢了，赶紧找解决办法。一开始看到有人说用 `addslashes()` 函数，就是给一些特殊字符比如单引号、双引号、反斜杠前面加上一个反斜杠，让数据库把它们当成普通字符，而不是 SQL 命令的一部分。试了一下，对于刚才那种简单的 `' OR '1'='1` 好像是管用了。

但后来查了更多资料，发现 `addslashes()` 也不是万能的，特别是碰到一些复杂的编码问题，比如 GBK 中文编码的时候，还是有被绕过的风险。感觉这招不够彻底，治标不治本。

改用更靠谱的方式

继续研究，发现现在大家普遍推荐用的是预处理语句（Prepared Statements）。不管是通过 PDO 还是 MySQLi 这两种 PHP 操作数据库的方式，都支持这玩意儿。

它的思路是这样的：

先把 SQL 语句的模板写变量部分用占位符（比如 `?` 或者 `:name`）代替。
然后告诉数据库：“这是我的 SQL 命令模板，你先编译一下”。
再把用户输入的数据，作为参数传递给这个编译好的模板去执行。

这样一来，数据库就能很清楚地区分哪个是 SQL 命令结构，哪个是用户输入的数据。用户输入的数据永远只会被当成数据来处理，就算输入了 `' OR '1'='1` 这种东西，数据库也只会把它当成一个普通的、包含特殊字符的字符串去查询，而不会把它当成 SQL 命令执行。这就从根本上杜绝了注入的可能。

重构代码与再次测试

明白了原理，我就开始动手改代码。把原来那些直接拼接字符串生成 SQL 的地方，全部换成了使用 PDO 的预处理方式。比如登录验证，就改成类似这样：

先准备 SQL 模板： `SELECT FROM users WHERE username = ?`

然后绑定参数：把用户输入的 `$username` 绑定到那个问号 `?` 上。

执行查询。

改起来确实比原来直接拼字符串要稍微麻烦一点，代码量也多了几行。但是改完之后，心里踏实多了。

为了验证效果，我又把之前试过的那些注入语句，挨个在新的代码上试了一遍。结果非常好，所有的注入尝试都失败了。要么是登录不了，要么是查询不到任何结果，反正就是没法再像之前那样搞破坏了。这下才算是松了口气。

一点体会

经过这回自己动手实践，最大的感受就是，写代码，特别是涉及到数据库操作和用户输入的，安全这根弦必须时刻绷紧。不能图一时省事就直接拼接 SQL，风险太大了。使用预处理语句是目前看来最靠谱、最推荐的方法，虽然写起来稍微多几步，但能换来安全，绝对值得。这算是我这回折腾的一个小分享出来给大家提个醒。

上一篇: 如何撰写一份高质量的商业银行调查报告？看这里！

下一篇: 免费推广去哪里？这些技巧帮你提升品牌曝光！

php mysql 注入危害大吗？真实案例告诉你怎么避免踩坑！

随便看看