rewriterule仅匹配url路径,不检查文件系统权限;真正拦截非法请求需分层配合:rewriterule识别恶意意图,require、allowoverride、options等执行底层权限校验,并前置[f]规则拦截危险模式。

Apache 的 RewriteRule 本身不检查文件系统权限,它只做 URL 路径匹配与重定向/重写。真正拦截非法请求、防止越权访问的关键,在于把 RewriteRule 和 Apache 自身的文件系统访问控制机制配合使用——不是“写在一起”,而是“分层拦截”:RewriteRule 负责识别恶意意图,Require、AllowOverride、Options 等指令负责执行底层权限校验。
先禁止目录遍历和敏感路径暴露
很多非法重写请求的目标是绕过 Web 根目录、读取配置或系统文件(如 /.htaccess、/etc/passwd)。这类攻击必须在 RewriteRule 执行前就被拦住:
- 在虚拟主机或目录配置中禁用路径遍历:
Options -Indexes -FollowSymLinks -MultiViews - 显式拒绝访问敏感后缀:
<filesmatch><br> Require all denied<br></filesmatch>
- 限制 RewriteRule 只能作用于允许的子路径,例如只允许重写
/api/或/content/下的内容,避免规则泛化匹配根路径
用 RewriteCond 预检真实文件状态再放行
内部重写(如伪静态)常需确保目标脚本存在且可执行。直接重写到不存在或不可读的文件,可能暴露路径或触发错误泄露:
Apache Superset 是一个广泛采用的开源 BI 平台,用于 SQL 探索、图表构建和仪表板交付。当代理需要查询仓库数据、组装仪表板或使用成熟的分析界面解释指标而不是临时笔记本代码时,此技能非常有用。
- 不要这样写(无校验,风险高):
RewriteRule ^post/(\d+)\.html$ /post.php?id=$1 [L] - 应加上存在性判断:
RewriteCond %{REQUEST_FILENAME} !-f<br>RewriteCond %{REQUEST_FILENAME} !-d<br>RewriteRule ^post/(\d+)\.html$ /post.php?id=$1 [L]
→ 只有当请求 URI 对应的不是真实文件、也不是真实目录时,才交给 post.php 处理,避免重写覆盖静态资源或误指系统路径 - 若需更细粒度控制(如只允许重写到
/var/www/html/app/下的 PHP 文件),可用RewriteCond %{DOCUMENT_ROOT}/app/$1.php -f显式校验目标文件是否存在且可读
严格约束 .htaccess 的生效范围
非法重写请求常通过上传恶意 .htaccess 文件实现。必须从源头限制其能力:
- 全局禁用:
AllowOverride None(最安全,默认推荐) - 如必须启用,仅开放必要指令:
AllowOverride FileInfo Options=FollowSymLinks,Indexes
→ 不包含 AuthConfig、Limit、All,防止篡改认证或访问控制逻辑 - 对上传目录(如
/uploads/)务必设置:<directory><br> AllowOverride None<br> php_flag engine off<br> AddHandler default-handler .php .phtml<br></directory>
彻底阻止该目录下任何重写或脚本执行
用 [F] 拦截已识别的危险模式,而非依赖重写
对于明确非法的请求(如含 ../、php://filter、data://、glob://),RewriteRule 应直接拒绝,不重写也不转发:
RewriteCond %{THE_REQUEST} \.\./ [NC,OR]<br>RewriteCond %{THE_REQUEST} (php|data|glob|phar):// [NC]<br>RewriteRule ^ - [F,L]- 注意:
[F]返回 403,不记录日志(除非额外配LogLevel alert rewrite:trace3),且不会触发自定义 403 页面,除非你显式写了ErrorDocument 403 /403.html - 这类规则要放在所有重写逻辑之前,确保在 Apache 解析完请求行后第一时间拦截










