如何通过Nginx正则规则阻止eval base64类病毒请求？

你之前的规则无效是因为location指令只匹配URI的路径部分（也就是?之前的内容），而这类攻击的恶意代码是藏在?后面的查询参数里，所以location ~* base64根本不会命中这些请求。下面给你几个有效的Nginx规则方案：

方案1：全局匹配请求URI中的恶意特征 #

把这个规则放在你的server块里，它会检查完整的请求URI（包含查询参数），只要匹配到常见的恶意函数就返回403禁止访问：

if ($request_uri ~* "(base64_decode|eval|assert|array_map)") {
    return 403;
}

这个规则覆盖了攻击请求里的array_map、eval、assert、base64_decode这些关键恶意特征，能有效拦截这类攻击。

方案2：精准匹配攻击的特定参数结构 #

如果想更精准，避免误拦正常请求，可以直接匹配攻击请求里的特定参数（注意这里用的是编码后的参数名，和原始攻击请求一致）：

if ($args ~* "name%5B%23post_render%5D%5B0%5D=array_map") {
    return 403;
}

$args变量专门存储请求的查询参数部分，这个规则会精准命中带有该恶意参数的请求。

方案3：组合特征增强拦截准确性 #

如果担心单一特征误拦，可以组合多个恶意特征，比如同时匹配eval和base64_decode（这俩在攻击里是成对出现的）：

if ($request_uri ~* "eval.*base64_decode|base64_decode.*eval") {
    return 403;
}

额外优化：只拦截POST请求 #

因为这类攻击是通过POST发起的，你可以加上请求方法判断，进一步缩小拦截范围：

if ($request_method = POST) {
    if ($request_uri ~* "(base64_decode|eval|assert|array_map)") {
        return 403;
    }
}

注意事项 #

• 不要在location块里嵌套if指令（Nginx的if在location里有坑），最好把这些规则放在server块全局生效。
• 测试阶段可以先把return 403改成return 404或者添加日志记录，确认不会误拦正常请求后再正式启用。

内容的提问来源于stack exchange，提问作者vysogot