SQL注入为何始终是OWASP Top 10核心漏洞

SQL注入在OWASP Top 10中长期占据一席之地，背后有个残忍的真相：开发者惯性拼接语句，攻击者总能找到过滤盲区。

先说几个核心判断：预处理语句本身没问题，但落地时经常认错了“敌人”。

预处理语句为什么没拦住所有注入

预处理（PDO::prepare、PreparedStatement、sqlite3.execute()带参数调用）的机制是安全的，问题在于开发者只把它用在“显眼”位置：

• 登录和搜索用了参数化，但导出报表的ORDER BY字段仍然用"ORDER BY " + user_input直接拼接
• Django里写了raw()，Flask-SQLAlchemy用了text()，等于退回字符串拼接的老路
• 把htmlspecialchars()或strip_tags()当SQL防护——它们专防XSS，对SQL注入完全无效，这是典型的武器错配

哪些地方预处理根本不起作用

数据库语法决定了某些位置无法参数化，硬上?会直接报错，必须换个思路：

• ORDER BY ?、GROUP BY ?：MySQL和PostgreSQL都不支持参数化排序字段，这是语法层面的限制
• IN (?, ?, ?)：问号数量必须提前确定，动态列表只能靠构建占位符字符串实现
• 表名、列名、数据库名：SELECT * FROM ?不合法，必须用白名单校验或正则匹配才能通过
• LOAD DATA INFILE中的文件路径、COPY FROM PROGRAM中的命令参数：这些不是查询数据，而是执行动作，预处理根本覆盖不到

新型绕过技术专打“合法语法”边界

传统WAF拦截'、--、#之后，攻击者转向解析器本身的歧义点：

• MySQL嵌套注释：admin' /* foo */ OR /* bar */ '1'='1，旧版WAF识别不了这种结构
• 关键词拆解：UNI/**/ON SEL/**/ECT可绕过关键词检测
• 十六进制编码：0x554e494f4e（UNION）躲过正则匹配
• JSON字段注入：data->>'name' || '1'='1，->>操作符若未参数化，一旦拼接就中招

最麻烦的是非标准上下文注入点

SQL注入早已不止于WHERE条件。这些场景难统一防护，且常被安全扫描忽略：

• PostgreSQL的COPY FROM PROGRAM('id')，program参数可控 = 直接执行系统命令
• Oracle的UTL_HTTP.REQUEST()，拼接URL参数 = SSRF + 二次注入
• 动态视图创建：CREATE VIEW v AS SELECT * FROM + user_input，表名没白名单 = 跨库引用
• MyBatis的${}语法用于动态表名——它不走预编译，等同于String.format

每个数据库方言、ORM的“例外通道”、为兼容老代码做的临时妥协，都在悄悄扩大攻击面。防御必须跟着上下文走，而不是只盯着SELECT ... WHERE这一行。