子查询注入比单层or 1=1更难防御，因其常藏于合法语法内部（如where id=(select...)），易绕过关键词过滤；waf难以区分业务子查询与恶意子查询；参数化若未覆盖嵌套拼接点、错误信息泄露结构信息，均加剧风险。
子查询本身不是漏洞，但当它出现在用户可控的拼接位置时，会放大SQL注入的破坏力。根本原因在于：子查询让攻击者能绕过简单过滤、构造多层逻辑判断，并直接探测数据库结构。
子查询注入为什么比单层 OR 1=1 更难防御
很多系统会拦截明显的关键字（如 UNION、SELECT、FROM），但子查询常藏在合法语法内部，比如 WHERE id = (SELECT ...) 这类结构本就正常存在。防火墙或WAF很难区分「业务需要的子查询」和「攻击者注入的子查询」。
- 过滤规则通常基于关键词匹配，而子查询中的
SELECT出现在括号内，容易被漏放 - 参数化查询若只对最外层变量做绑定，嵌套部分仍可能拼接字符串（例如用字符串模板生成子查询）
- 报错信息里返回的子查询执行结果，常暴露表名、列名甚至数据内容，比单纯报错更有价值
典型可利用场景：WHERE 条件中允许子查询拼接
假设后端代码类似：SELECT * FROM orders WHERE user_id = ? AND status IN (SELECT status FROM config WHERE type = 'valid')，但实际实现却是："... WHERE user_id = '" + uid + "' AND status IN (" + subQuery + ")" —— 此时 subQuery 若来自用户输入（如URL参数 ?subquery=SELECT%20status%20FROM%20secrets），就直接构成注入点。
- 攻击者可注入
(SELECT password FROM users WHERE id=1)，把敏感字段带入主查询条件 - 配合
AND (SELECT COUNT(*) FROM admin_users)>0判断管理员表是否存在 - 用
(SELECT BENCHMARK(1000000,MD5(1)))触发时间盲注，绕过无回显环境
MySQL 和 PostgreSQL 对子查询注入的响应差异
不同数据库对非法子查询的报错粒度不同，这直接影响攻击效率：
- MySQL 在子查询返回多行时抛出
Subquery returns more than 1 row，攻击者可借此枚举表结构 - PostgreSQL 对类型不匹配更严格，比如
(SELECT username FROM users)放进WHERE id = (...)会报more than one row returned by a subquery used as an expression，同样可用于布尔盲注 - SQL Server 允许
TOP 1强制单行，让攻击者更容易控制子查询输出格式
真正危险的不是子查询语法，而是动态拼接逻辑
只要代码里出现类似 "WHERE x = (" + getUserInput() + ")" 或模板引擎未关闭表达式求值（如Thymeleaf中误用 ${param.subq}），子查询就天然成为高危载体。ORM 框架如 MyBatis 的 <script></script> 标签、JPA 的原生查询拼接、甚至某些 DSL 构建器，都可能无意中打开这个口子。
- 别依赖「子查询看起来很高级所以应该安全」——它只是攻击面更深的拼接入口
- 参数化必须覆盖所有用户输入点，包括那些被当作「子查询片段」传入的地方
- 生产环境禁用数据库错误详情返回，否则
Unknown column 'xxx' in 'field list'这类提示就是攻击者的地图
子查询注入的隐蔽性，往往体现在开发人员以为“只拼接了值”，却没意识到拼进去的是能执行任意查询的完整SQL片段。
