2025/3/18：请求jsp获得servlet的过程

最初想法是调试tomcat最近几个代码执行的洞，看到CVE-2024-50379用非标准后缀使请求通过DefaultServlet处理触发文件上传，于是看看这个请求在tomcat具体咋绑定到JspServlet上，当复习了

环境准备

IDEA2024.2.3 java8u65 tomcat9.0.70 ant1.10.15

编译源码搭建环境大致参考这个：Tomcat IDEA源码调试环境搭建_企业 tomcat idea 本地代码调试-CSDN博客

将tomcat源码导入IDEA中后先新建pom.xml，并添加为maven工程；

之后在IDEA中下载ant插件，执行ant ide-intellij命令构建，构建成功后按提示设置PATH后执行ant deploy；

在IDEA中选择Java草稿设置运行配置来配置虚拟机选项；

若提示缺少aQute的包直接pom里添加拉取就行，提示VERSION_9变量找不到报错把那段代码注释不影响正常启动

调试流程

先根据请求（我使用GET请求/index.jsp）流程在JspServlet的service打个断点，访问下默认的index.jsp，如下图可以在request.mappingData中找到保存的信息，可以看到StandardWrapper对应的值为jsp

在StandardWrapperValve#invoke中，将加载servlet变量的值获取servlet

在118行的赋值后servlet的值为JspServlet，因此接下来寻找wrapper的赋值过程

wrapper的赋值来源于request.mappingData中wrapper保存的值，向上查找可以发现其在CoyoteAdapter中赋值。经过调试可知，在CoyoteAdapter#service函数中执行至354行时，mappingData被赋值

跟进函数postParseRequest，可以发现在714行处赋值

进入map函数后，会对mappingData内容赋值

随后进入Mapper#internalMap，首先赋值host，在772行处

设置context，随后进入internalMapWrapper

这个函数会将contextVersion的内容赋给mappingData.wrapper：

internalMapWrapper函数的逻辑大致为：依次检测contextVersion的exactWrappers、wildcardWrappers、extensionWrappers、welcomeResources、defaultWrapper是否符合赋值给mappingData的条件

进入internalMapWrapper函数时截取了路径的偏移量，备用

针对exactWrappers的处理由internalMapExactWrappe进行，进行精确匹配

处理精确匹配wrapper,这里可以看到wrappers内容为空，实际上不会做任何处理

这里检测路径是否符合通配符，进入internalMapWildcardWrapper看看

这里首先判断path开头是否匹配wrapper，startsWith内容如下：

public boolean startsWith(String s) {
    char[] c = buff;
    int len = s.length();
    if (c == null || len > end - start) {
        return false;
    }
    int off = start;
    for (int i = 0; i < len; i++) {
        if (c[off++] != s.charAt(i)) {
            return false;
        }
    }
    return true;
}