Base64编码本身完全不提供SQL注入防护能力——它仅做字符转换，解码后原始载荷未变；漏洞根源在于解码后未经类型校验或参数化直接拼入SQL语句，唯有参数化查询可彻底防御。
Base64编码本身**完全不提供SQL注入防护能力**——它只是把字节序列转成可打印字符，解码后原始内容一字不变，攻击载荷该执行还是执行。
Base64_decode() 后的字符串仍被拼进SQL语句
常见错误是：服务端收到 id=YW5kIDE9MQ==，调用 base64_decode($_GET['id']) 得到 and 1=1，然后直接拼进 "WHERE id = '$id'"。此时数据库看到的是 WHERE id = 'and 1=1'，单引号仍在，整个字符串仍是字面值，但若上下文是整型却未强转，攻击者可能通过 YW5kIDE9MQ== → and 1=1 → 拼入无引号的整型位置（如 ORDER BY $id），就直接触发语法解析。
- 字符串上下文里加单引号、
--、#都无效，因为它们被包裹在引号内 - 整型上下文里没加引号，且未用
intval()或(int)强制转换，base64_decode()后的1 OR 1=1就能逃逸 - 关键不在“有没有编码”，而在“解码后的值是否经过参数化或类型校验”
参数化查询才是唯一有效的防线
无论输入是否 Base64 编码，只要最终进数据库那一步用了参数占位符，就安全。例如：
SELECT * FROM users WHERE id = ?
绑定 base64_decode($_GET['id']) 的结果时，数据库引擎不会把它当 SQL 语法解析。
- PHP + PDO：
$stmt->execute([$decoded_id])，不是"WHERE id = '$decoded_id'" - Python + psycopg2：
cursor.execute("SELECT ... WHERE name = %s", (decoded_name,)) - Node.js + mysql2：
connection.execute("SELECT ... WHERE id = ?", [decoded_id]) - ORM 如 Django 默认安全，但一旦调
.extra()或.raw()，防线立刻失效
多重解码和字符集错配会绕过所有过滤
如果代码里存在嵌套解码或自动解码叠加手动解码，攻击者可以用双重编码绕过检查：
- 前端传
%2527（即%27的 URL 编码），PHP$_GET自动解一次得%27，再手动urldecode()得'，但你的str_replace("'", '')只作用于第一次解码后的字符串，对%27完全无效 - Base64 嵌套两次：
btoa(btoa("1' OR 1=1"))，后端若写base64_decode(base64_decode($input))，就直接还原出恶意 payload - MySQL 连接字符集设为
latin1，但传输 UTF-8 字节流，某些无效序列（如%C0%BC）会被解释成特殊字符，绕过基于 UTF-8 的 WAF 规则
真正危险的从来不是 Base64 本身，而是把它当成“已消毒”的信号——解码后的字符串，必须当作完全不可信的原始输入，只允许走参数化路径进入 SQL。任何中间环节（日志、缓存键、二次拼接）引入非参数化使用，都等于开门揖盗。
