magic_quotes_gpc对数字型参数无效，因其仅转义字符串中的引号，而id=1 OR 1=1等注入不带引号；宽字节编码（如GBK）可绕过转义；多语句和注释符不受其影响；PHP 5.4+已移除该机制，应改用预处理语句。
magic_quotes_gpc 为什么对数字型参数完全无效
它只在字符串上下文中起作用，而 id=1 OR 1=1 这类注入不带引号，magic_quotes_gpc 根本不会触发——因为没遇到单引号、双引号或反斜杠。
常见错误现象：后台用 $_GET['id'] 拼接 SQL 时没加引号，比如：SELECT * FROM users WHERE id = $_GET['id']。攻击者传 id=1 OR 1=1，数据库直接执行逻辑运算，和转义无关。
- 必须手动用
intval()或类型强制转换（如(int)$_GET['id']）约束输入为整数 - 即便用了
intval()，也要注意返回值是否为 0（比如传id=abc会变成 0），需额外校验业务合理性 - MySQL 支持
CHAR()、0x十六进制写法，例如id=CHAR(49,32,79,82,32,49,61,49)可绕过数字校验
宽字节编码如何让 magic_quotes_gpc 彻底失效
当 MySQL 连接字符集设为 gbk，而 PHP 层用 addslashes()（magic_quotes_gpc 的底层行为）处理时，攻击者可构造 %df%27：前半字节 %df 和后半字节 %27（即单引号）拼成一个合法 GBK 字符「運」，导致 \ 被“吃掉”，真正的单引号裸露出来。
典型场景：PHP + MySQL + SET NAMES gbk，且未显式设置连接层字符集（如 mysqli_set_charset($conn, 'utf8mb4')）。
- 修复方式不是禁用 gbk，而是统一使用
utf8mb4并在连接建立后立刻调用set_charset -
mysql_real_escape_string()能规避此问题，但它依赖有效数据库连接，且已废弃；现代应优先用PDO::prepare() - 仅靠
iconv()或mb_convert_encoding()做编码转换不能替代连接层 charset 设置
多语句与注释符让转义完全失去意义
magic_quotes_gpc 不处理分号 ;、括号 ( )、注释符 --、#、/* */ —— 它们不是字符串内容，而是 SQL 语法符号。
当后端启用 mysqli_multi_query() 或允许堆叠查询时，攻击者可直接执行：1; DROP TABLE users; --。此时无论单引号是否被转义，第二条语句已送入执行队列。
- 检查代码中是否出现
mysqli_multi_query()、pg_query()（PostgreSQL 默认支持多语句）等高危调用 - MySQLi 默认关闭多语句，但 PDO 需显式禁用：
new PDO($dsn, $user, $pass, [PDO::ATTR_EMULATE_PREPARES => false]) -
--后面必须跟空格才能被识别为注释，--foo在某些版本下不生效，但#和/* */更稳定，不可依赖格式细节来防御
现代 PHP 环境里 magic_quotes_gpc 已经不存在
PHP 5.4.0 起彻底移除该配置项，php.ini 中写 magic_quotes_gpc=On 会被忽略，get_magic_quotes_gpc() 返回 null 或报错。任何还在提“开启魔术引号防注入”的方案，本质是拿十年前的补丁当盾牌。
遗留系统迁移时常见坑：旧代码里混用 stripslashes() 清洗输入，结果在 PHP7+ 下把正常数据里的反斜杠删掉，造成路径、JSON、正则等逻辑异常。
- 若必须兼容老代码，应在入口处统一判断：
if (function_exists('get_magic_quotes_gpc') && get_magic_quotes_gpc()) { ... } - 更稳妥的做法是直接删除所有
stripslashes()调用，并确保后续逻辑不依赖“已被转义”的假设 - 框架如 Laravel、Symfony 从不读取
magic_quotes_gpc，它们默认信任开发者使用预处理或 ORM 参数绑定
真正关键的不是“怎么绕过转义”，而是“为什么还要拼接 SQL”。只要还手写 "SELECT * FROM $table WHERE $col = '$_POST[val]'" 这类字符串，就等于把解析权交给了攻击者。预处理语句的 prepare() + bind_param() 是唯一能从机制上切断数据与代码混合的方案——它不靠 PHP 层修补，而是让数据库引擎自己划清边界。
