Base64编码不能防御SQL注入，它仅是传输层编码，解码后原始恶意SQL仍会执行；必须依赖参数化查询、最小权限原则等真正安全机制。
Base64编码本身不改变SQL语义，只是传输层伪装
Base64不是安全机制，它只是把字节序列转成ASCII可打印字符，解码后内容完全还原。数据库执行时看到的仍是原始SQL片段——如果应用在拼接前没做参数化或过滤，base64_decode($_GET['q']) 吐出来的可能就是 ' OR 1=1 -- 这种东西。
常见错误场景：
- 前端用JS对用户输入做
btoa()，后端PHP直接base64_decode($_POST['data'])再拼进mysql_query("SELECT * FROM user WHERE name = '$name'") - API接口文档写“参数需Base64编码”，结果开发误以为“已防注入”，跳过预处理逻辑
- WAF规则只检查原始请求体，放行了
Ym9yIDE9MQ==（即or 1=1），但后端解码后照常拼接
绕过Base64校验的典型手法
攻击者会利用编码容错性、多层嵌套或服务端实现缺陷来绕过简单校验：
- 末尾填充字符
=被省略或替换为_/-（如某些URL-safe变种），而服务端用宽松解码函数（如Python的base64.urlsafe_b64decode()）仍能成功解析 - 重复编码：传入
YmFzZTY0X2RlY29kZShvciAxPTEp（即base64_decode(or 1=1)），若后端递归解码两次就触发注入 - 混合编码：先URL编码再Base64，如
%27%20OR%201%3D1%20--→JTJ3JTIwT1IlMjAxJTNEMSUyMC0t，绕过只检测ASCII单引号的WAF - 空字节截断：部分旧版
base64_decode()遇到\x00会提前终止，构造admin\x00' OR 1=1 --编码后可能只解出admin，看似“安全”实则埋雷
为什么不能依赖解码后做关键词过滤
解码时机和上下文决定过滤是否有效。如果过滤发生在解码前，Ym9yIDE9MQ==根本不会匹配or；如果过滤在解码后但位置不对，照样失败：
- 过滤函数只扫字符串一级，但SQL注入常藏在JSON字段值里：
{"name": "a' OR 1=1 -- "}→ Base64 → 解码后整个JSON才被json_decode()解析，此时过滤早已错过时机 - 大小写/Unicode混淆：传
b2IgMQoxPTE=（ob 1\n1=1），过滤器若只查小写or就失效；或用全角字符ｏｒ绕过ASCII关键词表 - 正则性能陷阱：对每个Base64参数都跑一遍
preg_match('/(union|select|;)/i', base64_decode($input))，高并发下CPU飙升，还可能被超长编码串拖垮
真正有效的防御组合策略
Base64可以保留（比如用于传输二进制附件），但绝不能把它当防护手段。关键动作必须落在SQL执行前：
- 所有用户可控数据，一律走
prepare()+bind_param()（PHP）或PreparedStatement（Java），让数据库自己区分代码与数据 - 若必须动态拼接（极少数场景），用白名单严格限制可选字段名/操作符，例如
$order = in_array($_GET['sort'], ['id', 'name', 'created_at']) ? $_GET['sort'] : 'id'; - WAF规则要覆盖解码后流量：Nginx+ModSecurity可配置
SecRule REQUEST_BODY_BASE64_DECODED变量；云WAF需开启“深度解码检测”开关 - 日志中记录原始Base64和解码后内容，便于回溯时确认是否真有恶意载荷——很多人只记编码串，查问题时才发现解码后早被篡改
最常被忽略的一点：数据库连接要用最低权限账号，哪怕注入成功，也拿不到information_schema或执行LOAD_FILE()。编码解决不了权限设计缺陷。
