全文检索字段是高危注入点，因其语法（如MATCH...AGAINST、to_tsquery）不支持参数化，须拼接用户输入；单引号、布尔符（+、-）、括号等易被用于闭合上下文或构造恶意逻辑，且传统转义无效，必须依赖白名单过滤或模式限制。
全文检索字段为什么是高危注入点
因为全文检索（FULLTEXT、MATCH ... AGAINST、CONTAINS、CONTAINSTABLE）的语法本身不支持参数化，数据库要求搜索关键词必须是字符串字面量或变量，但多数 ORM 和框架对这类语句不做自动预编译处理。比如 MySQL 的 MATCH(title, content) AGAINST('xxx' IN NATURAL LANGUAGE MODE) 中的 'xxx' 部分，如果用字符串拼接构造，单引号、括号、+ 号、@ 符号都可能被用来逃逸上下文或触发布尔逻辑。
MySQL FULLTEXT 查询的典型拼接陷阱
常见错误写法是把用户输入直接塞进 AGAINST() 里：
sql
-- 危险！用户输入未过滤
SELECT * FROM articles WHERE MATCH(title, content) AGAINST('$_GET[query]' IN NATURAL LANGUAGE MODE);
攻击者输入 test') OR 1=1 -- ，拼接后变成：
sql
... AGAINST('test') OR 1=1 -- ' IN NATURAL LANGUAGE MODE)
这会提前闭合引号和括号，注入任意条件。更隐蔽的是利用 +、-、>、< 等全文操作符干扰排序或绕过限制。
-
AGAINST内部不接受占位符（?或%s），PDO/MyBatis 等默认不会拦截它 - MySQL 对
AGAINST参数只做轻量解析，不校验 SQL 结构，因此拼接后仍能通过语法检查 - 很多开发者误以为“没用 WHERE 就安全”，但
MATCH...AGAINST本身就是 WHERE 子句的一部分
PostgreSQL tsvector/tsquery 场景下的盲注风险
PostgreSQL 全文检索依赖 to_tsvector 和 to_tsquery，而 to_tsquery 支持 &、|、!、: 等操作符——这些符号在未过滤时可被用于布尔盲注。例如：
sql
-- 用户输入被拼入 to_tsquery
SELECT * FROM docs WHERE doc_tsv @@ to_tsquery('english', 'user_input');
若输入为 hello & (SELECT 1 FROM pg_user WHERE username = current_user AND substr(password,1,1)='m')，配合响应时间差异，就能逐字符猜解密码哈希。
-
to_tsquery不接受参数绑定，pg_query_params对其内部字符串无效 - 报错注入也常见：输入
''::tsquery或非法语法会触发ERROR: syntax error in tsquery，泄露表结构 - 即使开启
log_min_error_statement，错误日志也可能暴露字段名
真正可用的防护手段不是“转义”，而是隔离与白名单
对全文检索字段，addslashes、mysql_real_escape_string 或正则替换单引号完全无效——因为 AGAINST 和 to_tsquery 解析逻辑与普通字符串不同，且操作符本身就有语义。
- 强制使用
IN NATURAL LANGUAGE MODE（MySQL），禁用IN BOOLEAN MODE，后者允许+/-注入逻辑 - 对搜索词做严格字符白名单：仅保留中文、ASCII 字母、数字、空格、短横线（
-）、下划线（_），其余一律截断或拒绝 - 如需支持布尔语法，必须自行解析输入（如用
preg_match('/^[a-zA-Z0-9\u4e00-\u9fa5\s\+\-\*\>\），再映射为安全的内部 DSL - 业务层统一收口：所有全文查询走一个封装函数，禁止任何直接拼接
AGAINST或to_tsquery的代码路径
最常被忽略的一点：即使用了参数化查询，只要最终 SQL 字符串里出现了用户输入拼接进 AGAINST 或 to_tsquery，就等于把防火墙开了一扇没锁的窗。防护的关键不在“怎么拼”，而在“不让它拼”。
