如何使用 .htaccess 安全拦截恶意 URL 请求（如 LFI 攻击）-php教程-PHP中文网

如何使用 .htaccess 安全拦截恶意 URL 请求（如 LFI 攻击）

本文详解如何正确使用 .htaccess 阻止含 php://filter 的恶意 URL 访问，指出常见配置错误，并强调：.htaccess 仅作辅助防护，关键须在 PHP 层对 page 参数做白名单校验。

本文详解如何正确使用 .htaccess 阻止含 `php://filter` 的恶意 url 访问，指出常见配置错误，并强调：**.htaccess 仅作辅助防护，关键须在 php 层对 `page` 参数做白名单校验**。

.htaccess 文件无法直接匹配完整 URL（含协议、域名、查询参数），因此你原写法：

RewriteRule http://192.168.1.123/index.php?page=php://filter/convert.base64-encode/resource=setupreset$ - [F]

是完全无效且导致 500 错误的主因——RewriteRule 默认只匹配 请求路径（URI）部分（即 /index.php 及其后内容），不包含 http://...，也不自动解析查询字符串（?page=...）。此外，Apache 2.4+ 已弃用 Deny from all，需改用 Require all denied。

✅ 正确做法分两层：

一、.htaccess 层：拦截危险查询参数（辅助防御）

在 .htaccess 中使用 RewriteCond 检查 %{QUERY_STRING}，阻断所有含 php:// 的 page 参数：

Yarn - Control and Access Threads.com via the CLI

通过 yarn-threads-cli 与 Threads（Meta）交互。当用户想要阅读首页动态、点赞、收藏的帖子或特定帖子时使用；查看...

下载

RewriteEngine On

# 拦截 page 参数中包含 php:// 的任意请求（大小写不敏感）
RewriteCond %{QUERY_STRING} page=php:// [NC]
RewriteRule ^index\.php$ - [F]

# 进阶：同时拦截其他危险伪协议（data://、phar:// 等）
RewriteCond %{QUERY_STRING} (page|file|include)=.*?(php|data|phar|zip):// [NC]
RewriteRule ^ - [F]

⚠️ 注意事项：

^index\.php$ 中的 ^ 和 $ 确保精确匹配路径，避免误伤；
[NC] 表示忽略大小写，防止 PHP:// 绕过；
- [F] 返回 403 Forbidden，比重定向更安全；
块中 setupreset.php 若真实存在，应确保其不在 Web 可访问目录下；若仅为资源名（非文件），完全无效。

二、PHP 层：强制白名单校验（核心防御）

.htaccess 仅能缓解，不能替代业务逻辑层的安全控制。必须在 index.php 中严格校验 page 参数：

<?php // index.php 示例：白名单驱动的页面路由
$allowed_pages = [
    'home',
    'about',
    'contact',
    'setupreset' // 仅当 setupreset 是合法页面时才列入
];

$page = $_GET['page'] ?? '';
$page = basename($page); // 移除路径遍历字符（如 ../）

if (!in_array($page, $allowed_pages, true)) {
    http_response_code(403);
    die('Access denied.');
}

// 安全加载页面
include "pages/{$page}.php";

? 关键原则：

永远不要拼接用户输入到 include()/require()/file_get_contents()；
使用 basename() 防止路径穿越；
优先采用白名单（whitelist），而非黑名单（blacklist）——攻击向量持续演进，黑名单极易遗漏；
敏感文件（如 setupreset 配置）应存放于 Web 根目录之外，或通过 .htaccess 全局禁止访问 .php 以外的敏感扩展（如 .inc, .config）：

<filesmatch>
  Require all denied
</filesmatch>

总结：.htaccess 是 Web 服务器层的有效补充手段，但面对本地文件包含（LFI）等逻辑漏洞，唯一可靠防线是 PHP 代码中的输入验证与白名单机制。将安全责任前移至应用层，才能真正实现纵深防御。