SQL注入最常突破的是参数拼接点，必须使用预编译接口如PreparedStatement；ORM的raw查询、动态表名列名需白名单校验；过滤器仅作辅助告警，不可替代参数化。
SQL注入最常突破的其实是参数拼接点
绝大多数SQL注入不是靠绕过WAF，而是直接把用户输入塞进query字符串里拼接。比如用String.format()拼SELECT * FROM users WHERE name = '%s'，或者用concat()拼MySQL语句——这种写法只要输入含' OR 1=1 -- 就直接沦陷。
实操建议：
- 所有动态值必须走
PreparedStatement（Java）、pg_query_params()（PHP/PgSQL）、sqlite3_prepare_v2()（C/SQLite）这类预编译接口，绝不用execute()或query()直接传拼好的SQL - ORM如Django ORM、Sequelize默认用参数化，但一旦调用
raw()、extra()或text()，就退回高危区，必须人工核对是否用了params参数 - 若必须拼接表名或列名（如动态排序字段），只能白名单校验：
if not field_name in ['created_at', 'status']: raise ValueError
自定义过滤器容易误判合法输入
写个strip_sql_inject()函数把UNIONSELECT;全干掉？这招在真实业务里会崩：用户昵称叫O'Reilly被砍成OReilly，JSON字段含{"type": "SELECT"}直接解析失败，连带前端显示异常。
实操建议：
- 过滤器只做「辅助防御」，不能替代参数化——它顶多是日志告警或临时拦截可疑请求，绝不修改原始参数值
- 正则匹配
SELECT\s+FROM类规则在注释里照样生效（/* SELECT FROM */），反而漏掉真正危险的1; DROP TABLE（分号后执行） - 如果真要用过滤，优先用数据库驱动自带的
escape_string()（如mysqli_real_escape_string()），但注意它只对单引号上下文有效，且必须指定正确字符集
Web层过滤器对预编译无效，但可能干扰调试
在Nginx加mod_security规则拦截UNION SELECT，或在Spring Boot里写个@ControllerAdvice统一扫请求体——这些动作发生在SQL执行前，但它们拦不住已通过参数化的请求，因为UNION根本不会出现在最终SQL字符串里；反而可能把含关键词的正常API请求（如文档搜索select * from docs）当成攻击干掉。
实操建议：
- Web层规则只用于记录和告警，不阻断；重点监控
403响应中是否高频出现sql相关关键词，反向验证应用层防护是否失效 - 避免在Filter里修改
HttpServletRequest的getParameter()返回值——Servlet容器可能缓存原始参数，导致后续Filter或Controller读到不一致数据 - 若用OpenResty写Lua过滤，别用
ngx.req.get_uri_args()直接改参，改用ngx.var.arg_xxx只读访问，确保不污染原始请求流
ORM自动转义不等于绝对安全
Django的filter(name__icontains=user_input)看似安全，但如果user_input是"%admin%"，而数据库用的是LIKE查询，那%就是通配符，不是字面量——这不是注入，但能绕过预期逻辑，查出不该查的数据。
实操建议：
- 所有
LIKE操作必须手动转义通配符：user_input.replace('%', '\%').replace('_', '\_')，并在查询中声明ESCAPE '\' - PostgreSQL的
ILIKE、MySQL的REGEXP等扩展语法，其模式字符串同样需参数化，不能拼接；Django的extra(where=[...])必须用params传参 - 用
jsonb_path_exists()（PostgreSQL）或JSON_CONTAINS()（MySQL）查JSON字段时，路径表达式也得走参数化，否则$[*] ? (@.role == "admin")里的admin仍可能被注入
真正的难点不在“怎么拦”，而在“哪里不能拦”——参数化是唯一可信路径，其余所有过滤、替换、正则，都是给漏网之鱼设的第二道岗，而且得随时防着自己打中友军。
