istio 原生策略无法拦截 sql 注入，因 envoy 不解析 sql 语法和请求体内容；virtualservice 与 authorizationpolicy 均无法检测 payload 中的 sqli 片段。
Istio 本身不能拦截 SQL 注入，别在 VirtualService 或 AuthorizationPolicy 里白费功夫
为什么 Istio 原生策略对 SQLi 完全无效
Envoy 数据面不解析 SQL 语法，也不处理请求体（application/json、application/x-www-form-urlencoded）中的参数内容。它只做 L7 路由、Header 改写、TLS 终止等基础操作。
-
VirtualService的match.uri或headers正则匹配 SELECT/UNION 等关键字 —— 攻击者用 URL 编码（%20OR%20%271%27%3D%271）、大小写混用（SeLeCt）、注释符（/**/UNION/**/SELECT）就能绕过 -
AuthorizationPolicy只校验 JWT 签名和 scope，跟请求体里的 SQL 片段毫无关系 -
PeerAuthentication只管 mTLS 握手，payload 是透明透传的
真正能落地的方案：WasmPlugin + 预编译 SQLi 检测模块
这是目前唯一可在 Istio 数据面实现 SQLi 内容级拦截的生产路径，但有强约束：
- Wasm 模块必须预编译为
wasm32-wasi目标，禁用浮点和动态内存分配（Envoy Wasm 运行时限制） - 仅支持解析 query string 和
application/x-www-form-urlencoded；JSON body 需手动解析（无标准 JSON 库可用） - 检测规则（如
' OR '1'='1、UNION SELECT）必须硬编码进 Wasm，无法热更新；改规则就得重新 build + rollout - 实测延迟增加 0.5–2ms/请求（Envoy 1.28 + Istio 1.21），高 QPS 场景需压测验证
示例配置片段（假设已构建好 sqli-filter.wasm）：
apiVersion: extensions.istio.io/v1alpha1
kind: WasmPlugin
metadata:
name: sqli-filter
namespace: istio-system
spec:
selector:
matchLabels:
istio: ingressgateway
url: file:///var/lib/istio/extensions/sqli-filter.wasm
phase: AUTHN
pluginConfig:
mode: "strict"
更推荐的替代路径：前置 WAF，别强塞进 Istio
SQLi 是典型 Web 层攻击，交给专业 WAF 处理更可靠、更灵活：
- Azure AKS 推荐在入口层前部署
Azure Web Application Firewall（配合 Application Gateway），启用 OWASP CRS 规则集 - 自建集群可部署
NGINX Plus（带 ModSecurity）或Pipy（轻量、支持 Lua 规则热加载）作为边缘代理 - 云厂商 WAF（如 AWS WAF、阿里云 WAF）提供托管规则+自定义规则能力，且与 Istio 无耦合，升级/调试互不影响
关键点是：确保所有流量必须经过 WAF，禁止客户端直连 Istio ingressgateway —— 否则绕过 WAF 就等于裸奔。
硬要在 Istio 里加 SQLi 检测，等于让快递分拣站去审每封信的内容；而 WAF 是专门的信件安检机。后者更稳，也更容易调规则、查日志、做误报分析。
