addslashes() 为什么不能防止 SQL 注入?
addslashes() 无法防止 sql 注入,因为它仅执行简单的字符替换,不感知数据库的字符集和上下文。它会在单引号前添加反斜杠,但如果数据库使用 gbk 等多字节编码,攻击者可以利用宽字节特性绕过转义,导致注入发生。

GBK 宽字节注入的具体原理是什么?
在 GBK 编码下,addslashes()对 ' 转义为 '。如果后端连接数据库时未强制指定 UTF-8,而是使用默认的 GBK,MySQL 会将 %df%27(即 ï')解析为一个多字节字符 運,而前面的 %5c(反斜杠)被吞掉,使得单引号重新生效,从而闭合查询语句。

如何验证 addslashes() 在不同编码下的行为差异?
通过构造特定的输入 payload,可以观察到在不同字符集配置下,addslashes() 的输出是否会被数据库正确解析。以下代码演示了如何在 PHP 中模拟这一过程,并展示即使使用了转义函数,若编码不匹配,注入依然可能成功。
<?php // 模拟 GBK 环境下的宽字节注入 $input = "%df%27"; // URL encoded: ï' $raw_input = urldecode($input); echo "原始输入: " . $raw_input . " "; $escaped = addslashes($raw_input); echo "转义后: " . $escaped . " "; // 在 GBK 编码下,\ 和 ' 可能被合并为一个非法字符,导致 ' 逃逸 // 实际数据库中,如果 charset 是 gbk,这个 ' 仍然有效 echo "SQL 片段: WHERE name = '" . $escaped . "' "; ?>
php免费学习视频:立即使用
踏上前端学习之旅,开启通往精通之路!从前端基础到项目实战,循序渐进,一步一个脚印,迈向巅峰!











