双层解析上下文混用导致SQL与Elasticsearch DSL叠加注入风险，核心解法是切断数据与指令耦合：禁止用户提交原始SQL，改用白名单字段/操作符的结构化参数，并禁用elasticsearch-sql等非生产级插件。
直接拼接 SQL 查询字符串 + 转发到 Elasticsearch（比如用 elasticsearch-sql 插件、elasticsearh-painless 中调用 JDBC、或自建桥接服务）时，若用户输入未经处理就进入 SQL 模板，会同时触发 SQL 注入和 Elasticsearch 查询 DSL 注入——这不是“跨源注入”的标准术语，而是**双层解析上下文混用导致的叠加风险**。核心解法不是加一层过滤，而是彻底切断数据与指令的耦合路径。
为什么不能只靠 SQL 参数化？
参数化查询（如 PreparedStatement）只保护数据库端，对 Elasticsearch 无效。例如你用 Java 写了：
String sql = "SELECT * FROM my_index WHERE title = ? AND status = ?"; PreparedStatement stmt = conn.prepareStatement(sql);
这能防 MySQL 注入，但如果你的底层是通过 Elasticsearch 的 _sql REST 接口执行该语句（比如用 elasticsearch-sql 插件），而该插件本身未做参数绑定，那 ? 占位符可能被插件错误地字符串替换——此时恶意输入仍会进入 DSL 解析器，触发布尔盲注或字段名遍历。
- 常见错误：以为用了
PreparedStatement就万事大吉，忽略中间桥接层是否真正支持参数透传 - Elasticsearch 官方
_sql接口（7.12+）已废弃，第三方插件如sql-jdbc-driver或es-sql对参数支持不一致，部分版本仅支持位置占位符，不支持命名参数 - 若桥接服务自己拼接
POST /_sql请求体，且把用户输入直接塞进 JSON body 的query字段，等同于手动构造 DSL，完全暴露
必须隔离 SQL 输入与 Elasticsearch 查询构造
真正的防线在桥接层：SQL 查询语义应由服务端定义，用户只能提供约束值，不能影响字段名、操作符、嵌套结构。
- 禁止用户提交原始 SQL 字符串；改用结构化参数，例如：
{"filter": {"field": "status", "value": "active", "op": "eq"}} - 字段名（
field）、操作符（op）必须来自白名单枚举，不可由用户自由输入 - 值（
value）才允许动态传入，并经JSON.stringify()或TermsQueryBuilder等安全 API 绑定，避免手写 JSON - 若必须支持类 SQL 语法（如 Kibana 的 Lens 或
search bar），启用 Elasticsearch 内置的kuery或lucene查询解析器，它们默认不执行脚本、不开放_msearch堆叠、且可配script.allowed_types: none
绕过桥接层直连时的硬性限制
如果前端或中间件绕过业务逻辑，直接调用 Elasticsearch 的 _search 接口并拼接 DSL，那任何 SQL 防护都失效。此时必须依赖 Elasticsearch 自身安全机制：
- 禁用高危 API：
PUT /_cluster/settings、POST /_scripts/、GET /_cat/*，在角色权限中显式deny - 关闭脚本执行：
script.allowed_types: none（Elasticsearch 8.x 默认已关） - 限制查询深度与大小：
index.max_result_window: 10000、search.max_buckets: 10000，防聚合爆破 - 绝不使用
source过滤器返回全部字段（"_source": true），而应明确指定白名单字段，避免泄露password_hash或api_key类敏感字段
最易被忽略的一点：很多团队在测试环境用 elasticsearch-sql 插件快速验证，上线后忘记移除——该插件默认开放 POST /_sql，且不校验用户身份，只要网络可达就能执行任意查询。它不是生产级组件，也不受 Elasticsearch RBAC 控制。真要联动 SQL 语义，请用官方支持的 data streams + rollup + transforms 替代，或走 Logstash JDBC input + Elasticsearch output 的离线同步路径。
