参数移除所有单引号后包裹单引号拼接SQL，是否存在SQL注入风险？

• 仅针对你给出的这段固定代码，在绝大多数常规配置的数据库环境下，确实很难成功触发SQL注入
  原因是你先移除了用户输入中所有的半角单引号，再用硬编码的单引号将处理后的内容包裹为SQL字符串值，用户无法输入半角单引号提前闭合字符串上下文，所有输入内容都会被识别为NAME字段的取值，不会被解析为SQL执行逻辑。比如常见注入载荷' OR 1=1--经过单引号移除处理后会变为 OR 1=1--，最终拼接生成的SQL为INSERT INTO USER (NAME) VALUES (' OR 1=1--')，仅会将OR 1=1--作为用户名存入数据库，不会产生注入危害。

• 该方案绝非通用安全方案，存在大量边缘场景的绕过可能，绝对禁止用于生产环境
  可触发风险的典型场景包括：

  1. 全角符号绕过：如果你的替换逻辑仅处理半角单引号'，未匹配全角单引号’，部分数据库在特定本地化、字符集配置下会将全角单引号识别为字符串边界符，攻击者输入全角单引号即可闭合字符串上下文构造注入。
  2. 字符编码不匹配绕过：如果服务端的字符编码和数据库连接使用的字符集不一致（比如服务端用UTF-8处理输入，数据库连接默认使用GBK编码且未显式指定编码配置），攻击者可以构造特殊编码的单引号，在服务端替换阶段不会被识别为半角单引号，进入数据库后才被解析为单引号完成闭合，触发宽字节注入等问题。
  3. 业务迭代引入风险：如果后续业务逻辑调整，比如该参数改为拼接到数值字段上下文（不需要用单引号包裹）、SQL拼接位置变化、或者改用其他字符串包裹符，仅删除单引号的防护逻辑会直接完全失效。
  4. 特殊数据库方言绕过：部分数据库支持自定义字符串分隔符（比如PostgreSQL的$$字符串包裹语法），在适配特殊方言的SQL上下文中，无需单引号也可能构造注入，仅删除单引号的防护完全无效。

提示：无论何种业务场景，预编译语句（Prepared Statement）都是防护SQL注入的最优解，通过SQL逻辑和参数完全分离的机制从根源避免注入风险，不要尝试使用任何自行实现的字符过滤/替换方案替代预编译。

内容的提问来源于stack exchange，提问作者Simone Lungarella