最麻烦的是多态SQL注入，攻击者通过大小写混用、URL编码、注释绕过、空格替换、函数嵌套等方式逃避检测；防御核心是禁用拼接、强制参数化查询、白名单校验动态部分、语义化格式校验、警惕ORM陷阱、中间件解码标准化及日志脱敏。
SQL注入里最麻烦的其实是多态变形
多态SQL注入不是拼接了' OR 1=1 --就完事——攻击者会用大小写混用、URL编码、注释绕过、空格替换（比如用%09、/**/）、函数嵌套（CONCAT(CHAR(45),CHAR(45))）等方式让特征难以被正则或简单黑名单识别。靠“过滤关键词”基本无效，因为规则越写越长，漏网率反而升高。
实操建议：
- 永远不拼接用户输入到SQL语句中，哪怕你“已经转义过了”——
mysql_real_escape_string这类函数在宽字节、多字节编码场景下有绕过风险 - 优先使用参数化查询：
PreparedStatement（Java）、pg_query_params（PHP/PgSQL）、cursor.execute(sql, params)（Python/psycopg2） - 如果必须动态拼表名/列名（如分表路由、排序字段），只能白名单校验：
if column_name not in ['created_at', 'status', 'user_id']:抛异常 - 避免用
eval()、exec()、format()模板拼SQL字符串——这些是多态注入的温床
格式化校验 ≠ 简单trim + isalnum
只做str.strip().isalnum()看似干净，但对user_id字段，攻击者可传123%00abc（含空字符）、123\x00（截断后续校验）、或超长十六进制编码绕过长度限制。格式校验必须和业务语义强绑定。
实操建议：
- 数字ID：用
int()强转并捕获ValueError，而非正则匹配^\d+$——后者允许00001甚至1e3等非整数形式 - 邮箱：用标准库解析（如Python的
email.utils.parseaddr），而不是re.match(r'.+@.+\..+', s) - 手机号：按国家码+位数双校验，例如中国手机号必须
^1[3-9]\d{9}$且长度严格为11，不能接受+8613xxxxxxxxx后不做归一化直接入库 - 所有校验后必须重赋值，别在原变量上
.replace()——s = s.replace('--', '')无法防-/*-/+这种变形
ORM也不能自动免疫多态注入
很多人以为用了Django ORM或SQLAlchemy就高枕无忧，但Model.objects.extra(where=["name = '%s'" % user_input])、queryset.extra(tables=['user_%s' % shard_id])、或func.concat(User.name, ' ', %s)中把用户输入塞进%s位置，照样触发漏洞。ORM只保证参数化部分安全，不负责帮你管住手写的SQL片段。
实操建议：
- Django里禁用
extra()、raw()、cursor.execute()带格式化字符串的调用；必须用时，只允许传入params元组，且params里每个值都经过前述格式校验 - SQLAlchemy慎用
text()，尤其避免text("SELECT * FROM users WHERE name = :name").bindparams(name=user_input)——这本身安全，但如果user_input是"admin' -- "且你又在日志里明文打印了str(text_obj)，可能泄露上下文 - 自定义数据库函数（如MySQL的
UNHEX()、FROM_BASE64()）若接收用户输入，需先校验输入是否为合法十六进制/Base64字符串，再解码后进参数化流程
WAF和日志里的变形payload容易被忽略
生产环境WAF日志里常看到%2527%2520OR%25201%253D1%2523（即' OR 1=1#的双重URL编码），或SELECT%09*%09FROM%09users（tab代替空格）。这类请求如果只在Nginx层记录而没进应用层校验，就等于漏掉了一次防御机会。
实操建议：
- 在Web框架中间件里做第一道解码+标准化：Python可用
urllib.parse.unquote_plus，但注意多次解码（最多2次），防止%252527绕过 - 所有日志记录前，对敏感字段做脱敏：不是删掉，而是统一替换成
[REDACTED]——否则攻击者故意发畸形payload刷满磁盘，还可能从日志反推你的校验逻辑 - API入口统一用
request.get_json()或request.form取值，别直接读request.environ['QUERY_STRING']——后者未解码，易遗漏变形
真正难防的不是' OR 1=1，而是那个在你校验函数里悄悄多加了一个\u202e（Unicode右向覆盖符）的用户名，它能让前端显示正常，后端正则却完全匹配不上。校验逻辑和显示逻辑用的字符集不一致，才是多态注入藏得最深的地方。
