怎么在Apache重写逻辑中加入RewriteFilter实现非法字符的提前过滤实战-Apache-PHP中文网

apache无rewritefilter模块，实际指urlrewritefilter或对mod_rewrite的误称；应使用mod_rewrite+rewritecond在请求初筛非法字符，匹配编码后uri/query_string并返回403，配合setenvif记录日志，避免解码过滤。

怎么在apache重写逻辑中加入rewritefilter实现非法字符的提前过滤实战

Apache 本身没有叫 RewriteFilter 的内置模块——这是常见误解。实际中，“RewriteFilter”通常指代两类东西：一是 Java 生态的 UrlRewriteFilter（Servlet 过滤器），二是对 mod_rewrite + 条件拦截逻辑的口语化误称。真正能在 Apache HTTP Server 层实现“非法字符提前过滤”的，是 mod_rewrite 配合 RewriteCond 对请求 URI、查询字符串或头部做模式匹配并立即拒绝，而非等请求进入后端才处理。

用 mod_rewrite 直接拦截含非法字符的请求路径

这是最轻量、最前置的过滤方式，在请求刚抵达 Apache 时就终止，不发往后端。关键点是匹配原始编码后的 URI（如空格为 + 或 %20，中文为 %E4%BD%A0 等）。

禁止路径中出现典型非法模式：../、.git/、WEB-INF/、%00（空字节）、双斜杠 //、反斜杠

写法示例（放在虚拟主机或 .htaccess 中）：

RewriteCond %{REQUEST_URI} ../ [OR]
RewriteCond %{REQUEST_URI} (.git|WEB-INF|.env|.htaccess) [NC,OR]
RewriteCond %{REQUEST_URI} (%00|//|\) [NC]
RewriteRule ^ - [F]

[F] 表示返回 403 Forbidden，比 404 更明确表示“你无权访问”，也避免暴露目录结构

对查询字符串中的敏感参数或非法值做正则过滤

查询字符串（?key=value）不会被 RewriteRule 默认匹配，必须用 RewriteCond %{QUERY_STRING} 显式检查，且注意值是 URL 编码后的原始形式。

Apache Superset Dashboard and SQL Exploration Skill

Apache Superset 是一个广泛采用的开源 BI 平台，用于 SQL 探索、图表构建和仪表板交付。当代理需要查询仓库数据、组装仪表板或使用成熟的分析界面解释指标而不是临时笔记本代码时，此技能非常有用。

下载

拒绝含 SQL 注入特征的参数值，例如：select%20、union%20all、sleep(%20
拒绝含 XSS 特征的参数值，例如：<script></script>（实际为 %3Cscript%3E）、javascript:（javascript%3A）

示例规则：

RewriteCond %{QUERY_STRING} (select%20|union%20all|sleep%20?() [NC,OR]
RewriteCond %{QUERY_STRING} (%3Cscript|%3Cimg|javascript%3A|expression%3A) [NC]
RewriteRule ^ - [F]

若需同时满足多个条件（如参数名是 q 且值含非法字符），可用 [AND] 连接多个 RewriteCond

结合环境变量与自定义日志，增强可追溯性

单纯返回 403 不够，建议记录拦截详情，便于安全审计和误报排查。

用 SetEnvIf 标记匹配到非法字符的请求：

SetEnvIf Request_URI "../|.git/|WEB-INF" badreq=1
SetEnvIf Query_String "(%3Cscript|javascript%3A)" badreq=1

在 LogFormat 中加入该变量，让 access log 显示是否被拦截：

LogFormat "%h %l %u %t "%r" %>s %b "%{Referer}i" "%{User-Agent}i" %{badreq}e" combined-with-flag

这样每条被拦截的日志行末尾会显示 1，方便 grep 或 SIEM 工具聚合分析

不推荐在 Apache 层做“解码后内容过滤”

有人想先解码再匹配明文（比如把 %E4%BD%A0 变成 “你”），但 mod_rewrite 不提供自动解码能力；强行用重写链模拟解码极易出错、性能差，且绕过方式多（如双重编码 %25E4%25BD%25A0）。更合理的方式是：

在 Apache 层只做编码态的强特征拦截（如 %3C、%00、%2e%2e%2f）
把语义级过滤（如关键词、上下文检测）交给后端 WAF 或应用层（如 Spring 的 @Valid、自定义 Filter）
若必须统一在网关层做深度检测，建议换用 mod_security（配合 OWASP CRS 规则集），它支持解码、多阶段匹配、异常评分等完整 WAF 能力