已做特殊字符转义，登录代码仍会遭SQL注入吗？如何防护

当前转义机制的潜在漏洞 #

你手动制定的转义规则看似能处理单引号、双引号和反斜杠，但这类手动实现的转义逻辑很容易因编码差异、数据库特性或规则遗漏留下安全隐患，以下是攻击者可能利用的场景和payload：

1. 宽字节注入（针对GBK等宽字节编码数据库） #

如果你的数据库使用GBK、GB2312这类宽字节编码，攻击者可利用多字节字符吃掉转义符。比如输入：

test@test.com%df%27 OR 1=1-- 

当代码对单引号转义为\'（即%5c%27）后，%df%5c会被GBK编码解析为一个合法汉字，原本的单引号（%27）被保留，从而闭合SQL语句中的引号，执行后续恶意条件。

2. UTF-8多字节编码绕过 #

部分老旧转义函数处理UTF-8多字节字符时会出错，攻击者可构造类似%bf%27的payload，转义后可能变成%bf%5c%27，某些场景下该组合不会被正确解析，导致单引号逃逸。

3. 二次注入攻击 #

如果用户输入的内容（比如注册时的邮箱）被直接存入数据库，后续在登录或其他场景取出并拼接到SQL语句时未重新转义，就会触发二次注入。比如攻击者注册邮箱时输入：

test@test.com%df%27

当这个值被取出用于登录验证的SQL拼接时，会触发和宽字节注入一样的效果。

4. LIKE语句通配符滥用（间接信息泄露） #

虽然不算严格的注入，但如果不对LIKE语句中的%、_转义，攻击者可输入test%匹配所有以test开头的邮箱，逐步枚举系统内用户信息，为后续攻击铺路。

有效的防护方案 #

手动转义永远不是最优解，推荐采用以下标准防护手段：

• 使用预编译语句（Prepared Statements）：这是防御SQL注入的黄金方案。将SQL结构和参数完全分离，数据库会自动安全处理参数，避免拼接带来的风险。比如PHP中用PDO的prepare/execute，Java中用PreparedStatement。
• 依赖数据库官方转义函数：如果无法使用预编译，务必用数据库提供的原生转义函数（如MySQL的mysqli_real_escape_string()），不要手动编写转义规则，这类函数会适配数据库的编码和语法规则。
• 严格校验输入格式：邮箱和手机号有明确格式规范，用正则表达式做严格校验（比如邮箱匹配^[a-zA-Z0-9._%+-]+@[a-zA-Z0-9.-]+\.[a-zA-Z]{2,}$，手机号匹配国内号段规则），直接过滤不符合格式的输入。
• 限制数据库用户权限：给连接数据库的应用账号分配最小必要权限，比如只允许执行SELECT查询，禁止DROP、INSERT、UPDATE等高危操作，即使被注入也能降低危害。
• 处理LIKE语句的通配符：如果业务需要用LIKE做模糊查询，必须对用户输入中的%和_转义（比如将%替换为\%，_替换为\_），防止攻击者利用通配符枚举数据。

内容的提问来源于stack exchange，提问作者L. Gahan