正则校验表schema与名称能否防范动态拼接SQL的SQL注入风险？

• 你给出的校验逻辑在修正正则小问题后，完全可以防范SQL注入，不存在可绕过的注入场景
• 没有注入payload可以绕过你使用的严格全匹配正则，前提是你正确实现了全匹配校验，没有只做部分匹配

1. 现有正则的小问题修正 #

你当前使用的正则^myschema\.[a-zA-Z0-9-_]+$中，字符组内的-位置不合理，部分正则引擎会将9-_识别为ASCII码范围匹配而非普通的横杠字符，建议调整为：
^myschema\.[a-zA-Z0-9_-]+$
把-放到字符组的末尾，即可确保仅匹配你预期的a-z、A-Z、0-9、_、-字符，不会出现异常匹配。

2. 为什么这个校验可以防注入 #

SQL注入的核心是让数据库把用户输入的内容解析为SQL指令的一部分，而非普通的查询参数/标识符。要实现这一点，注入payload必须包含'、"、;、空格、--、/*、)等特殊字符，而你的正则严格限制了仅允许字母、数字、下划线、横杠，加上固定的myschema.前缀，完全排除了所有可用于构造注入的特殊字符，因此不存在注入风险。

注意必须确保正则是全匹配校验（即你用到的^和$必须保留，不能去掉做部分内容匹配），否则可能出现输入前缀符合规则、后缀带注入内容的绕过场景。

3. 额外的加固建议 #

如果要进一步提升安全性，可以叠加以下两个低成本的防护措施，不需要改动你的动态表名逻辑：

• 拼接SQL时给表名加对应数据库的标识符包裹符：MySQL用反引号，PostgreSQL/Oracle用双引号，示例如下：

  sql = "SELECT * FROM `<<TABLE_NAME>>`;"; // MySQL示例
  

  就算出现极端的校验绕过场景，包裹符也会把整个输入识别为表名，不会解析为SQL指令，同时还能解决表名包含-时触发的SQL语法错误问题。
• 给该API使用的数据库账号配置最小权限：仅开放myschema下所有表的SELECT权限，禁止增删改、禁止访问其他schema、禁止执行存储过程等操作，就算出现最坏情况也不会产生严重的数据安全问题。

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