防止SQL注入的数据库中间件MyCat参数拦截功能

MyCat作为一款开源的分布式数据库中间件，在读写分离、分库分表场景下应用广泛。但在安全防护层面，多数人只关注其路由功能，忽略了它内置的参数拦截能力。这套机制本质上就是一套SQL防火墙，能在恶意请求到达数据库之前完成拦截，从源头防止SQL注入攻击。下面直接拆解MyCat参数拦截功能的具体实现和配置方法。

MyCat的参数拦截功能基于拦截器链实现，在SQL语句被解析后、路由分发前执行。当客户端发送SQL请求时，MyCat会先通过SQL解析器将语句拆解为语法树，然后依次调用配置好的拦截器。参数拦截器会检查SQL中的参数值是否匹配预设的危险规则，一旦命中就立即阻断请求，返回错误信息给客户端，根本不会让恶意SQL抵达后端数据库。这套机制的优势在于与业务代码完全解耦，不需要修改任何应用层逻辑，只需在MyCat配置文件中定义规则即可生效。

拦截器的执行时机非常关键。MyCat在接收到SQL后，会先做简单的语法校验，然后进入拦截器链。参数拦截器通常配置在拦截器链的前端，确保在SQL被改写和路由之前就完成安全检查。这样做有两个好处：一是减少不必要的计算开销，二是避免恶意SQL在改写过程中被变形绕过。拦截器链的执行是串行的，任何一个拦截器返回false都会导致整个请求被拒绝。

在MyCat的server.xml文件中，通过system标签下的配置项开启参数拦截功能。核心配置如下：

<system>
    <property name="usingAIO">0</property>
    <property name="useSqlInterceptor">true</property>
</system>

这个开关只是启用了拦截器框架，真正的拦截规则需要在具体的拦截器配置文件中定义。MyCat默认提供了多种拦截器实现，参数拦截器对应的类是com.mycat.server.interceptor.impl.DefaultSqlInterceptor，你也可以基于接口开发自定义拦截器。在server.xml中继续配置拦截器引用：

<system>
    <property name="sqlInterceptor">com.mycat.server.interceptor.impl.DefaultSqlInterceptor</property>
    <property name="sqlInterceptorFile">/opt/mycat/conf/sql_interceptor.txt</property>
</system>

sqlInterceptorFile指向的文件就是存放拦截规则的地方，每一行代表一条规则，MyCat启动时会加载该文件到内存中，形成规则匹配树。规则文件的格式采用正则表达式，支持对参数值、表名、字段名等多个维度进行匹配。

拦截规则的设计直接决定了防护效果和误杀率。规则文件每行一条，格式为“匹配类型:正则表达式”。常见的匹配类型包括param（参数值）、table（表名）、column（列名）、keyword（关键字）等。以下是一些实战中验证过的高效规则：

# 拦截包含UNION查询的参数
param:(?i)\bunion\b.*\bselect\b

# 拦截注释符号，防止注释绕过
param:/\*.*\*/

# 拦截系统表访问
table:(?i)\b(information_schema|mysql|sys|performance_schema)\b

# 拦截危险函数调用
param:(?i)\b(load_file|into\s+outfile|benchmark|sleep)\s*\(

# 拦截逻辑运算符异常使用
param:(?i)\b(or|and)\b\s+\d+\s*=\s*\d+

# 拦截堆叠查询
param:;

规则编写有几个关键技巧。第一，使用(?i)标志开启大小写不敏感匹配，因为SQL注入攻击经常通过大小写变换来绕过检测。第二，对于多语句攻击，直接拦截分号是最简单有效的手段，但要注意如果你的业务确实需要批量执行语句，这条规则需要调整。第三，针对时间盲注的拦截，重点关注sleep、benchmark、pg_sleep等数据库特有函数。第四，规则顺序有讲究，MyCat会按文件中的顺序依次匹配，建议把命中率高、开销小的规则放在前面，提高匹配效率。

还有一个容易被忽略的细节：规则文件中支持空行和注释行（以#开头），合理使用注释可以让规则文件更易维护。当规则数量超过50条时，建议按攻击类型分组并用注释标注，方便后续审计和更新。

单一拦截器往往无法覆盖所有攻击场景，MyCat支持配置多个拦截器形成拦截器链。在server.xml中，sqlInterceptor属性可以配置多个类名，用逗号分隔。执行顺序就是配置顺序，前一个拦截器通过后才会进入下一个。这种设计允许你将通用规则和业务特定规则分离管理。

举个例子，你可以创建一个专门拦截SQL注入的参数拦截器，再创建一个用于审计日志的记录拦截器。参数拦截器负责阻断恶意请求，审计拦截器负责记录所有被放行的SQL语句用于事后分析。两个拦截器各司其职，互不干扰。配置方式如下：

<property name="sqlInterceptor">
    com.mycat.server.interceptor.impl.DefaultSqlInterceptor,
    com.mycat.server.interceptor.impl.AuditLogInterceptor
</property>

自定义拦截器的开发也不复杂，只需要实现SQLInterceptor接口，重写intercept方法即可。在intercept方法中，你可以拿到完整的SQL语句、参数列表、前端连接信息等上下文数据，然后根据自定义逻辑返回true（放行）或false（拦截）。开发完成后将编译好的class文件放到MyCat的lib目录下，重启服务即可生效。

攻击者会不断尝试绕过拦截规则，了解常见的绕过手法才能写出更健壮的规则。以下是一些实际攻击中出现的绕过方式及对应的防御思路：

双写关键字绕过：例如将UNION写成UNIUNIONON，如果规则只是简单匹配UNION，去掉匹配到的部分后剩下的字符会重新组合成UNION。防御方法是在规则中使用重复匹配或递归匹配，确保多次替换后仍能识别。更彻底的做法是不做替换而是直接拒绝，只要匹配到危险模式就拦截，不给绕过机会。

编码绕过：攻击者可能使用URL编码、十六进制编码、Unicode编码来隐藏恶意负载。MyCat接收到的SQL是客户端已经解码后的原始字符串，但如果你的应用层在传输过程中做了额外编码，就需要在MyCat前端增加解码处理。建议在自定义拦截器中加入多层解码逻辑，对常见编码格式进行递归解码后再匹配规则。

注释内联绕过：攻击者在关键字中间插入注释来破坏规则匹配，例如UN//ION。针对这种手法，规则中需要覆盖注释的各种变体。可以专门增加一条规则拦截包含注释符号的请求，或者使用更宽泛的正则来匹配被注释分割的关键字组合。

大小写和空格变形：通过变换大小写、使用制表符或换行符代替空格来绕过检测。使用(?i)标志解决大小写问题，使用\s+代替单一空格来解决空白符变形问题。正则表达式写得越宽泛，绕过难度就越大，但误杀风险也会上升，需要根据实际业务找到平衡点。

参数拦截功能对性能的影响主要来自正则匹配的计算开销。每条SQL请求都要经过所有规则的逐一匹配，当规则数量达到上百条时，匹配耗时可能达到毫秒级。在高并发场景下，这个开销会被放大。优化方向有几个：一是精简规则数量，合并功能相似的规则，减少匹配次数；二是优化正则表达式的写法，避免使用回溯过多的模式，例如用字符类代替选择分支；三是利用MyCat的缓存机制，对于相同结构的SQL只做一次拦截判断。

实测数据显示，在配置30条典型拦截规则的情况下，MyCat单节点的QPS下降幅度在3%到5%之间。这个代价对于安全防护来说是完全可以接受的。如果规则数量超过100条，建议开启MyCat的预处理语句缓存功能，让相同SQL模板的请求复用拦截结果，可以将性能损耗控制在8%以内。

还有一个优化点是规则的分级管理。不是所有规则都需要全局生效，可以根据不同的逻辑库或数据节点配置不同的拦截规则集。在schema.xml中可以为每个schema指定独立的拦截器配置，这样读库和写库、核心库和日志库就可以使用不同强度的防护策略，既保证了安全又减少了不必要的性能开销。

拦截功能上线后，必须有配套的监控手段来观察拦截效果和发现误杀情况。MyCat的拦截器在拒绝请求时会打印日志，日志级别为WARN，包含被拦截的SQL语句、匹配到的规则、来源IP和用户名等信息。通过采集这些日志并接入监控系统，可以实时掌握攻击态势。

建议在日志中重点关注两类事件：一是短时间内同一来源的大量拦截，这很可能是一次扫描或攻击行为，需要及时封禁IP；二是来自正常业务账号的拦截，这可能是规则误杀，需要立即调整规则并验证。可以在MyCat的日志配置中单独为拦截器设置输出文件，方便集中分析和归档。

对于关键业务系统，还可以在自定义拦截器中加入告警逻辑。当拦截到高危攻击特征时，通过HTTP回调或消息队列将告警信息推送到安全运营平台，实现分钟级的应急响应。告警内容应包含完整的攻击载荷、目标库表、时间戳和来源信息，为后续溯源提供依据。

参数拦截功能不是孤立的安全手段，它应该与Web应用防火墙、数据库审计系统、最小权限原则等措施形成纵深防御体系。MyCat拦截器工作在数据库访问层，能拦截到已经穿透应用层防护的攻击，这是它的独特价值。但反过来，如果应用层已经做好了参数化查询和输入校验，MyCat拦截器就更多是作为最后一道防线存在。

在实际部署中，建议将MyCat的拦截规则与WAF的规则做差异化配置。WAF侧重HTTP层面的攻击检测，MyCat侧重SQL语义层面的检测，两者覆盖的攻击面不同，可以互补。同时，定期将MyCat拦截日志与数据库审计日志做交叉比对，可以发现是否有攻击绕过了中间件防护直接访问了数据库，这是检验网络安全架构完整性的有效方法。

参数拦截功能还有一个容易被忽视的用途：作为SQL注入攻击的情报来源。通过长期积累拦截日志，可以分析出攻击者的工具特征、攻击频率、目标偏好等信息，这些情报对于优化整体安全策略很有价值。建议每季度对拦截日志做一次深度分析，提取新的攻击模式并更新到规则库中，让防护能力持续进化。