Web - 标签 - 有价值炮灰

初探 Struts2 框架安全

Wed, 01 Nov 2023 08:40:00 +0800

最近分析 confluence 的漏洞，发现是基于 Struts 框架的，其中有很多相关知识点并不了解，因此专门来学习一下 Struts 2。

背景

在网上一搜 Struts 2 资料发现介绍漏洞的文章比介绍开发的还多，少数开发者的声音也是 “Struts 过时了吗？” 之类的疑问，事实上这个框架也确实是过时了，现在Java Web 开发早已是 Spring 全家桶一统江山的局面。但我们也不能不承认曾经 Struts 的地位。Struts2 + Spring + Hibernate 三大框架在当年组合号称 SSH，对 Java Web 应用生态产生了深远的影响，以至于现在有许多知名应用中还有 Struts 的影子。

因此，即便 Struts 已经日薄西山，对于 Java 安全研究者而言也是需要深入了解的目标，就像二进制研究员需要理解 “过时” 的 jmp esp 栈溢出利用方法一样。

Struts 101

分析 Struts 内部细节之前我们先从开发的角度看 Struts 应用的基本构建和使用过程。

在 Struts 官网中提供了对应的开发文档，如 Getting Start。同时也提供了具体的代码示例。

值得一提的是 Struts 的文档还提供了针对开发者的一些预备知识，见 Key Technologies Primer。其中包括了许多 JavaEE 的基本知识，想当初刚出门 Java 的时候要是能看到这份文档估计能少走不少弯路。

基本结构

Struts 应用也是一个 JavaEE 应用，因此同样基于 Servlet API。有趣的是它不像 Spring 等其他 Web 框架将功能插入到 Servlet 中(DispatchServlet)，而是插入到 Filter 中，如下所示:


 id="WebApp_ID" version="2.4"
	xmlns="http://java.sun.com/xml/ns/j2ee" 
	xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
	xsi:schemaLocation="http://java.sun.com/xml/ns/j2ee http://java.sun.com/xml/ns/j2ee/web-app_2_4.xsd">
	Basic Struts2
	
		struts2
		org.apache.struts2.dispatcher.filter.StrutsPrepareAndExecuteFilter
	

	
		struts2
		/*
	

	
		index

插入的 StrutsPrepareAndExecuteFilter 同样也可以实现接管所有请求的目的。在接管所有请求后，使用 struts.xml 作为 Struts 自身的路由映射配置，一个简单的示例如下:


    "-//Apache Software Foundation//DTD Struts Configuration 2.5//EN"
    "http://struts.apache.org/dtds/struts-2.5.dtd">



     name="struts.devMode" value="true" />

     name="basicstruts2" extends="struts-default">
         name="index">
            /index.jsp

注意该文件保存在 src/main/resources 中，类似于 log4j2.xml。上述配置指定 /index、/index.action 都会被路由到 index.jsp 上。

设计模式

看 Struts 的示例代码可以很明显的 MVC 设计风格，以 helloworld 为例，其中包含一个 Controller，又称为 Action:

import com.opensymphony.xwork2.ActionSupport;

public class HelloWorldAction extends ActionSupport {

    private MessageStore messageStore;

    public String execute() {
        messageStore = new MessageStore() ;
        
        return SUCCESS;
    }

    public MessageStore getMessageStore() {
        return messageStore;
}

Action 中通常包含具体的数据源，比如上面的 MessageStore (POJO)，这个数据源即是 Model。在 struts.xml 中指定 Action 的路由，并链接到具体的 JSP 上，此为 View 部分:

 name="hello" class="org.apache.struts.helloworld.action.HelloWorldAction" method="execute">
     name="success">/HelloWorld.jsp

如果没有指定，会默认访问 execute 返回值对应的 JSP，如 WEB-INF/content/hello-success.jsp。

标签表示如果 HelloWorldAction.execute 返回 “success” (即 Action.SUCCESS)，就将结果映射到 HelloWorld.jsp 上。

至此，Model-View-Controller 三要素都全了，访问 /hello 后即可进入到 Action 准备好数据，绑定到 JSP 的上下文中并根据需要渲染出来，HelloWorld.jsp 如下:


<%@ page language="java" contentType="text/html; charset=UTF-8" pageEncoding="UTF-8" %>
<%@ taglib prefix="s" uri="/struts-tags" %>

  
    
    Hello World!

其中使用 JavaBean 风格的表达式获取获取具体的属性 messageStore.message，其背后访问的是 Java 对象的 getter 方法。

内部实现

接下来我们深入到 Struts 的内部实现中。先粘贴一个经典的图片:

前面我们说过，Struts 应用的 web.xml 会添加一个 Filter StrutsPrepareAndExecuteFilter，因此用户请求进来的时候是依照 FilterChain 的顺序依次调用注册的 Filter，直到 Struts 的 Filter。随后从左边开始，Struts 会将请求的 URL 转换为对应的 ActionProxy 去进行调用，这里有一步使用 ConfiguarationManager 去加载我们的配置 struts.xml，这里可能意味着一次懒加载，我们后文再根据实际的代码去分析。

调用 ActionProxy 的时候，会在开发者实际定义的 Action 前后依次调用 Interceptor，实现诸如过滤参数、打印日志、记录请求时间等操作。可以看到这里的架构设计还是很优雅的，开发者也可以定义和注册自己的 Interceptor 去实现鉴权等业务逻辑。

大致的调用流程就是这样，接下来我们通过代码去分析具体的调用逻辑。由于代码比较多，我们需要有的放矢，因此主要聚焦于 Struts 的调用逻辑实现、路由查找等关键功能。

如无特别说明，本文所涉及代码都基于 struts2-core-6.2.0 版本。

Filter

首先看详细的调用流程。我们可以从 StrutsPrepareAndExecuteFilter 的 doFilter 开始，也可以直接在 Controller 打个断点去至顶向下分析。不过我们这里用另一个方法, 在设置应用 struts.devMode=true 的情况下，访问一个不存在的 URL 会返回带调用栈的出错信息，如下所示:

com.opensymphony.xwork2.DefaultActionProxy.prepare(DefaultActionProxy.java:183)
org.apache.struts2.factory.StrutsActionProxy.prepare(StrutsActionProxy.java:57)
org.apache.struts2.factory.StrutsActionProxyFactory.createActionProxy(StrutsActionProxyFactory.java:32)
com.opensymphony.xwork2.DefaultActionProxyFactory.createActionProxy(DefaultActionProxyFactory.java:60)
org.apache.struts2.dispatcher.Dispatcher.createActionProxy(Dispatcher.java:694)
org.apache.struts2.dispatcher.Dispatcher.prepareActionProxy(Dispatcher.java:679)
org.apache.struts2.dispatcher.Dispatcher.serviceAction(Dispatcher.java:642)
org.apache.struts2.dispatcher.ExecuteOperations.executeAction(ExecuteOperations.java:79)
org.apache.struts2.dispatcher.filter.StrutsPrepareAndExecuteFilter.handleRequest(StrutsPrepareAndExecuteFilter.java:157)
org.apache.struts2.dispatcher.filter.StrutsPrepareAndExecuteFilter.tryHandleRequest(StrutsPrepareAndExecuteFilter.java:140)
org.apache.struts2.dispatcher.filter.StrutsPrepareAndExecuteFilter.doFilter(StrutsPrepareAndExecuteFilter.java:128)
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:178)
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:153)
...

可以看到末尾如我们所料，从 Tomcat 调用到了 StrutsPrepareAndExecuteFilter.doFilter，虽然这是一个 Filter 但却做的是 Servlet 的事情。顾名思义，其作用主要是准备和执行，准备和执行什么呢？当然是 Action，即 Controller。

public void doFilter(ServletRequest req, ServletResponse res, FilterChain chain) throws IOException, ServletException {

    HttpServletRequest request = (HttpServletRequest) req;
    HttpServletResponse response = (HttpServletResponse) res;

    try {
        prepare.trackRecursion(request);
        String uri = RequestUtils.getUri(request);
        if (prepare.isUrlExcluded(request, excludedPatterns)) {
            LOG.trace("Request: {} is excluded from handling by Struts, passing request to other filters", uri);
            chain.doFilter(request, response);
        } else {
            tryHandleRequest(chain, request, response, uri);
        }
    } finally {
        prepare.cleanupRequest(request);
    }
}

excludedPatterns 是 java.util.regex.Pattern 的列表，在此列表中的路径不会被 Struts 接管，而是直接放行到后续的 Filter 和 Servlet 处理。这里获取请求 URI 是通过 RequestUtils.getUri，并且以此 Uri 作为后续路由的重要依据。

getUri

org.apache.struts2.RequestUtils#getUri 的主要实现如下:

public static String getUri(HttpServletRequest request) {
    // handle http dispatcher includes.
    String uri = (String) request.getAttribute("javax.servlet.include.servlet_path");
    if (uri != null) {
        return uri;
    }

    uri = getServletPath(request);
    if (StringUtils.isNotEmpty(uri)) {
        return uri;
    }

    uri = request.getRequestURI();
    return uri.substring(request.getContextPath().length());
}

public static String getServletPath(HttpServletRequest request) {
    String servletPath = request.getServletPath();
    
    String requestUri = request.getRequestURI();
    // Detecting other characters that the servlet container cut off (like anything after ';')
    if (requestUri != null && servletPath != null && !requestUri.endsWith(servletPath)) {
        int pos = requestUri.indexOf(servletPath);
        if (pos > -1) {
            servletPath = requestUri.substring(requestUri.indexOf(servletPath));
        }
    }

    if (StringUtils.isNotEmpty(servletPath)) {
        return servletPath;
    }
    
    int startIndex = request.getContextPath().equals("") ? 0 : request.getContextPath().length();
    int endIndex = request.getPathInfo() == null ? requestUri.length() : requestUri.lastIndexOf(request.getPathInfo());

    if (startIndex > endIndex) { // this should not happen
        endIndex = startIndex;
    }

    return requestUri.substring(startIndex, endIndex);
}

按顺序看，其获取 URI 的优先级如下:

request.getAttribute(“javax.servlet.include.servlet_path”);
request.getServletPath();
request.getRequestURI() 通过 request.getServletPath() 计算的子字符串；
request.getRequestURI() 通过 request.getContextPath() 和 request.getPathInfo() 计算的子字符串；
request.getRequestURI() 通过 request.getContextPath() 计算的子字符串；

其中大部分情况下会落到 2 或者 3 的返回结果上。getServletPath 是容器最终用于寻址 Servlet 的路径，即经过 normalize 和删除路径参数等操作的结果，在 Tomcat 中还进行了 URL 解码，可以认为是相对安全的。但 Struts 拓展了 getServletPath 方法，还是从 requestURI 进行了一次判断并执行 substring 操作，因此我们可以很大程度上控制 getUri 的返回结果，至于有什么影响要看后面具体的路由逻辑。

请求处理

handleRequest 主要分成两个阶段，先是处理静态资源文件，然后才是对于动态路由的处理，如下所示:

private void tryHandleRequest(FilterChain chain, HttpServletRequest request, HttpServletResponse response, String uri) throws IOException, ServletException {
    LOG.trace("Checking if: {} is a static resource", uri);
    boolean handled = execute.executeStaticResourceRequest(request, response);
    if (!handled) {
        LOG.trace("Uri: {} is not a static resource, assuming action", uri);
        handleRequest(chain, request, response, uri);
    }
}

我们分别对二者进行分析。

静态资源

静态资源的处理逻辑主要是 executeStaticResourceRequest:

public boolean executeStaticResourceRequest(HttpServletRequest request, HttpServletResponse response) throws IOException, ServletException {
    // there is no action in this request, should we look for a static resource?
    String resourcePath = RequestUtils.getServletPath(request);

    if ("".equals(resourcePath) && null != request.getPathInfo()) {
        resourcePath = request.getPathInfo();
    }

    StaticContentLoader staticResourceLoader = dispatcher.getContainer().getInstance(StaticContentLoader.class);
    if (staticResourceLoader.canHandle(resourcePath)) {
        staticResourceLoader.findStaticResource(resourcePath, request, response);
        // The framework did its job here
        return true;

    } else {
        // this is a normal request, let it pass through
        return false;
    }
}

其中值得关注的点是对于静态资源路径，这里使用的是没有经过其他处理的 getServletPath。通过 StaticContentLoader 先判断是否可以处理对应路径:

// org.apache.struts2.dispatcher.DefaultStaticContentLoader#canHandle
public boolean canHandle(String resourcePath) {
    return serveStatic && resourcePath.startsWith(uiStaticContentPath + "/");
}

uiStaticContentPath 默认是 /static，可以由开发者自行配置。因此这里仅判断请求路径是否以 /static/ 开头，而没有判断文件是否存在。注意一旦 canHandle 返回 true，那么后续即便找不到资源也不会继续后续的动态路由查找，而是直接返回 404 结束请求。

DefaultStaticContentLoader#findStaticResource 基本上是使用 ClassLoader.getResource，但有一些特殊的处理:

public void findStaticResource(String path, HttpServletRequest request, HttpServletResponse response)
    throws IOException {
    String name = cleanupPath(path);
    for (String pathPrefix : pathPrefixes) {
        URL resourceUrl = findResource(buildPath(name, pathPrefix));
        if (resourceUrl != null) {
            InputStream is = null;
            try {
                //check that the resource path is under the pathPrefix path
                String pathEnding = buildPath(name, pathPrefix);
                if (resourceUrl.getFile().endsWith(pathEnding))
                    is = resourceUrl.openStream();
            } catch (IOException ex) {
                // just ignore it
                continue;
            }

            //not inside the try block, as this could throw IOExceptions also
            if (is != null) {
                process(is, path, request, response);
                return;
            }
        }
    }
    response.sendError(HttpServletResponse.SC_NOT_FOUND);
}

首先是 cleanupPath 对路径又做了一次清理，作用是删除 /static 前缀:

protected String cleanupPath(String path) {
    if (path.startsWith(uiStaticContentPath)) {
        return path.substring(uiStaticContentPath.length());
    } else {
        return path;
    }
}

然后是通过 pathPrefixes 数组去构建实际的资源路径去循环进行查找，动态调试 pathPrefixes 的值有:

org/apache/struts2/static/
template/
static/
org/apache/struts2/interceptor/debugging/

buildPath 的实现比较有意思:

protected String buildPath(String name, String packagePrefix) throws UnsupportedEncodingException {
    String resourcePath;
    if (packagePrefix.endsWith("/") && name.startsWith("/")) {
        resourcePath = packagePrefix + name.substring(1);
    } else {
        resourcePath = packagePrefix + name;
    }

    return URLDecoder.decode(resourcePath, encoding);
}

其中对组合的 URL 路径又进行了一次 URL 解码。根据我们之前的文章可知，HttpServletRequest.getServletPath 已经是经过一次 URL 解码的了，因此这里实际上进行了二次解码！

因此这里可能会出现路径穿越的问题，不过这里已经进行了额外的判断:

String pathEnding = buildPath(name, pathPrefix);
if (resourceUrl.getFile().endsWith(pathEnding))
    is = resourceUrl.openStream();

根据 commit 日志，发现这个修改确实也是为了修复路径穿越的问题，详见 WW-2779 Directory traversal vulnerability while serving static content。

不过，即便能绕过这里的检查，在 Servlet 容器层还有一层校验，以 Tomcat 为例，其会对超出根路径的静态资源请求抛出异常:

java.lang.IllegalArgumentException: 资源路径[/WEB-INF/classes/static/../../../../../etc/hosts]已规范化为无效的[null]
org.apache.catalina.webresources.StandardRoot.validate(StandardRoot.java:258)
org.apache.catalina.webresources.StandardRoot.getResource(StandardRoot.java:207)
org.apache.catalina.webresources.StandardRoot.getClassLoaderResource(StandardRoot.java:220)
org.apache.catalina.loader.WebappClassLoaderBase.findResource(WebappClassLoaderBase.java:954)
org.apache.catalina.loader.WebappClassLoaderBase.getResource(WebappClassLoaderBase.java:1078)
com.opensymphony.xwork2.util.ClassLoaderUtil.getResource(ClassLoaderUtil.java:108)
org.apache.struts2.dispatcher.DefaultStaticContentLoader.findResource(DefaultStaticContentLoader.java:305)
org.apache.struts2.dispatcher.DefaultStaticContentLoader.findStaticResource(DefaultStaticContentLoader.java:213)
org.apache.struts2.dispatcher.ExecuteOperations.executeStaticResourceRequest(ExecuteOperations.java:59)
org.apache.struts2.dispatcher.filter.StrutsPrepareAndExecuteFilter.tryHandleRequest(StrutsPrepareAndExecuteFilter.java:137)
org.apache.struts2.dispatcher.filter.StrutsPrepareAndExecuteFilter.doFilter(StrutsPrepareAndExecuteFilter.java:128)

从中也可以看到 getResource 确实是通过 Tomcat 的 ClassLoader 实现的。

路由查找

如果前面判断目标路由不是静态资源，那么就会进行实际的路由查找和调用:

private void handleRequest(FilterChain chain, HttpServletRequest request, HttpServletResponse response, String uri) throws ServletException, IOException {
    prepare.setEncodingAndLocale(request, response);
    prepare.createActionContext(request, response);
    prepare.assignDispatcherToThread();

    HttpServletRequest wrappedRequest = prepare.wrapRequest(request);
    try {
        ActionMapping mapping = prepare.findActionMapping(wrappedRequest, response, true);
        if (mapping == null) {
            LOG.trace("Cannot find mapping for: {}, passing to other filters", uri);
            chain.doFilter(request, response);
        } else {
            LOG.trace("Found mapping: {} for: {}", mapping, uri);
            execute.executeAction(wrappedRequest, response, mapping);
        }
    } finally {
        prepare.cleanupWrappedRequest(wrappedRequest);
    }
}

这里看似分成了两步，findActionMapping 查找路由，executeAction 执行路由。但实际上 ActionMapping 只是一个简单的封装类，保存请求的路由(action)、命名空间(namespace)、后缀、请求参数等数据。实际从 URI 到 Action 的映射还是在 executeAction 中实现。

ActionMapping

findActionMapping 核心实现为 org.apache.struts2.dispatcher.mapper.DefaultActionMapper#getMapping:

public ActionMapping getMapping(HttpServletRequest request, ConfigurationManager configManager) {
    ActionMapping mapping = new ActionMapping();
    String uri = RequestUtils.getUri(request);

    int indexOfSemicolon = uri.indexOf(';');
    uri = (indexOfSemicolon > -1) ? uri.substring(0, indexOfSemicolon) : uri;

    uri = dropExtension(uri, mapping);
    if (uri == null) {
        return null;
    }

    parseNameAndNamespace(uri, mapping, configManager);
    handleSpecialParameters(request, mapping);
    extractMethodName(mapping, configManager);
    return parseActionName(mapping);
}

关键点如下:

使用 RequestUtils.getUri 获取 URI，前面介绍过这个方法，存在一定的可利用性；
手动删除分号，即删除最后一个分号及其之后的所有内容；
dropExtension 删除 URI 中的后缀，并设置 mapping.extension；
parseNameAndNamespace 负责设置设置 mapping.name 和 mapping.namespace；

parseNameAndNamespace 中通过遍历 Configuration#getPackageConfigs 里所有的 PackageConfig 配置，查找 URI 可能匹配的目标，然后获取其 namespace；而获取 actionName 的时候，是通过获取最后一个 / 之后的字符串作为名称，也就是说 URI / 之前的内容是不影响路由结果的:

// ...
if (!allowSlashesInActionNames) {
    int pos = actionName.lastIndexOf('/');
    if (pos > -1 && pos < actionName.length() - 1) {
        actionName = actionName.substring(pos + 1);
    }
}
mapping.setNamespace(cleanupNamespaceName(actionNamespace));
mapping.setName(cleanupActionName(actionName));

最后调用 setter 之前还调用了以下 cleanup 方法，这其中对名称进行了正则检查，以 cleanupActionName 为例:

protected String cleanupActionName(final String rawActionName) {
    if (allowedActionNames.matcher(rawActionName).matches()) {
        return rawActionName;
    } else {
        LOG.warn("{} did not match allowed action names {} - default action {} will be used!", rawActionName, allowedActionNames, defaultActionName);
        return defaultActionName;
    }
}

allowedActionNames 是 [a-zA-Z0-9._!/\-]*，对于不匹配的字符串，会直接返回默认的 defaultActionName，即 index。

handleSpecialParameters 使用前缀匹配请求参数的方式对一些特殊参数进行处理，主要是 org.apache.struts2.dispatcher.mapper.DefaultActionMapper 默认构造函数中注册的 action:* 以及 method:* 参数，用于调用自定义的 action 和方法。但是这两个默认配置都是不启用的，即便开启了动态调用，也需要开发者手动在中指定允许调用的方法名称。

parseActionName 中也有类似处理，如果支持动态方法(allowDynamicMethodCalls)，那么 actionName 可以是 foo!method 格式，通过感叹号指定要调用的方法。同时方法名通过 mapping.setMethod 进行设置。

ActionProxy

findActionMapping 提取出对应的 ActionMapping 信息之后，开始通过 executeAction 进行调用。回顾我们开头 404 页面返回的堆栈信息，可知在 ActionProxy.prepare 时进行实际 Controller(Action) 的查找。所谓 ActionProxy 实际是我们定义的 Action 的封装。

实际路由查找通过 DefaultConfiguration.RuntimeConfigurationImpl#getActionConfig 实现:

public ActionConfig getActionConfig(String namespace, String name) {
    ActionConfig config = findActionConfigInNamespace(namespace, name);

    // try wildcarded namespaces
    if (config == null) {
        NamespaceMatch match = namespaceMatcher.match(namespace);
        if (match != null) {
            config = findActionConfigInNamespace(match.getPattern(), name);

            // If config found, place all the matches found in the namespace processing in the action's parameters
            if (config != null) {
                config = new ActionConfig.Builder(config)
                        .addParams(match.getVariables())
                        .build();
            }
        }
    }

    // fail over to empty namespace
    if (config == null && StringUtils.isNotBlank(namespace)) {
        config = findActionConfigInNamespace("", name);
    }

    return config;
}

其中执行最终查找 ActionConfig 的方法是 findActionConfigInNamespace。注意上面的代码中依次有三种查找策略:

直接在 namespace 中精确查找 name；
如果没有找到，则判断是否定义正则匹配 patternMatcher，如果存在则使用模糊(正则)查找；
如果还没找到，则会在默认的空命名空间中查找。

在 Struts 官方文档中也有提及，见 Namespace Configuration 一节:

The default namespace is "" - an empty string. The default namespace is used as a “catch-all” namespace. If an action configuration is not found in a specified namespace, the default namespace is also be searched.

这个特性的目的是为了实现 local/global 的设计模式，即先查找局部路由实现，如果找不到就使用全局实现。注意这只是二阶段的查找，如果存在多级的命名空间如 /foo/bar/demo.action，在 /foo/bar 中查找不到 demo.action 后会直接跳到默认命名空间去查找，而不是跳到命名空间 /foo 进行查找。

private ActionConfig findActionConfigInNamespace(String namespace, String name) {
    ActionConfig config = null;
    if (namespace == null) {
        namespace = "";
    }
    Map<String, ActionConfig> actions = namespaceActionConfigs.get(namespace);
    if (actions != null) {
        config = actions.get(name);
        // Check wildcards
        if (config == null) {
            config = namespaceActionConfigMatchers.get(namespace).match(name);
            // fail over to default action
            if (config == null) {
                String defaultActionRef = namespaceConfigs.get(namespace);
                if (defaultActionRef != null) {
                    config = actions.get(defaultActionRef);
                }
            }
        }
    }
    return config;
}

这里主要是使用一个二级哈希表(namespaceActionConfigs)进行查找，其中第一级的 key 为 namespace，第二级的 key 则是实际路由的路径。

注意 namespaceActionConfigs 这个哈希表中包含 namespace 对应的所有 action，除了包含当前中定义的 action，还包括通过 extends 属性继承的父 package 中的所有 action。这也是一个路由的变异特性，后面我们介绍 Confluence 的 CVE-2023-22518 时会详细分析。

当然也不仅仅是哈希表的精确匹配，二级的 action 查找也支持使用 ActionConfigMatchers 去进行通配符匹配。ActionConfig 中包含了执行 action 所需要的所有信息，包括 Action 的类名、方法名、结果映射、拦截器列表等。

org.apache.struts2.dispatcher.Dispatcher#serviceAction 可以理解为分发请求的枢纽，获取到 ActionProxy 后负责进行调用并处理可能的异常结果:

    public void serviceAction(HttpServletRequest request, HttpServletResponse response, ActionMapping mapping)
        throws ServletException {
// ...
try {
    ActionProxy proxy = prepareActionProxy(extraContext, actionNamespace, actionName, actionMethod);
    if (mapping.getResult() != null) {
        Result result = mapping.getResult();
        result.execute(proxy.getInvocation());
    } else {
        proxy.execute();
    }

    } catch (ConfigurationException e) {
        logConfigurationException(request, e);
        sendError(request, response, HttpServletResponse.SC_NOT_FOUND, e);
    } catch (Exception e) {
        if (handleException || devMode) {
            if (devMode) {
                LOG.debug("Dispatcher serviceAction failed", e);
            }
            sendError(request, response, HttpServletResponse.SC_INTERNAL_SERVER_ERROR, e);
        } else {
            throw new ServletException(e);
        }
    }
}

在 DefaultActionInvocation#invoke 中进行了拦截器和 Action 的调用:

public String invoke() throws Exception {
    // ...
    if (interceptors.hasNext()) {
        // 见下节 ...
    } else {
        resultCode = invokeActionOnly();
    }
}

Interceptors 依次调用完后，后续会调用 invokeActionOnly 去调用我们实际的 Action，这里贴一下后续的调用栈，Register 为我们定义的 ActionSupport 示例:

execute:26, Register (org.apache.struts.register.action)
invoke0:-1, NativeMethodAccessorImpl (jdk.internal.reflect)
invoke:62, NativeMethodAccessorImpl (jdk.internal.reflect)
invoke:43, DelegatingMethodAccessorImpl (jdk.internal.reflect)
invoke:566, Method (java.lang.reflect)
invokeMethodInsideSandbox:1245, OgnlRuntime (ognl)
invokeMethod:1230, OgnlRuntime (ognl)
callAppropriateMethod:1958, OgnlRuntime (ognl)
callMethod:68, ObjectMethodAccessor (ognl)
callMethodWithDebugInfo:98, XWorkMethodAccessor (com.opensymphony.xwork2.ognl.accessor)
callMethod:90, XWorkMethodAccessor (com.opensymphony.xwork2.ognl.accessor)
callMethod:2034, OgnlRuntime (ognl)
getValueBody:97, ASTMethod (ognl)
evaluateGetValueBody:212, SimpleNode (ognl)
getValue:258, SimpleNode (ognl)
getValue:586, Ognl (ognl)
getValue:550, Ognl (ognl)
lambda$callMethod$2:593, OgnlUtil (com.opensymphony.xwork2.ognl)
execute:-1, 1400623756 (com.opensymphony.xwork2.ognl.OgnlUtil$$Lambda$300)
compileAndExecuteMethod:636, OgnlUtil (com.opensymphony.xwork2.ognl)
callMethod:593, OgnlUtil (com.opensymphony.xwork2.ognl)
invokeAction:434, DefaultActionInvocation (com.opensymphony.xwork2)
invokeActionOnly:307, DefaultActionInvocation (com.opensymphony.xwork2)
invoke:259, DefaultActionInvocation (com.opensymphony.xwork2)
// ...

值得一提的是，对于 Action 的调用，实际也是通过 OGNL 执行的:

protected String invokeAction(Object action, ActionConfig actionConfig) throws Exception {
    String methodName = proxy.getMethod();

    LOG.debug("Executing action method = {}", methodName);
    Object methodResult;
    methodResult = ognlUtil.callMethod(methodName + "()", getStack().getContext(), action);
    // ...
}

这样的好处是提供一定的灵活性，可以在配置文件中或者动态指定所要调用的 Action 方法，但同时也引入了一定的安全隐患。最初这里是使用 OgnlUtil::getValue() 来进行调用，在 S2-032、S2-033 和 S2-037 这几个漏洞之后才使用 callMethod 进行替换。callMethod 内部会执行 checkSimpleMethod 检查从而防止 OGNL 注入攻击，详见 CVE-2018-11776: How to find 5 RCEs in Apache Struts with CodeQL。

Interceptors

回顾本节开头的大图，在 ActionProxy 调用过程中，Interceptors(拦截器) 起到了重要的作用，关于拦截器的实现和作用可以参考官方的资料:

前文说过在 DefaultActionInvocation#invoke 中进行了拦截器和 Action 的调用:

public String invoke() throws Exception {
    // ...
    if (interceptors.hasNext()) {
        final InterceptorMapping interceptorMapping = interceptors.next();
        Interceptor interceptor = interceptorMapping.getInterceptor();
        if (interceptor instanceof WithLazyParams) {
            interceptor = lazyParamInjector.injectParams(interceptor, interceptorMapping.getParams(), invocationContext);
        }
        if (interceptor instanceof ConditionalInterceptor) {
            resultCode = executeConditional((ConditionalInterceptor) interceptor);
        } else {
            LOG.debug("Executing normal interceptor: {}", interceptorMapping.getName());
            resultCode = interceptor.intercept(this);
        }
    } else {
        resultCode = invokeActionOnly();
    }
}

Interceptors 依次调用完后，后续会调用 invokeActionOnly 去调用我们实际的 Action。

这里 interceptors 属性是个 InterceptorMapping 数组，只有三个关键属性:

public class InterceptorMapping implements Serializable {
    private String name;
    private Interceptor interceptor;
    private final Map<String, String> params;
}

一部分拦截器是开发者注册的，另外一部分则是 Struts 框架默认加入的，定义在 struts-default.xml 中。name 为拦截器的友好名称，params 则提供了一定程度上针对该拦截器的配置能力。

上述调用看似是循环，但实际上却使用的是递归，因为在 Interceptor 中为了实现分别在 action 之前和之后执行代码，会调用 ActionInvocation.invoke()，即 intercept() 的第一个参数，用于调用下一个拦截器或者是 Action。

以我们最常见的 ParametersInterceptor 为例，其继承自 MethodFilterInterceptor，最终会调用到下述 doIntercept 方法:

public String doIntercept(ActionInvocation invocation) throws Exception {
    // ...
    ActionContext ac = invocation.getInvocationContext();
    HttpParameters parameters = retrieveParameters(ac);
    if (parameters != null) {
        Map<String, Object> contextMap = ac.getContextMap();
        try {
            ReflectionContextState.setCreatingNullObjects(contextMap, true);
            ReflectionContextState.setDenyMethodExecution(contextMap, true);
            ReflectionContextState.setReportingConversionErrors(contextMap, true);

            ValueStack stack = ac.getValueStack();
            setParameters(action, stack, parameters);
        } finally {
            ReflectionContextState.setCreatingNullObjects(contextMap, false);
            ReflectionContextState.setDenyMethodExecution(contextMap, false);
            ReflectionContextState.setReportingConversionErrors(contextMap, false);
        }
    }
    return invocation.invoke();
}

setParameters 经过一系列调用，最终使用 ognl.Ognl#setValue 对请求上下文进行赋值，即通过请求参数实现调用 Action 中定义的 setter 设置对应 POJO 对象的值，从而完成从 HTTP 到 Java 的参数绑定。

// com.opensymphony.xwork2.ognl.OgnlUtil#setValue
public void setValue(final String name, final Map<String, Object> context, final Object root, final Object value) throws OgnlException {
    compileAndExecute(name, context, (OgnlTask<Void>) tree -> {
        if (isEvalExpression(tree, context)) {
            throw new OgnlException("Eval expression/chained expressions cannot be used as parameter name");
        }
        if (isArithmeticExpression(tree, context)) {
            throw new OgnlException("Arithmetic expressions cannot be used as parameter name");
        }
        Ognl.setValue(tree, context, root, value);
        return null;
    });
}

注意其中使用了 OGNL 作为参数绑定的实现，因此在参数名、参数值中都可能出现 OGNL 注入。相较之下 Spring Framework 则是通过反射来实现参数绑定，虽然代码实现更繁琐，但也确实更安全一些。

OGNL

Struts 在许多地方都用到了 OGNL 作为表达式去实现功能，历史上也出现过许多 OGNL 注入相关的漏洞。

除了修复漏洞点本身，Strtus 也对 OGNL 引擎做了一些拓展，比如实现 ognl.MemberAccess 为 SecurityMemberAccess 来管理 OGNL 的一些敏感操作。

关于 Struts OGNL 相关漏洞以及修复历史，已经有很多优秀的介绍文章了，感兴趣可以参考:

我们直接说现状，在当前版本中，SecurityMemberAccess 包含一系列黑名单来防止敏感类、包名的访问，同时配置禁止访问静态变量:

public class SecurityMemberAccess implements MemberAccess {
    private final boolean allowStaticFieldAccess;
    private Set<Pattern> excludeProperties = Collections.emptySet();
    private Set<Pattern> acceptProperties = Collections.emptySet();
    private Set<Class> excludedClasses = Collections.emptySet();
    private Set<Pattern> excludedPackageNamePatterns = Collections.emptySet();
    private Set<String> excludedPackageNames = Collections.emptySet();
    private Set<Class> excludedPackageExemptClasses = Collections.emptySet();
    private boolean disallowProxyMemberAccess;
    // ...
}

SecurityMemberAccess#isAccessible 中指定了访问的 member(Method) 限制:

禁止访问非 public 的 member；
禁止访问静态 field member，即静态属性，可通过 disallowProxyMemberAccess 配置；
禁止访问静态 method member，即静态方法；
检查 isClassExcluded 黑名单；
检查 isPackageExcluded 黑名单；
禁止访问 ProxyMember，可通过 disallowProxyMemberAccess 配置；

这些名单的设置是在 OgnlUtil#createDefaultContext 中:

protected Map<String, Object> createDefaultContext(Object root, ClassResolver classResolver) {
    ClassResolver resolver = classResolver;
    if (resolver == null) {
        resolver = container.getInstance(CompoundRootAccessor.class);
    }

    SecurityMemberAccess memberAccess = new SecurityMemberAccess(allowStaticFieldAccess);
    memberAccess.setDisallowProxyMemberAccess(disallowProxyMemberAccess);

    if (devMode) {
        if (!warnReported.get()) {
            warnReported.set(true);
            LOG.warn("Working in devMode, using devMode excluded classes and packages!");
        }
        memberAccess.setExcludedClasses(devModeExcludedClasses);
        memberAccess.setExcludedPackageNamePatterns(devModeExcludedPackageNamePatterns);
        memberAccess.setExcludedPackageNames(devModeExcludedPackageNames);
        memberAccess.setExcludedPackageExemptClasses(devModeExcludedPackageExemptClasses);
    } else {
        memberAccess.setExcludedClasses(excludedClasses);
        memberAccess.setExcludedPackageNamePatterns(excludedPackageNamePatterns);
        memberAccess.setExcludedPackageNames(excludedPackageNames);
        memberAccess.setExcludedPackageExemptClasses(excludedPackageExemptClasses);
    }

    return Ognl.createDefaultContext(root, memberAccess, resolver, defaultConverter);
}

调用时机是第一次使用 OgnlUtil 设置属性即应用启动并载入 struts.xml 中的 interceptors 的时候。这些列表的值通过属性定义在 struts 源码的配置文件中: core/src/main/resources/struts-excluded-classes.xml。例如 excludedClasses:

 name="struts.excludedClasses"
            value="
            java.lang.Object,
            java.lang.Runtime,
            java.lang.System,
            java.lang.Class,
            java.lang.ClassLoader,
            java.lang.Shutdown,
            java.lang.ProcessBuilder,
            java.lang.Thread,
            sun.misc.Unsafe,
            com.opensymphony.xwork2.ActionContext"/>

当然更严格的限制还是 excludedPackageNames，通过包名前缀去限制 OGNL 的访问。注意 excludedPackageNamePatterns 目前实际上是无用的，属于是历史遗留产物，因为前者现在已经替代了正则表达式的黑名单。

历史上的 OGNL 攻防花样百出，有尝试通过调用构造函数执行命令的，有尝试通过 OGNL 修改配置开启静态方法的，也有通过配置修改黑名单的，本质上还是想绕过上述 isAccessible 的限制。从目前的情况来看，Struts 对于 OGNL 的防御还是基于黑名单，那么是否能够完全防御代码注入攻击呢？这个就见仁见智了。

如果想要测试 Struts 的 OGNL 沙箱，可以在 struts.devMode 为 true 的情况下，直接通过请求任意路由加 debug 参数去执行 OGNL 代码:

curl 'http://localhost:8888/basic_struts_war/index.action' --data-raw 'debug=command&expression=3*4'

CVE-2023-22515

文章开头的时候说了，笔者研究 Struts 主要是因为最近碰到了 confluence 的这个漏洞。confluence 由 Atlassian 开发是一个知识库管理服务，支持本地部署，其 Web 框架主要基于 Struts 2。

关于该漏洞的详细分析可以参考下面的文章:

这里笔者对其中的细节就不过多复述了，而是结合 Struts 的特性来补充一些前置知识。

前面说过，Struts 中有许多 Interceptors 在 Action 前后会被进行调用，其中 ParametersInterceptor 尤为特殊，因为其会自动将 HTTP 的请求参数绑定到 Java bean 上，这是 XWork 框架的一大特性，但同时也带来了潜在的安全问题。因为这种情况下用户定义的 Action 中只要有 public getter 的属性都可能被 HTTP 请求进行访问和修改，甚至支持多级复杂的操作。

Confluence 的开发者作为 Struts 资深用户，自然早已知道这个问题，因此特地引入了 SafeParametersInterceptor 用于替换原始的 ParametersInterceptor。按照其设想，只有主动添加了 @ParameterSafe 的参数才能进行复杂操作，这个 annotation 可以加在 POJO 类的定义上，也可以加到 Action 中的 getter 上，比如:

@ParameterSafe
public FormData getFormData() { 
   return formData; 
}

或者:

@ParameterSafe
public class FormData {
   // ...
}

详见 XWork Plugin Complex Parameters and Security - Atlassian Developer。

只可惜，在近期的某个版本更新中，SafeParametersInterceptor 的实现出现了逻辑错误，导致参数过滤实际并不生效。因此攻击者通过查找合适的 Action，并且通过其中的 getter/setter 逐级访问，最终修改了重要的内存设置，使得攻击者可以成功发起添加管理员的请求。

虽然漏洞已经修复，但从中我们依然可以学习到一些重要的经验:

对于 Struts Action 公开 getter 属性所返回的对象要重点关注，尤其注意这些对象中带有的 setter 方法；
有些对象可能带有隐含的 getter 和 setter 方法，比如 Lombok 修饰的对象或者 Spring Bean 等，这类属性可能会被开发者忽略；
单元测试/回归测试很重要，如果 SafeParametersInterceptor 带有正确的单元测试，那将可以将这类严重的逻辑问题扼杀在摇篮中；

CVE-2023-22518

我们在前面分析 ActionProxy 查找时说到 namespaceActionConfigs 哈希表中包含 namespace 对应的所有 action，除了包含当前中定义的 action，还包括通过 extends 属性继承的父 package 中的所有 action。

例如，对于 CVE-2023-22518 漏洞而言，在 struts.xml 中有以下配置:

 name="default">
 name="setup" extends="default" namespace="/setup">
     name="setup-restore" class="com.atlassian.confluence.importexport.actions.SetupRestoreAction">
    

 name="admin" extends="setup" namespace="/admin">
     name="console" class="com.atlassian.confluence.admin.actions.AdministrationConsoleAction" method="doDefault">
    

 name="json" extends="admin" namespace="/json">

那么请求 /json/console 实际上可以路由到 /admin/console，而请求 /json/setup-restore 也可以路由到 /setup/setup-restore! 这显然不是开发者所预期的 URI 路径，因此如果鉴权时没有考虑这个场景，就有可能造成漏洞。

在本次更新中，对于这类问题的修复是增加了两个注解 @SystemAdminOnly 和 @WebSudoRequired，例如对于 SetupRestoreAction 的更新如下:

diff --git a/com/atlassian/confluence/importexport/actions/SetupRestoreAction.java b/com/atlassian/confluence/importexport/actions/SetupRestoreAction.java
index 8b64751..6c307ce 100644
--- a/com/atlassian/confluence/importexport/actions/SetupRestoreAction.java
+++ b/com/atlassian/confluence/importexport/actions/SetupRestoreAction.java
@@ -1,5 +1,6 @@
 package com.atlassian.confluence.importexport.actions;

+import com.atlassian.confluence.impl.security.SystemAdminOnly;
 import com.atlassian.confluence.importexport.DefaultImportContext;
 import com.atlassian.confluence.importexport.ImportExportException;
 import com.atlassian.confluence.importexport.impl.ExportDescriptor;
@@ -8,6 +9,7 @@ import com.atlassian.confluence.importexport.impl.UnexpectedImportZipFileContent
 import com.atlassian.confluence.tenant.OpenTenantGateLongRunningTask;
 import com.atlassian.confluence.util.HtmlUtil;
 import com.atlassian.core.task.longrunning.LongRunningTask;
+import com.atlassian.sal.api.websudo.WebSudoRequired;
 import com.atlassian.xwork.HttpMethod;
 import com.atlassian.xwork.PermittedMethods;
 import com.atlassian.xwork.RequireSecurityToken;
@@ -16,6 +18,8 @@ import org.slf4j.Logger;
 import org.slf4j.LoggerFactory;

 @Deprecated
+@WebSudoRequired
+@SystemAdminOnly
 public class SetupRestoreAction extends RestoreAction {
    private static final Logger log = LoggerFactory.getLogger(SetupRestoreAction.class);

当然还有很多其他的 Action 也做了修复，关于该漏洞的细节比如 Confluence 的鉴权实现和漏洞利用流程，可以参考其他的文章，本文仅讨论 Struts 本身。除了上面这类继承导致的路由错配，还有前面说过的默认命名空间作为兜底也会匹配其他命名空间找不到的 action，这对自己实现 URI 鉴权的开发者而言是一个需要注意的陷阱。

Debugging Tips

前面大致介绍了 Struts 的内部实现，从中我们可以通过对框架的深入理解来给日常的工作进行提效。例如在对基于 Struts 的应用进行安全审计时，一个常见的任务是获取所有路由列表。根据前面的分析，我们有两个地方可以选择，一是在 PrepareOperations.findActionMapping 初步查找映射时，二是在 Dispatcher.prepareActionProxy 实际获取 ActionProxy 的时候。

这二者本质上都是从 ConfigurationManager 获取到实际的配置:

configManager.getConfiguration().getPackageConfigs()

getPackageConfigs 返回的 Map 对应每个 PackageConfig 及其名称。PackageConfig 表示的是 XML 配置中标签内的所有内容，其中就包括路由映射和拦截器配置等信息。其中一些 getter 定义如下:

getActionConfigs() - 返回 ActionConfig 列表即所有的路由信息；
getAllActionConfigs() - 同上，但同时包含父结点的路由信息；
getInterceptorConfigs()、getAllInterceptorConfigs() - 返回所有拦截器信息；
getNamespace() - 返回命名空间，在路由 URI 的前半部分，以最后一个 / 分隔，为空表示默认命名空间；
…

因此，只要能够获得 com.opensymphony.xwork2.config.Configuration 实例就能获取所有的 PackageConfig 信息，从而获得所有路由和拦截器信息。

Struts2 实际查找路由的实现是在下面的方法中:

com.opensymphony.xwork2.config.impl.DefaultConfiguration.RuntimeConfigurationImpl#getActionConfig

因此调试时候如果不确定请求的路由对应哪个 Action，可以在这里进行动态分析。

后记

一开始只是想要分析一下近期出现的 Confluence 漏洞 CVE-2023-22515 和 CVE-2023-22518，但分析过程中发现有许多 Struts 相关的知识点并不了解，因此就从头开始学习了一遍 Struts 的文档和部分源码实现。虽然现在该框架在新项目中使用不多，但也有一些亮眼的地方，比如拦截器的架构和参数绑定的功能，这些设计思想在许多后继者如 SpringMVC 中也继续发扬光大；但也有一些弊病比如强依赖 OGNL 和迷之路由查找也导致了许多安全问题，也许这就是其日渐衰落的原因吧。

Reference

EoF

版权声明: 自由转载-非商用-非衍生-保持署名 (CC 4.0 BY-SA)
原文地址: https://evilpan.com/2023/11/01/struts2-internal/
微信订阅: 『有价值炮灰』
– TO BE CONTINUED.

Fuzzing 在 Java 漏洞挖掘中的应用

Sat, 09 Sep 2023 12:40:00 +0800

前段时间泛微发布了 10.58.6 补丁，修复好几个笔者之前储备的 0day，本文就来介绍其中一系列比较有意思的漏洞，以及分享一下相关的挖掘思路。

背景

最近几个月笔者都在研究 Java Web 方向，一方面是工作职责的调整，另一方面也想挑战一下新的领域。对于漏洞挖掘而言，选择一个具体目标是非常重要的，经过一段时间供应链和生态的学习以及同事建议，兼顾漏洞挖掘难度和实战效果选择了泛微OA作为第一个漏洞挖掘的目标。

代码审计

虽然本文介绍的是 Fuzzing，但之前也说过很多次，自动化漏洞挖掘只能作为一种辅助手段，是基于自身对代码结构的理解基础上的提效方式。

在真正开始挖漏洞之前，笔者花了好几周的时间去熟悉目标的代码，并且对一些不清晰的动态调用去进行运行时分析，最终才能在 20G 代码之中梳理出大致的鉴权和路由流程。

本文介绍的就是其中红框中的漏洞

通过分析 JavaEE 应用注册的路由，注意到其中一个映射:

ServletMapping[url-pattern=/services/*, name=XFireServlet] ^/services(?=/)|^/services\z]

其对应的类为 org.codehaus.xfire.transport.http.XFireConfigurableServlet:


    XFireServlet
    XFire Servlet
    org.codehaus.xfire.transport.http.XFireConfigurableServlet


    XFireServlet
    /services/*

XFire 考古

XFire 并不是泛微自己的业务代码，而是一个 SOAP Web 服务框架，它是作为 Apache Axis 的有效替代方案而开发的。除了通过使用 StAX 实现良好性能的目标外，XFire 的目标还包括通过各种插件机制实现灵活性，API 的直观操作以及与通用标准的兼容性。此外 XFire 非常适合集成到基于 Spring Framework 的项目中。

值得一提的是，XFire 目前已经不再进行开发，其官方继任者是 Apache CXF。

XFire 的用法比较简单，首先在 META-INF/xfire/services.xml 中定义需要导出的服务，比如:



 xmlns="http://xfire.codehaus.org/config/1.0">
    
        WorkflowService
        webservices.services.weaver.com.cn
        weaver.workflow.webservices.WorkflowService
        weaver.workflow.webservices.WorkflowServiceImpl
        org.codehaus.xfire.annotations.AnnotationServiceFactory

这样 weaver.workflow.webservices.WorkflowService 就被认为是导出服务。

可以直接被客户端进行调用。调用方式主要是通过 SOAP 请求到 XFireServlet，例如调用上述服务可以发送 POST 请求到 /services/WorkflowService:


  
    
evilpan
2333

表示以指定参数调用服务的 getUserId 方法。

SQL 注入

接下来回到漏洞本身，WorkflowService 服务的具体实现为 WorkflowServiceImpl，例如其中的 getUserId 就是服务导出的一个方法，其具体实现为:

@Override
public String getUserId(String var1, String var2) {
    if (Util.null2String(var2).equals("")) {
        return "-1";
    } else if (Util.null2String(var1).equals("")) {
        return "-2";
    } else {
        RecordSet var3 = new RecordSet();
        var3.executeQuery("select id from HrmResource where " + var1 + "=? and status<4 ", var2);
        return !var3.next() ? "0" : Util.null2s(var3.getString("id"), "0");
    }
}

可以看到，一个教科书式的 SQL 注入就已经找到了。

Service 鉴权

现在漏洞点找到了，触发路径也找到了，可实际测试的时候发现这个接口有些特殊的鉴权，其鉴权逻辑为判断请求地址是否是内网地址，如果是的话就放行。

考虑到很多系统是集群部署的，且前面有一层或者多层负载均衡，因此实际请求服务的可能是经过反向代理的请求，此时客户端的真实 IP 只能通过 X-Forward-For 等头部获取。

这本来无可厚非，但是 HTTP 请求头是可以被攻击者任意设置的，因此泛微在此基础上进行了复杂的过滤，精简后的伪代码如下:

private String getRemoteAddrProxy() {
    String ip = null;
    String tmpIp = null;
    tmpIp = this.getRealIp(this.request.getHeaders("RemoteIp"), ipList);
    if (ip == null || ip.length() == 0 || "unknown".equalsIgnoreCase(ip)) {
        ip = tmpIp;
    }
    boolean isInternalIp = IpUtils.internalIp(ip);
    if (isInternalIp) {
    ipList.add(this.request.getRemoteAddr());
    tmpIp = IpUtils.getRealIp(ipList);
    if (!IpUtils.internalIp(tmpIp)) {
        ip = tmpIp;
    }
    }

    return ip != null && ip.length() != 0 && !"unknown".equalsIgnoreCase(ip) ? ip : null;
}

IpUtils#internalIp 的判断更为复杂，连 byte[] 都出来了:

public static boolean internalIp(String ip) {
    if (ip != null && !ip.equals("127.0.0.1") && !ip.equals("::1") && !ip.equals("0:0:0:0:0:0:0:1")) {
    if (ip.indexOf(":") != -1 && ip.indexOf(":") == ip.lastIndexOf(":")) {
        ip = ip.substring(0, ip.indexOf(":"));
    }

    byte[] addr = (byte[])null;
    if (isIpV4(ip)) {
        addr = textToNumericFormatV4(ip.trim());
    } else {
        addr = textToNumericFormatV6(ip.trim());
    }

    return addr == null ? false : internalIp(addr);
    } else {
    return true;
    }
}

public static boolean internalIp(byte[] addr) {
  byte b0 = addr[0];
  byte b1 = addr[1];
  byte SECTION_1 = true;
  byte SECTION_2 = true;
  byte SECTION_3 = true;
  byte SECTION_4 = true;
  byte SECTION_5 = true;
  byte SECTION_6 = true;
  switch (b0) {
    case -84:
      if (b1 >= 16 && b1 <= 31) {
        return true;
      }
    case -64:
      switch (b1) {
        case -88:
          return true;
      }
    default:
      return false;
    case 10:
      return true;
  }
}

其逻辑是对 getRemoteAddrProxy 取出来的 IP，如果路径匹配 webserviceList 且 IP 匹配 webserviceIpList 前缀，就认为是内网地址的请求从而进行放过:

webserviceList = [
   "/online/syncOnlineData.jsp",
   "/services/",
   "/system/MobileLicenseOperation.jsp",
   "/system/PluginLicenseOperation.jsp",
   "/system/InPluginLicense.jsp",
   "/system/InMobileLicense.jsp"
];

webserviceIpList = [
   "localhost",
   "127.0.0.1",
   "192.168.",
   "10.",
   "172.16.",
   "172.17.",
   "172.18.",
   "172.19.",
   "172.20.",
   "172.21.",
   "172.22.",
   "172.23.",
   "172.24.",
   "172.25.",
   "172.26.",
   "172.27.",
   "172.28.",
   "172.29.",
   "172.30.",
   "172.31."
]

根据上面的代码，你能发现鉴权绕过的漏洞吗？

Fuzzing

也许对代码比较敏感的审计人员可以通过上述鉴权代码很快发现问题，但说实话我一开始并没有找到漏洞。于是我想到这个鉴权逻辑是否能单独抽离出来使用 Fuzzing 的思路去进行自动化测试。

之前发现 Java 也有一个基于 libFuzzer 的模糊测试框架 Jazzer，但是试用之后发现比较鸡肋，因为和二进制程序会自动 Crash 不同，Java 的 fuzz 需要自己指定 Sink，令其在触达的时候抛出异常来构造崩溃。

虽然说没法发现通用的漏洞，但是对于现在这个场景来说正好是绝配，我们可以将目标原始的鉴权代码抠出来，然后在未授权通过的时候抛出一个异常即可。构建的 Test Harness 代码如下:

public static void fuzzerTestOneInput(FuzzedDataProvider data) {
    String poc = data.consumeRemainingAsString();
    fuzzIP(poc);
}

public static void fuzzIP(String poc) {
    if (containsNonPrintable(poc)) return;
    XssRequestWeblogic x = new XssRequestWeblogic();
    String out = x.getRemoteAddr(poc);
    boolean check2 = check2(out);
    if (check2) {
        throw new FuzzerSecurityIssueHigh("Found IP [" + poc + "]");
    }
}

public static boolean check2(String ipstr) {
    for (String ip: webserviceIpList) {
        if (ipstr.startsWith(ip)) {
            return true;
        }
    }
    return false;
}

其中精简了一些泛微代码中读取配置相关的依赖，将无关的逻辑进行手动剔除。

编译好代码后，使用以下命令开始进行 fuzz:

$ ./jazzer --cp=target/Test-1.0-SNAPSHOT.jar --target_class=org.example.App

不多一会儿，就已经有了一个成功的结果！

可以看到图中给出了 127.0.0.10 这个 payload，可以触发 IP 鉴权的绕过！反过来分析这个 PoC，可以发现之所以能绕过是因为 webserviceIpList 只检查了前缀，而 127.0.0.10 可以在 internalIp 返回 False，即认为不是内部 IP，但实际上 webserviceIpList 却认为是内部 IP，从而导致了绕过。

如果只是从代码上去分析的话，可能一时半会并不一定能发现这个问题，可是通过 Fuzzing 在覆盖率反馈的加持下，却可以在几秒钟之内找到正解，这也是人工审计无法比拟的。

漏洞补丁

通过 IP 的鉴权绕过和 XFire 组件的 SQL 注入，笔者实现了多套前台的攻击路径，并且在 HW 中成功打入多个目标。因为当时提交的报告中带了漏洞细节，因此这个漏洞自然也就被官方修补了。如果没有公开的话这个洞短期也不太会被撞到。

漏洞修复的关键补丁如下:

diff --git a/src/weaver/security/webcontainer/IpUtils.java b/src/weaver/security/webcontainer/IpUtils.java
index 6b3d8efc..e7482511 100644
--- a/src/weaver/security/webcontainer/IpUtils.java
+++ b/src/weaver/security/webcontainer/IpUtils.java
@@ -48,12 +48,16 @@ public class IpUtils {
    }

    public static boolean internalIp(String ip) {
-      if (ip != null && !ip.equals("127.0.0.1") && !ip.equals("::1") && !ip.equals("0:0:0:0:0:0:0:1")) {
+      if (ip == null || ip.equals("127.0.0.1") || ip.equals("::1") || ip.equals("0:0:0:0:0:0:0:1")) {
+         return true;
+      } else if (ip.startsWith("127.0.0.")) {
+         return true;
+      } else {
          if (ip.indexOf(":") != -1 && ip.indexOf(":") == ip.lastIndexOf(":")) {
             ip = ip.substring(0, ip.indexOf(":"));
          }

其中把 equals 换成了 startsWith，并且还过滤了我们之前使用的 WorkflowService 组件。当然还是沿袭泛微一贯的漏洞修复原则，不改业务代码，只增加安全校验，这也是对历史遗留问题的一种妥协吧。

总结

对于 Java 这样的内存安全编程语言也是可以 fuzz 的，只不过目的是找出逻辑漏洞而不是内存破坏；
漏洞挖掘初期花时间投入到代码审计中是有必要的，有助于理解项目整体结构并在后期进行针对性覆盖；
漏洞挖掘的时候重点关注边界的系统和服务，处于信任边界之外的组件更有可能过于信任外部输入导致安全问题；
对于看起来很复杂的数据处理模块，可以充分利用 Fuzzing 的优势，帮助我们快速找出畸形的 payload；
模块化 Fuzzing 的难点在于抽离代码并构建可编译或者可以独立运行的程序，即构建 Test Harness，跑起来测试用例你就已经成功了 90%；
软件开发和漏洞挖掘正好相反。开发者会出于厌恶情绪刻意避开复杂的历史遗留代码，而这些代码却是更可能出现问题的地方。因此安全研究员要学会克服自己的厌恶情绪，做到 —— “明知山有屎，偏向屎山行”。

版权声明: 自由转载-非商用-非衍生-保持署名 (CC 4.0 BY-SA)
原文地址: https://evilpan.com/2023/09/09/java-fuzzing/
微信订阅: 『有价值炮灰』
– TO BE CONTINUED.

URL 解析与鉴权中的陷阱 —— Spring 篇

Sat, 19 Aug 2023 12:40:00 +0800

在上一篇文章中介绍了 Java Web 应用中 URL 解析与鉴权认证中的常见陷阱，但主要针对 Servlet 容器进行分析。前文末尾也提到了，当前 Web 应用多是使用 Spring 全家桶进行开发，其路由匹配方式又与传统 Web 容器有所差异，因此本文就对其进行分析。

DispatcherServlet

新建一个 Spring 项目，通过 start.spring.io 去勾选需要的依赖，然后下载 Maven 或者 Gradle 的工程目录文件，在其中添加自己的业务代码去构建应用。在本节中主要使用 spring-boot-starter-web 为起始工程进行代码编写和分析。

国内用户可以通过 start.springboot.io 镜像进行加速。

默认的项目使用的是 Tomcat 作为 Servlet 容器，因此我们可以利用前一篇文章的知识去快速定位容器中的路由情况。在 org.apache.catalina.mapper.Mapper#internalMapWrapper 中打下断点，查看所有已经注册的 Servlet，发现 exactWrappers、wildcardWrappers、extensionWrappers 等都为空数组，因此路由时会进入到 defaultWrapper，其对应类名为 org.springframework.web.servlet.DispatcherServlet。

我写了个简单的 Controller，如下所示:

@RestController
@RequestMapping("/bind")
public class BinderController {
    @GetMapping("str")
    String bindString(String p) {
        return "Bind: " + p;
    }
}

在 bindString 中下断点，触发后查看调用栈，截取前半部分如下:

bindString:25, BinderController (com.example.springbootdemo)
invoke0:-1, NativeMethodAccessorImpl (jdk.internal.reflect)
invoke:77, NativeMethodAccessorImpl (jdk.internal.reflect)
invoke:43, DelegatingMethodAccessorImpl (jdk.internal.reflect)
invoke:568, Method (java.lang.reflect)
doInvoke:207, InvocableHandlerMethod (org.springframework.web.method.support)
invokeForRequest:152, InvocableHandlerMethod (org.springframework.web.method.support)
invokeAndHandle:118, ServletInvocableHandlerMethod (org.springframework.web.servlet.mvc.method.annotation)
invokeHandlerMethod:884, RequestMappingHandlerAdapter (org.springframework.web.servlet.mvc.method.annotation)
handleInternal:797, RequestMappingHandlerAdapter (org.springframework.web.servlet.mvc.method.annotation)
handle:87, AbstractHandlerMethodAdapter (org.springframework.web.servlet.mvc.method)
doDispatch:1081, DispatcherServlet (org.springframework.web.servlet)
doService:974, DispatcherServlet (org.springframework.web.servlet)
processRequest:1011, FrameworkServlet (org.springframework.web.servlet)
doGet:903, FrameworkServlet (org.springframework.web.servlet)
service:564, HttpServlet (jakarta.servlet.http)
service:885, FrameworkServlet (org.springframework.web.servlet)
service:658, HttpServlet (jakarta.servlet.http)
// ...

DispatcherServlet 继承自 FrameworkServlet，实现了标准的 Java EE Servlet 接口，因此最初是调用到了 HttpServlet 的 service 方法接口。实际预处理请求以及路由(分发)的方法为 doService，关键代码如下:

protected void doService(HttpServletRequest request, HttpServletResponse response) throws Exception {
    logRequest(request);
    // ...
    if (this.parseRequestPath) {
		previousRequestPath = (RequestPath) request.getAttribute(ServletRequestPathUtils.PATH_ATTRIBUTE);
		ServletRequestPathUtils.parseAndCache(request);
	}
	try {
		doDispatch(request, response);
	}
    // ...
}

parseAndCache 中对使用 setAttribute 保存请求 URL:

public static RequestPath parseAndCache(HttpServletRequest request) {
    RequestPath requestPath = ServletRequestPath.parse(request);
    request.setAttribute(PATH_ATTRIBUTE, requestPath);
    return requestPath;
}

属性的 key 为 PATH_ATTRIBUTE，对应字符串是 org.springframework.web.util.ServletRequestPathUtils.PATH，在后面 doDispatch 进行路由查找的时候使用 getAttribute 获取对应 URL 再进行查找。

在实际调试的时候发现，如果一次 HTTP 请求出错的话，doService 会调用两次，这是因为 Spring 在遇到错误时会将 response 设置为错误返回，然后 Tomcat 会根据配置的自定义错误页面进行再次分发，相应的逻辑在 org.apache.catalina.core.StandardHostValve#invoke:

public void invoke(Request request, Response response) throws IOException, ServletException {
    // ...
    if (!response.isErrorReportRequired()) {
        context.getPipeline().getFirst().invoke(request, response); // 第一次调用
    }
    response.setSuspended(false);
    Throwable t = (Throwable) request.getAttribute(RequestDispatcher.ERROR_EXCEPTION);
    // Look for (and render if found) an application level error page
    if (response.isErrorReportRequired()) {
        // If an error has occurred that prevents further I/O, don't waste time
        // producing an error report that will never be read
        AtomicBoolean result = new AtomicBoolean(false);
        response.getCoyoteResponse().action(ActionCode.IS_IO_ALLOWED, result);
        if (result.get()) {
            if (t != null) {
                throwable(request, response, t);
            } else {
                status(request, response); // 第二次调用
            }
        }
    }
}

错误请求的路由是 /error，因此在第二次请求时会看到 getRequestURI 返回的就是 /error。

doDispatch

DispatcherServlet#doDispatch 的核心简化实现如下:

protected void doDispatch(HttpServletRequest request, HttpServletResponse response) throws Exception {
    processedRequest = checkMultipart(request);
    HandlerExecutionChain mappedHandler = getHandler(processedRequest);
    if (mappedHandler == null) {
        noHandlerFound(processedRequest, response);
        return;
    }
    HandlerAdapter ha = getHandlerAdapter(mappedHandler.getHandler());
    ModelAndView mv = ha.handle(processedRequest, response, mappedHandler.getHandler());
    processDispatchResult(processedRequest, response, mappedHandler, mv, dispatchException);
}

关键步骤就是三步:

查找 handler；
查找 HandlerAdapter；
调用 handler；

这里介绍下背景知识。在 Spring 中提供了多种定义路由的方法，每一类方法可以使用一个 HandlerMapping 表示，该接口通过 getHandler 获取具体的业务代码对象。

public interface HandlerMapping {
	HandlerExecutionChain getHandler(HttpServletRequest request) throws Exception;
}

handler 对象封装在 HandlerExecutionChain 类中，其类型是通用的 Object 类。封装类中还包含可选的 HandlerInterceptor 数组，用于给开发者自定义在 handler 之前执行的代码，比如认证或者语言/主题的设置等。

实际调用 handler 即用户定义路由需要通过 HandlerAdapter 实现。这样做的目的主要是为了让 DispatcherServlet 代码中无需知晓 handler 的具体类型，从而具备可拓展的抽象能力。

public interface HandlerAdapter {
    boolean supports(Object handler);
	ModelAndView handle(HttpServletRequest request, HttpServletResponse response, Object handler) throws Exception;
}

handle 接口通过将 handler 转换成实际的类型并进行调用，将结果统一返回为 ModelAndView 类型，然后根据需要进行渲染并将结果写入到 response 完成响应提交的返回。

HandlerMapping

可见，获取对应 HandlerMapping 是路由的重要一步，DispatcherServlet#getHandler 的实现就是从 this.handlerMappings 数组中依次遍历并调用 mapping.getHandler，如果返回不为空则返回对应的 handler 对象。

protected HandlerExecutionChain getHandler(HttpServletRequest request) throws Exception {
    if (this.handlerMappings != null) {
        for (HandlerMapping mapping : this.handlerMappings) {
            HandlerExecutionChain handler = mapping.getHandler(request);
            if (handler != null) {
                return handler;
            }
        }
    }
    return null;
}

handlerMappings 数组中包含多个 HandlerMapping 的实现，根据开发者具体定义的路由确定。这里测试时注册的映射有以下这些:

这些映射都是 AbstractHandlerMapping 的子类，在基类中实现了 getHandler 接口，实际返回的 handler 如果是字符串类型则认为是 Bean 的名称，否则认为是实际的 handler:

public final HandlerExecutionChain getHandler(HttpServletRequest request) throws Exception {
    Object handler = getHandlerInternal(request);
	if (handler == null) {
		handler = getDefaultHandler();
	}
	if (handler == null) {
		return null;
	}
	// Bean name or resolved handler?
	if (handler instanceof String handlerName) {
		handler = obtainApplicationContext().getBean(handlerName);
	}
	HandlerExecutionChain executionChain = getHandlerExecutionChain(handler, request);
	return executionChain;
}

大致的类结构如下所示，每个版本略有不同，仅作参考:

在基类中最终会调用到 lookupHandler:

protected Object lookupHandler(
		RequestPath path, String lookupPath, HttpServletRequest request) throws Exception {

	Object handler = getDirectMatch(lookupPath, request);
	if (handler != null) {
		return handler;
	}

	// Pattern match?
	List<PathPattern> matches = null;
	for (PathPattern pattern : this.pathPatternHandlerMap.keySet()) {
		if (pattern.matches(path.pathWithinApplication())) {
			matches = (matches != null ? matches : new ArrayList<>());
			matches.add(pattern);
		}
	}
	if (matches == null) {
		return null;
	}
	if (matches.size() > 1) {
		matches.sort(PathPattern.SPECIFICITY_COMPARATOR);
		if (logger.isTraceEnabled()) {
			logger.trace("Matching patterns " + matches);
		}
	}
	PathPattern pattern = matches.get(0);
	handler = this.pathPatternHandlerMap.get(pattern);
	if (handler instanceof String handlerName) {
		handler = obtainApplicationContext().getBean(handlerName);
	}
	validateHandler(handler, request);
	String pathWithinMapping = pattern.extractPathWithinPattern(path.pathWithinApplication()).value();
	pathWithinMapping = UrlPathHelper.defaultInstance.removeSemicolonContent(pathWithinMapping);
	return buildPathExposingHandler(handler, pattern.getPatternString(), pathWithinMapping, null);
}

总结:

先使用 getDirectMatch 进行直接匹配，查找 this.handlerMap 中的路由；
后使用模式匹配，依次匹配 this.pathPatternHandlerMap 中的路由，具体匹配方法见下节；
查找完成后对所有匹配进行排序，选出最佳匹配的 handler 进行返回；

由于注册的路由大多数都继承自 AbstractHandlerMapping，因此如果我们想要在运行时查看目标 Spring 应用的所有路由，可以首先断点在 DispatcherServlet#doDispatch，然后遍历其中的 this.handlerMappings，最后读取每个 mapping 中的 handlerMap 和 pathPatternHandlerMap 属性，即可枚举出所有的路由 Pattern。

PathPattern

不同的 HandlerMapping 针对不同的映射类型。主要分为两大类:

AbstractHandlerMethodMapping: 用于将请求映射到 HandlerMethod；
AbstractUrlHandlerMapping: 用于针对 URL 的映射，比如精确匹配或者模式匹配(PathPattern、AntPathMatcher)，多个匹配满足时采用最优(最长)匹配的结果；

一些具体的实现包括但不限于:

WebMvcEndpointHandlerMapping: 将请求映射到 Spring MVC 控制器方法，用于 Spring Actuator 的端点，如 /actuator/health 和 /actuator/info 等；之所以有这个映射是因为项目中使用了 actuator 模块 (spring-boot-starter-actuator)；
ControllerEndpointHandlerMapping: 同上，也是 actuator 中的；
RequestMappingHandlerMapping: 查找使用 @Controller 修饰的类中的 @RequestMapping 方法，返回方法级别的映射；
SimpleUrlHandlerMapping: 将 URL 映射到 Bean 实例或者 Bean 的名称；
BeanNameUrlHandlerMapping: 将 URL 映射到以 / 开头的 bean，类似于 Struts 将 URL 映射到 action；

我们关心的是 URL 路径到 Handler 的路由或者说匹配规则，因此还需要选择其中几个实现进行深入的跟踪。

以前面定义的 /bind/str 路由为例，其调用路径较深，经过一顿 F7 之后最终可以看到使用 PathPattern.matches 进行匹配，调用栈如下:

matches:42, SeparatorPathElement (org.springframework.web.util.pattern)
matches:216, PathPattern (org.springframework.web.util.pattern)
getMatchingPatterns:203, PathPatternsRequestCondition (org.springframework.web.servlet.mvc.condition)
getMatchingCondition:195, PathPatternsRequestCondition (org.springframework.web.servlet.mvc.condition)
getMatchingCondition:397, RequestMappingInfo (org.springframework.web.servlet.mvc.method)
getMatchingMapping:110, RequestMappingInfoHandlerMapping (org.springframework.web.servlet.mvc.method)
getMatchingMapping:68, RequestMappingInfoHandlerMapping (org.springframework.web.servlet.mvc.method)
addMatchingMappings:447, AbstractHandlerMethodMapping (org.springframework.web.servlet.handler)
lookupHandlerMethod:407, AbstractHandlerMethodMapping (org.springframework.web.servlet.handler)
getHandlerInternal:382, AbstractHandlerMethodMapping (org.springframework.web.servlet.handler)
getHandlerInternal:126, RequestMappingInfoHandlerMapping (org.springframework.web.servlet.mvc.method)
getHandlerInternal:68, RequestMappingInfoHandlerMapping (org.springframework.web.servlet.mvc.method)
getHandler:505, AbstractHandlerMapping (org.springframework.web.servlet.handler)
getHandler:1275, DispatcherServlet (org.springframework.web.servlet)

PathPattern 是以斜杠 / 为间隔的路径模式，遵循以下规则:

? 匹配单个字符；
* 匹配单个路径段(path segment)之间的零个或者多个字符；
** 匹配零个或者多个路径段，直至路径结尾；
{spring}: 匹配一个路径段并且捕捉该段保存为变量 “spring”；
{spring:[a-z]+}: 同上，但要求路径段满足正则表达式 [a-z]+；
{*spring}: 类似于 **，但将匹配的路径段保存为变量 “spring”；

其规则类似于与我们之前介绍 Shiro 时用的 Ant 风格路径匹配(Ant Style Path Matcher)。

Ant 指的是最早在 Apache Ant 使用的匹配方法，不同于正则表达式，主要是为了实现 JavaEE Servlet 的路径匹配规则。

PathPattern 内部包含一个 PathElement 格式的 head 属性，以双链表的形式保存了所有路径段和分隔符，head 指向路径的开头即 SeparatorPathElement Separator(/)。

public boolean matches(PathContainer pathContainer) {
    if (this.head == null) {
        return !hasLength(pathContainer) ||
            (this.matchOptionalTrailingSeparator && pathContainerIsJustSeparator(pathContainer));
    }
    else if (!hasLength(pathContainer)) {
        if (this.head instanceof WildcardTheRestPathElement || this.head instanceof CaptureTheRestPathElement) {
            pathContainer = EMPTY_PATH; // Will allow CaptureTheRest to bind the variable to empty
        }
        else {
            return false;
        }
    }
    MatchingContext matchingContext = new MatchingContext(pathContainer, false);
    return this.head.matches(0, matchingContext);
}

head.matches 不断匹配下一级路径或者分隔符(this.next)，并调用其 matches 方法进行匹配。head 即 SeparatorPathElement 的实现如下:

public boolean matches(int pathIndex, MatchingContext matchingContext) {
    if (pathIndex < matchingContext.pathLength && matchingContext.isSeparator(pathIndex)) {
        if (isNoMorePattern()) {
            if (matchingContext.determineRemainingPath) {
                matchingContext.remainingPathIndex = pathIndex + 1;
                return true;
            }
            else {
                return (pathIndex + 1 == matchingContext.pathLength);
            }
        }
        else {
            pathIndex++;
            return (this.next != null && this.next.matches(pathIndex, matchingContext));
        }
    }
    return false;
}

其他的 PathElement 接口实现包括:

org.springframework.web.util.pattern.SeparatorPathElement
org.springframework.web.util.pattern.WildcardPathElement
org.springframework.web.util.pattern.SingleCharWildcardedPathElement
org.springframework.web.util.pattern.WildcardTheRestPathElement
org.springframework.web.util.pattern.CaptureVariablePathElement
org.springframework.web.util.pattern.CaptureTheRestPathElement
org.springframework.web.util.pattern.LiteralPathElement
org.springframework.web.util.pattern.RegexPathElement

比如 /foo 就包含一个 SeparatorPathElement 和一个 LiteralPathElement，后者的 value 为 foo。LiteralPathElement 的实现如下:

public boolean matches(int pathIndex, MatchingContext matchingContext) {
    if (pathIndex >= matchingContext.pathLength) {
        // no more path left to match this element
        return false;
    }
    Element element = matchingContext.pathElements.get(pathIndex);
    if (!(element instanceof PathSegment pathSegment)) {
        return false;
    }
    String value = pathSegment.valueToMatch();
    if (value.length() != this.len) {
        // Not enough data to match this path element
        return false;
    }

    if (this.caseSensitive) {
        if (!this.text.equals(value)) {
            return false;
        }
    }
    pathIndex++;
    // ...
    return (this.next != null && this.next.matches(pathIndex, matchingContext));
}

其他的 PathElement 都有不同实现，这里就不一一介绍了。

PathContainer 也是类似的数据结构，其中 elements 数组中包含了所有解析的路径段和分隔符，类型为 Element；对于路径段使用子接口 PathSegment 表示，拥有返回路径参数以及解码路径值的能力。

interface PathSegment extends Element {

    /**
     * Return the path segment value, decoded and sanitized, for path matching.
     */
    String valueToMatch();
    char[] valueToMatchAsChars();

    /**
     * Path parameters associated with this path segment.
     * @return an unmodifiable map containing the parameters
     */
    MultiValueMap<String, String> parameters();
}

从中我们可以看出路径匹配的算法:

应用启动时解析所有的 Controller 等各种路由映射，将其以 PathPattern 的格式存储在不同 HandlerMapping 中；
收到请求时，DispatcherServlet 会将请求路径解析为 PathContainer，将路径中的元素(Path Element)保存到列表中，元素包含路径分隔符和每一级路径的内容；其中路径内容使用 PathSegment 表示，其 valueToMatch 返回的是不带路径参数且 URL 解码后的内容，精确匹配时会使用 String.equals 进行对比；
实际比较时，PathContainer 会被封装成 MatchingContext，包括当前比对的位置等信息，方便使用 .next 遍历链表时保存比较的上下文信息；
路径比对会从表头开始，依次调用 next.matches，直至最后一级，此时 next 为 null；

就 RequestMappingHandlerMapping 而言，我们能够针对路径做的变异如下，假设原始路径为 /api/flag:

/api/%66%6C%61%67: 基于 valueToMatch 返回 URL 解码后的的 segment 值；
/api;a=b/flag: 基于 valueToMatch 返回不包含路径参数的值；

注意 /api/./flag 或者 /api/../api/flag 这种请求时无法路由到目标 Handler 的，因为匹配时会将 dot-segment 当成一般的路径去进行精确匹配，因此只能路由到 @GetMapping("/./flag) 对应的 Handler 上。

参考资料:

ResourceHttpRequestHandler

对于常规 Servlet 容器，在所有定义的路由都无法匹配时，会尝试从磁盘文件或者 jar 中的资源文件进行匹配，即所说的 DefaultServlet。Spring MVC 也有类似的行为，当前面所有的 HadlerMapping 都找不到匹配时，会尝试查找对应的资源文件，负责处理这部分操作的是最后一个 SimpleUrlHandlerMapping，其 beanName 为 resourceHandlerMapping。

其中的 pathPatternHandlerMap 默认包含两个 PathPattern，分别是:

/webjars/** -> ResourceHttpRequestHandler [classpath [META-INF/resources/webjars/]]
/** -> ResourceHttpRequestHandler [classpath [META-INF/resources/], classpath [resources/], classpath [static/], classpath [public/], ServletContext [/]]

/** 是一个 PathElement，称为 WildcardTheRestPathElement，用于匹配所有 / 开头的路径。

最后调用 handler 的是 HttpRequestHandlerAdapter，实现比较简单，就是直接调用 handler.handleRequest:

public ModelAndView handle(HttpServletRequest request, HttpServletResponse response, Object handler)
        throws Exception {

    ((HttpRequestHandler) handler).handleRequest(request, response);
    return null;
}

handleRequest

读取资源文件的 handleRequest 实现如下:

public void handleRequest(HttpServletRequest request, HttpServletResponse response)
        throws ServletException, IOException {
    // For very general mappings (e.g. "/") we need to check 404 first
    Resource resource = getResource(request);
    if (resource == null) {
        logger.debug("Resource not found");
        response.sendError(HttpServletResponse.SC_NOT_FOUND);
        return;
    }
    // Supported methods and required session
    checkRequest(request);
    // Header phase
	// Apply cache settings, if any
	// Check the media type for the resource
	// Content phase
	if (request.getHeader(HttpHeaders.RANGE) == null) {
        this.resourceHttpMessageConverter.write(resource, mediaType, outputMessage);
    } else {
        ServletServerHttpRequest inputMessage = new ServletServerHttpRequest(request);
        List<HttpRange> httpRanges = inputMessage.getHeaders().getRange();
        response.setStatus(HttpServletResponse.SC_PARTIAL_CONTENT);
        this.resourceRegionHttpMessageConverter.write(
        HttpRange.toResourceRegions(httpRanges, resource), mediaType, outputMessage);
    }
}

请求只支持 GET 和 OPTIONS 方法，并且支持 HTTP 缓存，对于未修改的资源可以返回 304；此外还有个值得注意的点是这里还支持了 HTTP Range 头，即从指定偏移开始读取文件。

资源分为两种，一种是 classpath resource，即 Jar 包中的文件，另一种是 ServletContext resource，即 Web 目录中的磁盘文件。是否能够定位到对应文件的关键是 getResource 是否能成功返回对于资源:

protected Resource getResource(HttpServletRequest request) throws IOException {
	String path = (String) request.getAttribute(HandlerMapping.PATH_WITHIN_HANDLER_MAPPING_ATTRIBUTE);
	if (path == null) {
		throw new IllegalStateException("Required request attribute '" +
				HandlerMapping.PATH_WITHIN_HANDLER_MAPPING_ATTRIBUTE + "' is not set");
	}

	path = processPath(path);
	if (!StringUtils.hasText(path) || isInvalidPath(path)) {
		return null;
	}
	if (isInvalidEncodedPath(path)) {
		return null;
	}

	Assert.state(this.resolverChain != null, "ResourceResolverChain not initialized.");
	Assert.state(this.transformerChain != null, "ResourceTransformerChain not initialized.");

	Resource resource = this.resolverChain.resolveResource(request, path, getLocations());
	if (resource != null) {
		resource = this.transformerChain.transform(request, resource);
	}
	return resource;
}

首先关注局部变量 path，该值是之前保存到属性中的。回顾之前 HandlerMapping 一节中 lookupHandler 的代码末尾。pathWithinMapping，这个参数会在 buildPathExposingHandler 中使用，最终会创建一个拦截器 PathExposingHandlerInterceptor，而这个拦截器会在 DispatcherServlet 中调用 handler 前调用，即 mappedHandler.applyPreHandle()。该拦截器会使用 request 的属性保存该 URL，且这个 URL 就是这里寻址资源时用到的 path 值:

String pathWithinMapping = pattern.extractPathWithinPattern(path.pathWithinApplication()).value();
pathWithinMapping = UrlPathHelper.defaultInstance.removeSemicolonContent(pathWithinMapping);
return buildPathExposingHandler(handler, pattern.getPatternString(), pathWithinMapping, null);

buildPathExposingHandler 中设置属性:

request.setAttribute(PATH_WITHIN_HANDLER_MAPPING_ATTRIBUTE, pathWithinMapping);

因此，这里的 path 会经过一部分预处理。

预处理

PathPattern#extractPathWithinPattern 中的处理方法还是从 path element 的维度去处理，如果其中有连续的分隔符会进行合并，随后会返回从第一个非分隔符的元素一直到最后一个非分隔符的元素，因此路径 /foo//bar/ 处理后会变成 foo/bar。

removeSemicolonContent 则是删除 URL 中的路径参数。

仅从这个预处理的代码片段来看，路径 /foo/;/bar 处理后依旧会保留连续的分隔符形成 foo//bar，当然具体影响还要看后续的处理代码。

processPath

在获得部分处理的路径后，会继续经过 processPath 过滤，代码如下:

protected String processPath(String path) {
    path = StringUtils.replace(path, "\\", "/");
    path = cleanDuplicateSlashes(path);
    return cleanLeadingSlash(path);
}
private String cleanLeadingSlash(String path) {
    boolean slash = false;
    for (int i = 0; i < path.length(); i++) {
        if (path.charAt(i) == '/') {
            slash = true;
        }
        else if (path.charAt(i) > ' ' && path.charAt(i) != 127) {
            if (i == 0 || (i == 1 && slash)) {
                return path;
            }
            return (slash ? "/" + path.substring(i) : path.substring(i));
        }
    }
    return (slash ? "/" : "");
}

将 \ 替换为了 /；
删除重复的 /，比如 //；
删除路径前部的 /，准确来说是所有 / 和控制符(00-1F, 7F)的组合；

注意 cleanLeadingSlash 的实现，会从第一个字符开始查找，直到找到第一个大于 \x20 且不等于 \x7F 的字符，返回此后的子字符串，根据期间是否出现过 / 来判断结果是否要在前方添加 /。

isInvalidPath

processPath 之后会判断路径是否为空且是否为合法的路径，判断方法为:

protected boolean isInvalidPath(String path) {
	if (path.contains("WEB-INF") || path.contains("META-INF")) {
		return true;
	}
	if (path.contains(":/")) {
		String relativePath = (path.charAt(0) == '/' ? path.substring(1) : path);
		if (ResourceUtils.isUrl(relativePath) || relativePath.startsWith("url:")) {
			return true;
        }
    }
	if (path.contains("..") && StringUtils.cleanPath(path).contains("../")) {
		return true;
    }
	return false;
}

其中对请求资源的路径做了几个限制:

不能包含 WEB-INF 或者 META-INF；
不能是 URL；
对于包含 .. 的路径，使用 cleanPath 不能再包含 ../；

ResourceUtils.isUrl 的实现的伪代码如下:

public static boolean isUrl(String resourceLocation) {
    if (resourceLocation.startsWith("classpath:")) {
        return true;
    }	
    try {
        new URL(location);
        return true;
    } catch (MalformedURLException ex) {
        return false;
    }
}

除了以 classpath: 开头的路径，其他都依赖于 java.net.URL 构造函数中的处理，即如果能成功调用 URL 的构造函数就认为是一个 URL。根据官方文档，URL 构造函数抛出异常的条件是:

if no protocol is specified, or an unknown protocol is found, or spec is null.

感觉这里还是有点操作空间的，比如从源码中对比一下 Spring 支持而 URL 不支持的协议。

StringUtils.cleanPath 的作用主要是将路径进行归一化，不过考虑到 path 可能包含特殊的协议头，要考虑的情况就变得相对复杂了:

public static String cleanPath(String path) {
	String normalizedPath = replace(path, WINDOWS_FOLDER_SEPARATOR, FOLDER_SEPARATOR);
	String pathToUse = normalizedPath;

    // 去除协议部分
	int prefixIndex = pathToUse.indexOf(':');
	String prefix = "";
	if (prefixIndex != -1) {
		prefix = pathToUse.substring(0, prefixIndex + 1);
		if (prefix.contains(FOLDER_SEPARATOR)) {
			prefix = "";
		}
		else {
			pathToUse = pathToUse.substring(prefixIndex + 1);
		}
	}
	if (pathToUse.startsWith(FOLDER_SEPARATOR)) {
		prefix = prefix + FOLDER_SEPARATOR;
		pathToUse = pathToUse.substring(1);
	}

    // 处理路径树
	String[] pathArray = delimitedListToStringArray(pathToUse, FOLDER_SEPARATOR);
	Deque<String> pathElements = new ArrayDeque<>(pathArray.length);
	int tops = 0;
	for (int i = pathArray.length - 1; i >= 0; i--) {
		String element = pathArray[i];
		if (".".equals(element)) {
			// Points to current directory - drop it.
		} else if ("..".equals(element)) {
			// Registering top path found.
			tops++;
		} else {
			if (tops > 0) {
				// Merging path element with element corresponding to top path.
				tops--;
			}
			else {
				// Normal path element found.
				pathElements.addFirst(element);
			}
		}
	}
	// All path elements stayed the same - shortcut
	if (pathArray.length == pathElements.size()) {
		return normalizedPath;
	}
	// Remaining top paths need to be retained.
	for (int i = 0; i < tops; i++) {
		pathElements.addFirst(TOP_PATH);
	}
	// If nothing else left, at least explicitly point to current path.
	if (pathElements.size() == 1 && pathElements.getLast().isEmpty() && !prefix.endsWith(FOLDER_SEPARATOR)) {
		pathElements.addFirst(CURRENT_PATH);
	}

	final String joined = collectionToDelimitedString(pathElements, FOLDER_SEPARATOR);
	// avoid string concatenation with empty prefix
	return prefix.isEmpty() ? joined : prefix + joined;
   }

cleanPath 中使用的算法是将路径以 / 分隔，并将列表从后往前进行处理，最后将列表重新组合成新的路径。值得注意的是该方法只是将路径中的 . 去除以及将路径中间的 .. 移动到前方，比如 foo/../../bar 会变成 ../bar，因此该方法的注释中也说了不能讲其作为安全校验来防止路径穿越。这也是为什么要对 cleanPath 之后的路径再次检查是否存在 ../ 的原因。这样过滤的好处是可以找出归一化后以 ../ 开头的路径，即目录穿越到 web 应用 context-root 之外的路径。

回顾 isInvalidPath 的实现，此时 path 虽然经过了一定的处理，但现在还是包含 URL 编码字符的，因此猜测这里并不是唯一的安全校验，否则可以被比较容易地绕过。不过从这个判断的实现上来看，我们可以学习到 Spring 对于资源请求的一些设计，比如支持 URL、classpath: 和 url: 格式的资源，以及 WEB-INF 路径中的文件被认为是敏感信息等。

isInvalidEncodedPath

接着看下一个判断，isInvalidEncodedPath，根据其实现正好验证了我们上节的猜想，即 path 如果包含 URL 编码，需要对解码后的路径再次进行安全判断:

private boolean isInvalidEncodedPath(String path) {
    if (path.contains("%")) {
        try {
            // Use URLDecoder (vs UriUtils) to preserve potentially decoded UTF-8 chars
            String decodedPath = URLDecoder.decode(path, StandardCharsets.UTF_8);
            if (isInvalidPath(decodedPath)) {
                return true;
            }
            decodedPath = processPath(decodedPath);
            if (isInvalidPath(decodedPath)) {
                return true;
            }
        }
        catch (IllegalArgumentException ex) {
            // May not be possible to decode...
        }
    }
    return false;
}

URL 解码后的路径进行了两次判断，第一次是针对解码后的原始 URL，第二次是 processPath 之后的 URL，判断和前面一样都是通过 isInvalidPath。

Resource

在经过一系列前置判断后，最后开始使用 resolveResource 查找资源。基于 getLocations() 返回的 classpath resource 或者 context resource 分别进行查找:

// org.springframework.web.servlet.resource.PathResourceResolver#getResource()
for (Resource location : locations) {
    String pathToUse = encodeOrDecodeIfNecessary(resourcePath, request, location);
    Resource resource = getResource(pathToUse, location);
    if (resource != null) {
        return resource;
    }
}

encodeOrDecodeIfNecessary 对请求的路径进行了 URL 解码。当然主要取决于对应请求的 HandlerMapper 配置，对于大部分映射而言只要请求使用 PathContainer 封装就需要进行解码；在一些特殊的 HandlerMapper 中可能会已经对请求进行解码，因此这里反而会需要进行编码。

getResource 使用 Resource.createRelative 获取指定资源文件，并且在获取到后还使用 checkResource 进行了额外的防御性检查:

protected Resource getResource(String resourcePath, Resource location) throws IOException {
    Resource resource = location.createRelative(resourcePath);
    if (resource.isReadable()) {
        if (checkResource(resource, location)) {
            return resource;
        }
        else if (logger.isWarnEnabled()) {
            Resource[] allowed = getAllowedLocations();
            logger.warn(LogFormatUtils.formatValue(
                "Resource path \"" + resourcePath + "\" was successfully resolved " +
                "but resource \"" + resource.getURL() + "\" is neither under " +
                "the current location \"" + location.getURL() + "\" nor under any of " +
                "the allowed locations " + (allowed != null ? Arrays.asList(allowed) : "[]"), -1, true));
        }
    }
    return null;
}

Resource 是 Spring 中一个真的资源的抽象接口，具有多种实现，包括前面介绍过的，比如:

ClassPathResource: 使用 Class.getResource 或者 ClassLoader.getResource 接口去读取对应文件；
ServletContextResource: 使用 ServletContext.getResource 或者 ServletContext.getRealPath 读取 web 应用目录下相对路径的文件；
FileSystemResource: 使用 java.io.File 接口读取磁盘文件；
…

每种资源的实现各不相同，但总的来说 createRelative 大都是通过 StringUtils.applyRelativePath(this.path, relativePath) 构造新的 Resource。

至于 checkResource 的实现这里就不展开了，除非你已经绕过了 getResource 之前对路径的重重校验。这里主要是进行防御性的检查，判断新的资源是否在原始资源目录之下，根据资源类型的不同可能会调用 getURL 或者 getPath 作为资源的路径，并使用 String.startsWith 对整理后的路径进行比较。

Bypass Tricks

通过上面对 Spring MVC 路由代码的分析可以看出，对于大多数 HandlerMethodMapping，Spring 使用 PathPattern 去进行路径匹配，类似于 Ant 风格的最优匹配方式，因此对指定路由的变异相比于 Tomcat 等 Web 容器而言会少很多；但是对于资源文件的路由则可以使用更多变种。

假设存在资源文件 resources/static/secret.txt，对应的路由是 /secret.txt，可以使用下面的变体:

/secret.txt/: 预处理时候会变成 secret.txt 删除前方以及末尾的分隔符；
/;/secret.txt: 预处理时候删除连续的分隔符，和 // 的差别是处理阶段不同；
/secret.txt;a=b: 预处理时候会删除路径参数；
\secret.txt: 基于 processPath 中将 \ 替换成 / 的变异；
//secret.txt: 基于 cleanDuplicateSlashes 的变异，因此前面遗留的连续分隔符不会影响；
/ / // secret.txt: 基于 cleanLeadingSlash 的变异；
/secret.%74%78%74: 寻找文件前会通过 encodeOrDecodeIfNecessary 进行 URL 解码；
/foo/.././/secret.txt: createRelative 中会组合路径，并将其当做最终路径；

这些路径变异方式可以组合进行使用，从而根据需要构造出更加复杂的变异。当然值得注意的是其中某些变异可能会在 Web 容器就被拦截，比如 Tomcat 在碰到路径中包含(未编码的)空格时会直接返回 400 错误。

Spring Security

前面详细分析了 Spring MVC 的路由实现，在实际的 Spring 应用中通常配套使用 Spring-Security 作为认证和鉴权方案，因此本节将二者结合起来看，以加深对鉴权逻辑的理解。另外也会分析一些历史上出现过的 Spring Security 鉴权绕过漏洞，结合实际案例进行分析。

如无特别说明，本节使用的安全配置代码如下:

@Configuration
@EnableWebSecurity
public class SecurityConfig {
    @Bean
    public SecurityFilterChain securityFilterChain(HttpSecurity http) throws Exception {
        http.csrf().disable()
                .authorizeHttpRequests((requests) -> requests
                        .requestMatchers("/secret.txt").hasRole("USER")
                        .requestMatchers("/api/flag").hasRole("USER")
                        .requestMatchers("/**").permitAll()
                )
                .formLogin((form) -> form
                        .loginPage("/login").permitAll()
                )
                .logout(LogoutConfigurer::permitAll);
        return http.build();
    }
}

本文使用的版本是 spring-security-web 6.0.3

通用防御

首先构造一个简单的变异 /api/flag;xxx 进行请求后发现结果直接返回 400，在 DispatcherServlet 中直接看到请求的是 /error 界面。因此猜测在 Spring Security 引入的某个 Filter 中拦截了请求。

调试方式还是在 org.apache.catalina.core.ApplicationFilterChain#internalDoFilter 中遍历每个 filter 时进行断点，最终发现在 org.springframework.web.filter.DelegatingFilterProxy#doFilter 中触发了 response.setError，从而跳出循环并查找自定义错误页面进行输出。

在 org.springframework.security.web.FilterChainProxy#doFilter 中内部抛出了异常并被捕捉，异常类的详细信息如下:

org.springframework.security.web.firewall.RequestRejectedException: The request was rejected because the URL contained a potentially malicious String ";"
	at org.springframework.security.web.firewall.StrictHttpFirewall.rejectedBlocklistedUrls(StrictHttpFirewall.java:535)
	at org.springframework.security.web.firewall.StrictHttpFirewall.getFirewalledRequest(StrictHttpFirewall.java:505)
	at org.springframework.security.web.FilterChainProxy.doFilterInternal(FilterChainProxy.java:211)
	at org.springframework.security.web.FilterChainProxy.doFilter(FilterChainProxy.java:191)
	at org.springframework.web.filter.DelegatingFilterProxy.invokeDelegate(DelegatingFilterProxy.java:352)
	at org.springframework.web.filter.DelegatingFilterProxy.doFilter(DelegatingFilterProxy.java:268)
	at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:174)
	at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:149)
	at org.springframework.web.filter.RequestContextFilter.doFilterInternal(RequestContextFilter.java:100)
	at org.springframework.web.filter.OncePerRequestFilter.doFilter(OncePerRequestFilter.java:116)

即核心在于 StrictHttpFirewall 的拦截。下面是调用方的代码:

// org.springframework.security.web.FilterChainProxy
private void doFilterInternal(ServletRequest request, ServletResponse response, FilterChain chain)
		throws IOException, ServletException {
	FirewalledRequest firewallRequest = this.firewall.getFirewalledRequest((HttpServletRequest) request);
	HttpServletResponse firewallResponse = this.firewall.getFirewalledResponse((HttpServletResponse) response);
	List<Filter> filters = getFilters(firewallRequest);
	if (filters == null || filters.size() == 0) {
		if (logger.isTraceEnabled()) {
			logger.trace(LogMessage.of(() -> "No security for " + requestLine(firewallRequest)));
		}
		firewallRequest.reset();
		this.filterChainDecorator.decorate(chain).doFilter(firewallRequest, firewallResponse);
		return;
	}
	if (logger.isDebugEnabled()) {
		logger.debug(LogMessage.of(() -> "Securing " + requestLine(firewallRequest)));
	}
	FilterChain reset = (req, res) -> {
		if (logger.isDebugEnabled()) {
			logger.debug(LogMessage.of(() -> "Secured " + requestLine(firewallRequest)));
		}
		// Deactivate path stripping as we exit the security filter chain
		firewallRequest.reset();
		chain.doFilter(req, res);
	};
	this.filterChainDecorator.decorate(reset, filters).doFilter(firewallRequest, firewallResponse);
}

在请求 firewall.getFirewalledRequest 时抛出了异常:

public FirewalledRequest getFirewalledRequest(HttpServletRequest request) throws RequestRejectedException {
    rejectForbiddenHttpMethod(request);
    rejectedBlocklistedUrls(request);
    rejectedUntrustedHosts(request);
    if (!isNormalized(request)) {
        throw new RequestRejectedException("The request was rejected because the URL was not normalized.");
    }
    rejectNonPrintableAsciiCharactersInFieldName(request.getRequestURI(), "requestURI");
    return new StrictFirewalledRequest(request);
}

对于请求的拦截包括:

rejectForbiddenHttpMethod: 拦截非法的请求方法，默认允许的方法为 HEAD, DELETE, POST, GET, OPTIONS, PATCH, PUT 这 7 个；
rejectedBlocklistedUrls: 拦截 URL 中的特殊字符,
- encodedUrlBlocklist: //, \x00, %2F2F, %00, %25, \n, \r, %5C, %3B, %0A, %2E, %2F, %0D, ;, \;
- decodedUrlBlocklist: //, \x00, %2F2F, %00, %, \u2028, \u2029 \n, \r, %5C, %3B, %0A, %2F, %0D, ;, \;
rejectedUntrustedHosts: 拦截不可信的请求域名 (request.getServerName);
isNormalized: 拦截包含 ./, /../, /. 字符的路径；
rejectNonPrintableAsciiCharactersInFieldName: 拦截 getRequestURI 中包含不可打印字符的请求，即小于 \x20 或者大于 \x7e 的字符；

在 2 中两个 Blocklist 略有不同，二者都检查了 getContextPath 的值，但前者检查的是 getRequestURI，而后者检查的是 getPathInfo 的值；这里列举的字符我删除了一些大小写的变体，具体分类如下:

public StrictHttpFirewall() {
    urlBlocklistsAddAll(FORBIDDEN_SEMICOLON);
    urlBlocklistsAddAll(FORBIDDEN_FORWARDSLASH);
    urlBlocklistsAddAll(FORBIDDEN_DOUBLE_FORWARDSLASH);
    urlBlocklistsAddAll(FORBIDDEN_BACKSLASH);
    urlBlocklistsAddAll(FORBIDDEN_NULL);
    urlBlocklistsAddAll(FORBIDDEN_LF);
    urlBlocklistsAddAll(FORBIDDEN_CR);

    this.encodedUrlBlocklist.add(ENCODED_PERCENT);
    this.encodedUrlBlocklist.addAll(FORBIDDEN_ENCODED_PERIOD);
    this.decodedUrlBlocklist.add(PERCENT);
    this.decodedUrlBlocklist.addAll(FORBIDDEN_LINE_SEPARATOR);
    this.decodedUrlBlocklist.addAll(FORBIDDEN_PARAGRAPH_SEPARATOR);
}

在 4 中检查的路径包括 getRequestURI、getContextPath、getServletPath 以及 getPathInfo；

可见在当前版本的默认配置下，Spring Security 拦截了很多 URL 的变体，从而在后续鉴权检查的时候避免了许多潜在的绕过。其中大部分选项都可以配置关闭，比如使用 setAllowSemicolon 来允许分号(路径参数)，详见 StrictHttpFirewall 中的接口。一个重要的例外是 isNormalized 的检查无法关闭，官方文档中的解释是:

There is no way to disable this as it is considered extremely risky to disable this constraint. A few options to allow this behavior is to normalize the request prior to the firewall or using DefaultHttpFirewall instead. Please keep in mind that normalizing the request is fragile and why requests are rejected rather than normalized.

另外其实针对可打印字符的拦截也是无法关闭的，只不过这里的检查并没有考虑对这些字符 URL 编码的情况。

AuthorizationFilter

在本节开头的 SecurityConfig 中放了一个类型为 SecurityFilterChain 的 bean，并设置了以下规则:

.requestMatchers("/api/flag").hasRole("USER")

直接请求 /api/flag 会返回 302 跳转到配置的登录地址。想要分析这背后的原理可以和之前一样继续在 FilterChainProxy 中跟踪返回的每个 filter:

List<Filter> filters = getFilters(firewallRequest);

这里直接说结论，最终检查上述规则的 Filter 是 AuthorizationFilter，使用 AuthorizationManager#check 来对路径进行权限检查。

// org.springframework.security.web.access.intercept.AuthorizationFilter#doFilter
AuthorizationDecision decision = this.authorizationManager.check(this::getAuthentication, request);
this.eventPublisher.publishAuthorizationEvent(this::getAuthentication, request, decision);
if (decision != null && !decision.isGranted()) {
    throw new AccessDeniedException("Access Denied");
}
chain.doFilter(request, response);

AuthorizationDecision 只是 bool 的简单封装，保存 isGrant 即认证的结果是否通过。RequestMatcherDelegatingAuthorizationManager#check 的关键实现如下:

public AuthorizationDecision check(Supplier<Authentication> authentication, HttpServletRequest request) {
    this.logger.trace(LogMessage.format("Authorizing %s", request));
	for (RequestMatcherEntry<AuthorizationManager<RequestAuthorizationContext>> mapping : this.mappings) {
		RequestMatcher matcher = mapping.getRequestMatcher();
		MatchResult matchResult = matcher.matcher(request);
		if (matchResult.isMatch()) {
			AuthorizationManager<RequestAuthorizationContext> manager = mapping.getEntry();
            this.logger.trace(LogMessage.format("Checking authorization on %s using %s", request, manager));
			return manager.check(authentication,
					new RequestAuthorizationContext(request, matchResult.getVariables()));
		}
	}
    this.logger.trace(LogMessage.of(() -> "Denying request since did not find matching RequestMatcher"));
	return DENY;
}

this.mappings 保存了 RequestMatcherEntry 类型的列表，请求是否命中规则的判断使用 RequestMatcher#matcher 进行匹配，命中匹配后再使用 AuthorizationManager#check 判断权限是否满足，这里我们显然主要关注前者。

RequestMatcher 接口是 Spring Security 中用于匹配请求的关键接口，具体实现有 antMatchers、regexMatchers 等，这里 /api/flag 对应的是 MvcRequestMatcher，实现如下:

public MatchResult matcher(HttpServletRequest request) {
	if (notMatchMethodOrServletPath(request)) {
		return MatchResult.notMatch();
	}
	MatchableHandlerMapping mapping = getMapping(request);
	if (mapping == null) {
		return this.defaultMatcher.matcher(request);
	}
	RequestMatchResult result = mapping.match(request, this.pattern);
	return (result != null) ? MatchResult.match(result.extractUriTemplateVariables()) : MatchResult.notMatch();
}

其中实际使用了 org.springframework.web.servlet.handler.MatchableHandlerMapping 去进行路径匹配，这个类正是 Spring MVC 中使用的，该映射类通过内省的方式获取，因此避免了检查和路由不一致的问题，从而防止各种路径变异导致的绕过。当然只能说顶层设计是这样的，但具体实现可能依然有些阴暗的角落，这个可以从近期的一些案例中看到。

历史案例

在 Spring {Boot,Data,Security} 历史漏洞研究一文中提及到相关的漏洞，这里再深入分析一下。早期 Spring Security 的配置支持 antMatchers, mvcMatchers, 以及 regexMatchers 等多种路径匹配方式，但这些匹配方法多少还是和 Spring MVC 中的路由匹配规则是有差异的。

比如在 SEC-2534 漏洞中，Spring Security 的 antMatchers("/link") 配置与 Spring MVC 的 @RequestMapping("/link") 配置可以被 /link.html 绕过。

在 CVE-2016-5007 中，可以在路径中加入空格来绕过 Spring Security 的判断(早期 Spring Framework 使用 AntPathMatcher 可配置忽略空格且默认开启)。

在 CVE-2022-22975/CVE-2022-22978 中，基于正则表达式的 RegexRequestMatcher 在使用点号 . 比如 .* 时可以被换行符绕过。这是一个正则表达式常见的陷阱，一般使用 Pattern.DOTALL 来指明点号匹配包括换行符的所有字符。

这些漏洞的核心在于，Spring 框架对于路径匹配的规则提供了相比于 Spring Security 更加丰富的配置方法，而用户可以轻易地在二者之间开启不同的配置，导致二者不匹配产生鉴权绕过。针对这类问题，当时开发组提出了一种与 Spring MVC 对齐的匹配方法，即 MvcRequestMatcher。该类使用了 Spring MVC 中的 HandlerMappingIntrospector 来匹配路径和提取变量，从而根治了鉴权和路由不一致的问题。

在新版 Spring Security 的官方文档中也提到，建议开发者使用新的 requestMatcher 接口，并将历史接口的废弃提上日程:

In Spring Security 5.8, the antMatchers, mvcMatchers, and regexMatchers methods were deprecated in favor of new requestMatchers methods. https://docs.spring.io/spring-security/reference/5.8/migration/servlet/config.html

除此之外还有一些鸡肋漏洞，比如 Spring Security 与 WebFlux 的匹配，或者应用在使用 Spring 的基础上还使用了其他 Servlet，又或者是一些特殊配置下的鉴权绕过，这里就不展开介绍了。

参考资料:

Shiro

在前文中介绍了 Shiro 针对 Java EE 应用的基本配置以及 URL 路径的过滤和匹配代码实现。实际上在 Shiro 中 Spring 也是一等公民，有单独的配置选项，见: Integrating Apache Shiro into Spring-Boot Applications。

针对 Spring MVC 的路径鉴权匹配实现和针对一般 Java Web 应用的实现大同小异，回顾前文的代码片段:

// org.apache.shiro.web.filter.mgt.PathMatchingFilterChainResolver#getChain
final String requestURI = getPathWithinApplication(request);
final String requestURINoTrailingSlash = removeTrailingSlash(requestURI);
for (String pathPattern : filterChainManager.getChainNames()) {
  if (pathMatches(pathPattern, requestURI)) {
    return filterChainManager.proxy(originalChain, pathPattern);
  } else {
    // 针对 Spring Web 的处理
    pathPattern = removeTrailingSlash(pathPattern);
      if (pathMatches(pathPattern, requestURINoTrailingSlash)) {
        return filterChainManager.proxy(originalChain, pathPattern);
      }
  }
}

其中针对 Spring Web 会进行额外处理，即删除 pathPattern 中末尾的分隔符再进行一次比对。值得注意的是 getPathWithinApplication 中使用的路径并不是 getRequestURI 而是 getServletPath + getPathInfo，这几个常见路径的官方介绍如下:

getRequestURI: 原始 HTTP 请求路径部分在请求参数(即?)之前部分的内容，这是最原始的数据，包含原样的用户输入；
getContextPath: 对应 Context 的路径，即 Web 容器挂载对应应用的前缀；
getServletPath: 调用对应 Servlet 时的(相对)路径，不包含 Context 部分，且删除了路径参数；
getPathInfo: 额外设置的路径信息，默认为 null；

不管如何，Shiro 会尝试使用“干净”的路径去匹配鉴权规则，这在 Spring MVC 项目中与 Spring Security 比起来就多了很多潜在的鉴权路由不匹配风险。基本上 Spring Security 出现过的问题很可能也会在 Shiro 中出现。

比如，Spring Security 中 CVE-2016-5007，通过在路径添加空格的方式绕过鉴权，在 Shiro 中就有 CVE-2020-17510 和 CVE-2020-17523 等针对 AntPathMatcher 的绕过方式；

又比如，Spring Security 中 regexMatcher 正则表达式 DOTALL 问题导致的 CVE-2022-22978，在 Shiro 中也有几乎一样的 CVE-2022-32532，针对 RegExPatternMatcher 的绕过方式；

关于更多 Shiro 的历史漏洞介绍和分析，可以参考已有的优秀文章，比如 Shiro 历史漏洞分析。

总结

相比于传统的 JavaEE Web 应用，Spring 基于全匹配的 DispatcherServlet 实现了一套应用层的路由方案，并且在依赖注入的加持下使得业务开发和配置变得更加方便。这一套路由方案屏蔽了底层 Servlet 容器的解析差异，但同时也引入了 Spring 特有的解析陷阱。在不断的更新过程中，Spring Security 逐渐与 MVC 对齐，使用相同的路径匹配方法，从而避免鉴权和路由不一致的问题，但是 Shiro 就没那么幸运了，作为 “外拨秧” 缺乏官方的支持，只能寻求更为通用的解决方案，但未来这类不匹配的问题可能还是依旧会出现。

通过最近两篇文章针对 URL 路径鉴权的分析，对解析路径时会遇到的陷阱也算有了基本了解。虽然文章只介绍了 Java Web 生态的 URL 鉴权实现，但对于其他应用也是类似的。核心在于 TOCTOU 即判断和最终使用的变量不一致问题。这一类问题不仅出现在 Web 中，在二进制世界经常也是导致条件竞争、UAF 之类漏洞的元凶，值得我们在漏洞挖掘时重点关注。

参考链接

版权声明: 自由转载-非商用-非衍生-保持署名 (CC 4.0 BY-SA)
原文地址: https://evilpan.com/2023/08/19/url-gotchas-spring/
微信订阅: 『有价值炮灰』
– TO BE CONTINUED.

浅谈 URL 解析与鉴权中的陷阱

Sat, 29 Jul 2023 12:40:00 +0800

最近一段时间都在审计 Java 代码，也算是积累了一些各式各样小技巧，但总感觉不够体系化。因此有必要先停下来，跳出业务逻辑并后退一步，更加深入地思考一下漏洞背后的成因。

前言

说到 URL 解析，想必关注 Web 安全的朋友们都看过 Orange 那篇 A New Era of SSRF - Exploiting URL Parser in Trending Programming Languages，其中对不同语言中的 URL Parser 做了较为详尽的分析。该议题主要关注不同 Parser 处理 URL 时的域名部分，以实现针对 SSRF 的绕过和后利用。

本文的关注点则有所不同，主要是针对 URL 解析的路径部分。因为 URL 的路径部分通常涉及到资源和服务的路由，以及对应的鉴权校验。通常我们在漏洞挖掘和渗透测试时都收集过一些鉴权绕过的 “Tricks”，但很多时候并不了解其所以然，每每测试结束后总觉得缺少了些什么。这些绕过的 payload 是否覆盖了所有场景？是否还有其他可能的变种？其实也不能完全肯定。

因此就有了这篇文章，一方面记录和整理笔者遇到过的鉴权绕过技巧，另一方面也尝试分析这些绕过背后的原理，希望对大家有所启发。

威胁模型

本文主要以 JavaEE 的 Web 网络框架举例，这是因为 Java 目前在国内有着庞大的使用率和 Web 生态。不过我相信在许多其他 Web 框架下如 PHP、NodeJS 中也是可以举一反三的。

回顾 Java 安全研究初探一文中提到的 Java Web 应用的请求流程，大致可以抽象成如下的链路:

Client -> Filter_1 -> Filter_2 -> ... -> Filter_n -> Servlet

即客户端的请求会经过一个或者多个 Filter，然后再到达实际处理请求的 Servlet 中。通常 Filter 以级联方式运作，称为 FilterChain，而出于低耦合的设计模式考虑，开发者一般会将重要的鉴权逻辑放在 Filter 中实现。一旦认证失败，可以提前终止请求，这对于 Servlet 而言是透明的。

因此，所谓的鉴权绕过，很多情况下就是鉴权 Filter 中的逻辑错误。而 Filter 中的鉴权，大部分情况下也是 URL 粒度的鉴权，毕竟在一个网站中总是会有无需认证的前台界面(如登录界面)，以及需要认证的后台服务(如管理后台)。

从代码上看，Filter 中鉴权使用的多是 HttpServletRequest.getRequestURI() 接口，判断对应路径是否需要鉴权，如果需要则进行 Session 的判断和认证，对于鉴权失败的请求则返回 403 拒绝访问或者 302 跳转到登录界面。

绕过 Filter 中的 URL 的鉴权认证只是第一步，而更为重要的一步是如何在构造畸形 URL 的同时依然能寻址到正确的 Servlet，从而正确处理业务请求。因此本文也正是从这两方面出发，分别探寻 URL 解析中的隐秘。

Servlet 容器

首先要明确的是，不管构造的 URL 再怎么花里胡哨，如果 URL 路径寻址不到正确的 Servlet，那都是没有意义的，只能获得一个空虚的 404 聊以自慰。因此我们先从 Servlet 的寻址开始，尝试在正常寻址的基础上进行变异。

URL 的路由在不同的 Servlet 容器中的实现各不相同，这里仅选择两个笔者最近在看的容器去进行分析。

Tomcat

首先是最常见的 Tomcat 容器。关于 Tomcat 的源码分析在网上已经有过很多文章了，我们只需要关注其中 URL 到业务代码的路由映射过程。最简单的方式就是使用调试器在 Servlet 中打上一个断点去反向追踪源码的相关部分。业务代码如下:

@WebServlet(name = "flagServlet", value = "/api/flag")
public class FlagServlet extends HttpServlet {
    public void doGet(HttpServletRequest request, HttpServletResponse response) throws IOException {
        PrintWriter out = response.getWriter();
        out.println(String.format("YOU WIN: [%s]", request.getRequestURI()));
    }
}

在成功访问后返回请求的 RequestURI 的值。在 doGet 打个断点，请求 /api/flag 后触发的堆栈信息如下:

doGet:17, FlagServlet (com.example.tc)
service:529, HttpServlet (javax.servlet.http)
service:623, HttpServlet (javax.servlet.http)
internalDoFilter:209, ApplicationFilterChain (org.apache.catalina.core)
doFilter:153, ApplicationFilterChain (org.apache.catalina.core)
doFilter:51, WsFilter (org.apache.tomcat.websocket.server)
internalDoFilter:178, ApplicationFilterChain (org.apache.catalina.core)
doFilter:153, ApplicationFilterChain (org.apache.catalina.core)
doFilter:20, AdminFilter (com.example.tc)
doFilter:53, HttpFilter (javax.servlet.http)
internalDoFilter:178, ApplicationFilterChain (org.apache.catalina.core)
doFilter:153, ApplicationFilterChain (org.apache.catalina.core)
invoke:167, StandardWrapperValve (org.apache.catalina.core)
invoke:90, StandardContextValve (org.apache.catalina.core)
invoke:481, AuthenticatorBase (org.apache.catalina.authenticator)
invoke:130, StandardHostValve (org.apache.catalina.core)
invoke:93, ErrorReportValve (org.apache.catalina.valves)
invoke:673, AbstractAccessLogValve (org.apache.catalina.valves)
invoke:74, StandardEngineValve (org.apache.catalina.core)
service:343, CoyoteAdapter (org.apache.catalina.connector)
service:390, Http11Processor (org.apache.coyote.http11)
process:63, AbstractProcessorLight (org.apache.coyote)
process:926, AbstractProtocol$ConnectionHandler (org.apache.coyote)
doRun:1791, NioEndpoint$SocketProcessor (org.apache.tomcat.util.net)
run:52, SocketProcessorBase (org.apache.tomcat.util.net)
runWorker:1191, ThreadPoolExecutor (org.apache.tomcat.util.threads)
run:659, ThreadPoolExecutor$Worker (org.apache.tomcat.util.threads)
run:61, TaskThread$WrappingRunnable (org.apache.tomcat.util.threads)
run:829, Thread (java.lang)

注: 这里使用的 Tomcat 为 9.0.78 版本，是文章编写时 Tomcat9 的最新版本。之所以选择 Tomcat9 而不是 Tomcat10 是因为目前其存量应用相对较多(听说)。

CoyoteAdaptor

AdminFilter 是我自己写的一个 Filter，这里先无需在意。Tomcat 在进入第一个 FIlter 之前就已经确定了路由的目标。注意上述调用栈中的 CoyoteAdapter，实际方法为 org.apache.catalina.connector.CoyoteAdapter#service:

@Override
public void service(org.apache.coyote.Request req, org.apache.coyote.Response res) throws Exception {
    // ...
    postParseSuccess = postParseRequest(req, request, res, response);
    if (postParseSuccess) {
        // Calling the container
        connector.getService().getContainer().getPipeline().getFirst().invoke(request, response);
    }
}

postParseRequest 的调用时机是在 TCP 的 HTTP 请求头接收完之后，并且在 Body 读取之前，也正是在其中处理了 URL 的映射。在 Tomcat 中请求对应的路由是存放在 request.mappingData 中的。对于上述请求，会依次调用:

postParseRequest
org.apache.catalina.mapper.Mapper#map
org.apache.catalina.mapper.Mapper#internalMap

internalMap 的关键代码片段如下:

private void internalMap(CharChunk host, CharChunk uri, String version, MappingData mappingData) throws IOException {
    if (uri.isNull()) {
        // Can't map context or wrapper without a uri
        return;
    }
    uri.setLimit(-1);

    // Context mapping
    ContextList contextList = mappedHost.contextList;
    MappedContext[] contexts = contextList.contexts;
    int pos = find(contexts, uri);
    if (pos == -1) {
        return;
    }
    // Wrapper mapping
    if (!contextVersion.isPaused()) {
        internalMapWrapper(contextVersion, uri, mappingData);
    }

}

contexts 数组中包含一系列 org.apache.catalina.mapper.Mapper.MappedContext#MappedContext，表示 URL 路由的上下文，说简单点就是 URL 的前缀。一般一个 Context 前缀代表一个 JavaEE 应用，在 Tomcat 中其实还注册了几个默认的应用，对应的前缀(ContextRoot)分别是:

/docs
/examples
/manager
/host-manager

我们这次请求的 URI 为 /api/flag，且部署的 ContextRoot 为空，因此命中的就是我们的应用。一个完整的 URL 如下所示:

http://host:port/context-root[/url-pattern]

如果 ContextRoot 为 /demo 的话，示例的 Servlet 会映射到 /demo/api/flag。

Mapper

定位到 context 之后，接下来就是在对应 context 下查找具体的路由。这个过程称为 “Wrapper mapping”，Wrapper 可以理解为 Servlet 的封装。所调用的方法为 org.apache.catalina.mapper.Mapper#internalMapWrapper。

关键代码如下:

private void internalMapWrapper(ContextVersion contextVersion, CharChunk path, MappingData mappingData) throws IOException {
    // Rule 1 -- Exact Match
    MappedWrapper[] exactWrappers = contextVersion.exactWrappers;
    internalMapExactWrapper(exactWrappers, path, mappingData);
    // Rule 2 -- Prefix Match
    MappedWrapper[] wildcardWrappers = contextVersion.wildcardWrappers;
    if (mappingData.wrapper == null) {
        internalMapWildcardWrapper(wildcardWrappers, contextVersion.nesting, path, mappingData);
    }
    // Rule 3 -- Extension Match
    MappedWrapper[] extensionWrappers = contextVersion.extensionWrappers;
    if (mappingData.wrapper == null && !checkJspWelcomeFiles) {
        internalMapExtensionWrapper(extensionWrappers, path, mappingData, true);
    }
    // Rule 4 -- Welcome resources processing for servlets
        // Rule 4a -- Welcome resources processing for exact macth
        // Rule 4b -- Welcome resources processing for prefix match
        // Rule 4c -- Welcome resources processing

    /*
    * welcome file processing - take 2 Now that we have looked for welcome files with a physical backing, now look
    * for an extension mapping listed but may not have a physical backing to it. This is for the case of index.jsf,
    * index.do, etc. A watered down version of rule 4
    */

    // Rule 7 -- Default servlet
}

在深入代码之前，我们先插播一条关于 JavaEE Servlet 标准的回忆录。

Servlet 标准

在前面的文章也简单提到过，Servlet 映射查找是依据 JSR 340: Java Servlet 3.1 Specification 中的第 12 章 Mapping Requests to Servlets 的介绍而实现的。其中关键的寻址逻辑笔者总结如下:

首先尝试查找 Servlet 路由的 精确匹配；
递归查找最长前缀匹配，以 / 字符为每一级目录树的分隔，即前缀匹配的单位是目录；
如果 URL 路径的最后一个片段(Segment)包含后缀，容器会尝试使用后缀匹配对应的 Servlet，比如对于 .jsp 后缀使用 JspServlet；
如果上述规则都没有成功匹配，容器将会尝试根据请求的 URL 去匹配对应的资源，这通常会使用一个容器自带的默认 Servlet 去处理。

在标准中还提到了几个值得注意的点:

在匹配 ContextRoot 的时候也是使用最长前缀匹配；
在 URL 进行匹配时候都是 大小写敏感的；

对于配置映射的，有以下规则:

映射值以 / 开头且以 /* 结尾的用于前缀匹配映射；
映射值以 *. 开头的使用后缀匹配；
空字符是一个特殊的映射值，指向 context-root；
仅包含字符 / 的映射值表示对应应用的默认 Servlet；
其他所有的值都被认为是精确匹配；

因此，对于应用中定义的不同映射，都可以根据寻址逻辑按照顺序找到最佳的匹配。

Wrappers

回忆杀结束，继续回到上述 internalMapWrapper 的代码中。按照查找的顺序，Tomcat 会依次从下面的 Wrapper 中进行匹配:

exactWrappers: 用于精确匹配的 Wrapper，比如值为 /api/flag 的 FlagServlet；
wildcardWrappers: 用于(最长)前缀匹配的通配符 Wrapper，比如值为 /admin/* 的 Servlet；
extensionWrappers: 用于后缀匹配的 Wrapper，比如值为 *.txt 的 Servlet。在 Tomcat 中默认有两个，分别是 jsp 和 jspx，都对应 org.apache.jasper.servlet.JspServlet；
welcomeResources: 如果 URL 的最后一个字符是 /，则会尝试匹配欢迎页面，默认是 index.html、index.htm、index.jsp；对于没有物理文件的欢迎页面，比如 index.do、index.jsf 等，会根据后缀匹配的方式在内置资源文件中查找；
defaultWrapper: 在前面都没有匹配的情况下，使用 Tomcat 的默认 Servlet 去进行处理，对应类是 org.apache.catalina.servlets.DefaultServlet，用于请求磁盘文件或者 jar 包中的文件。

大体来说，每一个 Servlet 对应一个 Wrapper 实例，而根据 URL 查找 Wrapper 的过程也就是对应 Servlet 路由查找的过程。

decodeURI

值得注意的是，在进行 Wrapper 查找的时候，所使用的 uri 是已经进行过处理的，还是在 CoyoteAdapter#postParseRequest 方法中:

protected boolean postParseRequest(){
    MessageBytes decodedURI = req.decodedURI();
    // Parse (and strip out) the path parameters
    parsePathParameters(req, request);
    // URI decoding
    // %xx decoding of the URL
    req.getURLDecoder().convert(decodedURI.getByteChunk(),
            connector.getEncodedSolidusHandlingInternal());
    // Normalization
    if (normalize(req.decodedURI())) {
        // Character decoding
        convertURI(decodedURI, request);
    }
}

decodedURI 只是 req.decodedUriMB 的一个指针(引用)，在后续处理中有时没有直接指定 decodeURI 而是使用了 req 进行传参，但效果都是对 decodedURI 进行修改。

首先是第一步，parsePathParameters，该方法会解析 Path Parameter 即路径参数，后面介绍 URL 标准文档的时候会详细说到。路径参数是针对每一级 URL 目录的参数，形如 /api;a=b/flag;c=d，使用分号 ; 进行指定，并以等号 = 指定 key 和 value。解析路径参数之后会将其使用 Request.addPathParameter 加入到请求信息中，并且将其从 decodeURI 中删除。

第二步，URL Decode，正常的 URL 解码。

第三步，Normalization，主要针对 URL 中包含 “", “//”, “/./” 以及 “/../” 的情况，操作过程如下:

将 \ 替换为 /；
将 // 替换为 /；
对于 /. 或者 /.. 结尾的 URI，先在末尾额外添加一个 /；
递归解析 URI 中的 /./ 字符串，将其替换为 /；
递归解析 URI 中的 /../ 字符串，移动相应的目录；

在解析 /../ 时如果超出了根目录会直接返回 false。此外一些其他的错误也会返回 false，比如 CoyoteAdapter#ALLOW_BACKSLASH 为 false 却包含反斜杠，路径不以 / 或者 \ 开头等。

第四步，Character decoding，使用 convertURI 对路径进行字符解码。因为此时的路径还是以 ByteChunk 的格式进行存储的，这一步会将其转换为 CharChunk；

在依次经过上述处理后，最终的 URI 才会用来进行 Servlet 路由查找。

Bypass Tricks

据此，我们可以得到一系列 “Bypass Tricks”，即用不同的方式路由到同一个 Servlet 中，比如目标路由是 /api/flag 的话，以下请求都能寻址到目标:

/api;a=b/flag: 通过 Path Parameter 路径参数变异；
/api/%66%6C%61%67: 通过 URL 编码进行变异；
\api\flag: 通过 Normalization 1 变异，当前需要 Tomcat 配置 ALLOW_BACKSLASH 为 true；
//api/flag: 通过 Normalization 2/3 变异;
/api/./flag: 通过 Normalization 4 变异；
/foo/api/../api/flag: 通过 Normalization 5 变异；

这些变异方法可以相互组合进行使用，另外配合 DefaultServlet 针对磁盘文件和资源的路由也可以组合出其他的 URI。

Resin

虽然 Tomcat 相对常用，但实际场景中也有许多其他的 Web 容器实现。正所谓兼听则明，偏信则暗，因此这里选取另外一个 Web 容器 Resin 作为对比，看看二者对 URL 的处理和路由有何异同。之所以选择 Resin 只不过是因为笔者最近正好看到而已。

这里选择的 Resin 版本是 4.0.58

还是老方法，直接在 Servlet 中下断点，观察 Resin 的请求调用栈如下:

doGet:17, FlagServlet (com.example.resin)
service:120, HttpServlet (javax.servlet.http)
service:97, HttpServlet (javax.servlet.http)
doFilter:109, ServletFilterChain (com.caucho.server.dispatch)
doFilter:21, AdminFilter (com.example.resin)
doFilter:127, HttpFilter (javax.servlet.http)
doFilter:89, FilterFilterChain (com.caucho.server.dispatch)
doFilter:156, WebAppFilterChain (com.caucho.server.webapp)
doFilter:95, AccessLogFilterChain (com.caucho.server.webapp)
service:304, ServletInvocation (com.caucho.server.dispatch)
handleRequest:840, HttpRequest (com.caucho.server.http)
dispatchRequest:1367, TcpSocketLink (com.caucho.network.listen)
handleRequest:1323, TcpSocketLink (com.caucho.network.listen)
handleRequestsImpl:1307, TcpSocketLink (com.caucho.network.listen)
handleRequests:1215, TcpSocketLink (com.caucho.network.listen)
handleAcceptTaskImpl:1011, TcpSocketLink (com.caucho.network.listen)
runThread:117, ConnectionTask (com.caucho.network.listen)
run:93, ConnectionTask (com.caucho.network.listen)
handleTasks:175, SocketLinkThreadLauncher (com.caucho.network.listen)
run:61, TcpSocketAcceptThread (com.caucho.network.listen)
runTasks:173, ResinThread2 (com.caucho.env.thread2)
run:118, ResinThread2 (com.caucho.env.thread2)

前部分的调用为 FilterChain 调用，逐个调用已注册的 Filter。进入第一个 Filter 之前的调用为我们关心的路由解析完成之时。其方法为 com.caucho.server.http.HttpRequest#handleRequest，大致调用代码如下:

public boolean handleRequest() throws IOException {
  startRequest();
  if (! parseRequest()) {
      return false;
  }
  CharSequence host = getInvocationHost();
  Invocation invocation = getInvocation(host, _uri, _uriLength);

  startInvocation();
  invocation.service(requestFacade, getResponseFacade());
}

其中，startRequest 方法会读取 _uri、_headerKeys、_headerValues 等属性；parseRequest 将 buffer 中的请求方法、URI、HTTP 协议以及后续的 HTTP 头逐行解析并保存。

在 readRequest 即 HTTP 的第一行时读取 URI，有相关的代码片段:

// skip 'http:'
if (ch != '/') {
}
// read URI
while (! isHttpWhitespace[ch]) {
  uriBuffer[uriLength++] = (byte) ch;
  if (readTail <= readOffset) {
    uriBuffer = _uri;
    uriLength = _uriLength;
}
  ch = readBuffer[readOffset++] & 0xff;
}

其中如果第一个字符不是 / 会跳到 URL 路径中进行读取。

Invocation

与 Tomcat 的 Wrapper 对应的数据结构在 Resin 中称为 Invocation，获得了 Invocation 也就获得了对应 Servlet 的路由映射。因此我们重点关注 getInvocation 方法的实现，调用过程如下:

com.caucho.server.http.AbstractHttpRequest#getInvocation
- com.caucho.server.dispatch.InvocationServer#getInvocation
- com.caucho.util.LruCache#get
com.caucho.server.http.AbstractHttpRequest#buildInvocation

简单来说，AbstractHttpRequest#getInvocation 会先尝试从 InvocationServer._invocationCache 缓存中获取 Invocation 对象，如果不存在则会使用 buildInvocation 新建一个并放入缓存中。_invocationCache 是个 LRU 缓存，键为 com.caucho.server.http.InvocationKey 类型。InvocationKey 中包含 host、port、uri 三元组以及 isSecure 标志位，这么做的好处是节约路由查找时间，对于大型项目而言路由映射往往成百上千，每次请求都进行查找显然比较耗时。

com.caucho.server.http.AbstractHttpRequest#buildInvocation
com.caucho.server.dispatch.InvocationDecoder#splitQueryAndUnescape

splitQueryAndUnescape 中对 Invocation 的 URI 进行了处理和赋值，代码比较重要，所以这里直接把完整的代码贴出来:

public void splitQueryAndUnescape(Invocation invocation,
                                  byte []rawURI, int uriLength)
  throws IOException
{
  for (int i = 0; i < uriLength; i++) {
    if (rawURI[i] == '?') {
      i++;

      // XXX: should be the host encoding?
      String queryString = byteToChar(rawURI, i, uriLength - i,
                                      "ISO-8859-1");
      invocation.setQueryString(queryString);

      uriLength = i - 1;
      break;
    }
  }

  String rawURIString = byteToChar(rawURI, 0, uriLength, "ISO-8859-1");
  invocation.setRawURI(rawURIString);

  String decodedURI = normalizeUriEscape(rawURI, 0, uriLength, _encoding);

  if (_sessionSuffix != null) {
    int p = decodedURI.indexOf(_sessionSuffix);

    if (p >= 0) {
      int suffixLength = _sessionSuffix.length();
      int tail = decodedURI.indexOf(';', p + suffixLength);
      String sessionId;

      if (tail > 0)
        sessionId = decodedURI.substring(p + suffixLength, tail);
      else
        sessionId = decodedURI.substring(p + suffixLength);

      decodedURI = decodedURI.substring(0, p);

      invocation.setSessionId(sessionId);

      p = rawURIString.indexOf(_sessionSuffix);
      if (p > 0) {
        rawURIString = rawURIString.substring(0, p);
        invocation.setRawURI(rawURIString);
      }
    }
  }
  else if (_sessionPrefix != null) {
    if (decodedURI.startsWith(_sessionPrefix)) {
      int prefixLength = _sessionPrefix.length();

      int tail = decodedURI.indexOf('/', prefixLength);
      String sessionId;

      if (tail > 0) {
        sessionId = decodedURI.substring(prefixLength, tail);
        decodedURI = decodedURI.substring(tail);
        invocation.setRawURI(rawURIString.substring(tail));
      }
      else {
        sessionId = decodedURI.substring(prefixLength);
        decodedURI = "/";
        invocation.setRawURI("/");
      }

      invocation.setSessionId(sessionId);
    }
  }

  String uri = normalizeUri(decodedURI);

  invocation.setURI(uri);
  invocation.setContextURI(uri);
}

提炼一下关键点，URI 的处理流程如下:

找到第一个 ? 符号并将之后的设置为 queryString；
normalizeUriEscape: 对路径进行 URI 解码；
sessionSuffix 提取: 如果 URI 末尾的路径参数是对应的后缀，则从中提取并设置 SessionID，默认的后缀是 ;jsessionid。注意此时 sessionid 参数及其之后的数据都会从 rawURI 中移除；
sessionPrefix 提取: 默认为空即不需要操作；
normalizeUri: 对路径进行归一化操作，后面细说；

normalizeUriEscape 的 URL 解码除了传统的 %dd 解码，还支持 Resin 特殊的 URL 编码，其实现如下:

private static int scanUriEscape(ByteToChar converter,
                                 byte []rawUri, int i, int len)
  throws IOException
{
  int ch1 = i < len ? (rawUri[i++] & 0xff) : -1;

  if (ch1 == 'u') {
    ch1 = i < len ? (rawUri[i++] & 0xff) : -1;
    int ch2 = i < len ? (rawUri[i++] & 0xff) : -1;
    int ch3 = i < len ? (rawUri[i++] & 0xff) : -1;
    int ch4 = i < len ? (rawUri[i++] & 0xff) : -1;

    converter.addChar((char) ((toHex(ch1) << 12) +
                              (toHex(ch2) << 8) + 
                              (toHex(ch3) << 4) + 
                              (toHex(ch4))));
  }
  else {
    int ch2 = i < len ? (rawUri[i++] & 0xff) : -1;

    int b = (toHex(ch1) << 4) + toHex(ch2);;

    converter.addByte(b);
  }

  return i;
}

即 %u0067 这种类型的解码。

注意这里处理完后的 URI 除了删除 jsessionid，依然带有其他的 Path Parameter 路径参数，这部分处理要在后面进行操作。不过在此之前还是按顺序先看 normalizeUri 的实现。

normalizeUri

从参数来看，InvocationDecoder.normalizeUri 的实现会根据当前 JVM 运行的操作系统来执行不同的归一化操作，由于这是我们 URI 变异的重点，因此直接将完整的方法实现贴出来:

public String normalizeUri(String uri, boolean isWindows)
  throws IOException
{
  CharBuffer cb = new CharBuffer();

  int len = uri.length();

  if (_maxURILength < len)
    throw new BadRequestException(L.l("The request contains an illegal URL because it is too long."));

  char ch;
  if (len == 0 || (ch = uri.charAt(0)) != '/' && ch != '\\')
    cb.append('/');

  for (int i = 0; i < len; i++) {
    ch = uri.charAt(i);

    if (ch == '/' || ch == '\\') {
    dots:
      while (i + 1 < len) {
        ch = uri.charAt(i + 1);

        if (ch == '/' || ch == '\\')
          i++;
        else if (ch != '.')
          break dots;
        else if (len <= i + 2
                 || (ch = uri.charAt(i + 2)) == '/' || ch == '\\') {
          i += 2;
        }
        else if (ch != '.')
          break dots;
        else if (len <= i + 3
                 || (ch = uri.charAt(i + 3)) == '/' || ch == '\\') {
          int j;

          for (j = cb.length() - 1; j >= 0; j--) {
            if ((ch = cb.charAt(j)) == '/' || ch == '\\')
              break;
          }
          if (j > 0)
            cb.setLength(j);
          else
            cb.setLength(0);
          i += 3;
        } else {
          throw new BadRequestException(L.l("The request contains an illegal URL."));
        }
      }

      while (isWindows && cb.getLength() > 0
             && ((ch = cb.getLastChar()) == '.' || ch == ' ')) {
        cb.setLength(cb.getLength() - 1);

        if (cb.getLength() > 0
            && (ch = cb.getLastChar()) == '/' || ch == '\\') {
          cb.setLength(cb.getLength() - 1);
          // server/003n
          continue;
        }
      }

      cb.append('/');
    }
    else if (ch == 0)
      throw new BadRequestException(L.l("The request contains an illegal URL."));
    else
      cb.append(ch);
  }

  while (isWindows && cb.getLength() > 0
         && ((ch = cb.getLastChar()) == '.' || ch == ' ')) {
    cb.setLength(cb.getLength() - 1);
  }

  return cb.toString();
}

如无特别说明则认为分隔符是 / 或者 \。这里实现路径归一化的算法是新建一个 CharBuffer，然后逐字符解析 URI，对于正常字符直接加入到 cb 中，而遇到分隔符后需要考虑特殊的情况。

首先如果 URI 首个字母不是分隔符，则会先在 cb 中添加 /；
对于遇到分隔符的情况:
1. 如果后 1 个字符还是分隔符，则往前进 2 个字符；
2. 如果后 2 个字符是 . + 分隔符，则往前进 2 个字符；
3. 如果后 3 个字符是 .. + 分隔符，则往前进 3 个字符，并且 cb 中回退一级目录，如果超出了根目录会将 cb 置空；如果后 2 个字符是 .. 但第 3 个字符不是分隔符，会直接抛异常；
4. 其他情况下 cb 中添加一个分隔符 /；但是在添加之前，对于 Windows 系统，如果 cb 中末尾的字符是 . 或者空格，会将其删除，同时会删除末尾的分隔符；
对于其他字符，直接加入 cb 中；
遍历完成后，对于 Windows 系统，删除 cb 中末尾的 . 和空格；

这里 normallize 方法的实现还是比较特别的，据此我们可以得到一些特殊的变异方式，具体在后文提及。

ServletMapper

前面获取到 Invocation 中的 URI 经过了 URL 解码和路径归一化，随后调用 InvocationServer#buildInvocation 获取对应 Server 的 Invocation 实例。最终会进入到 ServletMapper 的 mapServlet 进行 Servlet 映射查找。其中经过了 Host、Container 以及 WebApp 的查找，调用栈如下:

mapServlet:234, ServletMapper (com.caucho.server.dispatch)
buildInvocation:4154, WebApp (com.caucho.server.webapp)
buildInvocation:798, WebAppContainer (com.caucho.server.webapp)
buildInvocation:753, Host (com.caucho.server.host)
buildInvocation:319, HostContainer (com.caucho.server.host)
buildInvocation:1064, ServletService (com.caucho.server.cluster)
buildInvocation:250, InvocationServer (com.caucho.server.dispatch)
buildInvocation:223, InvocationServer (com.caucho.server.dispatch)
buildInvocation:1610, AbstractHttpRequest (com.caucho.server.http)
getInvocation:1583, AbstractHttpRequest (com.caucho.server.http)
handleRequest:822, HttpRequest (com.caucho.server.http)

mapServlet 是实际进行 Servlet 查找的实现，其大致代码如下:

public FilterChain mapServlet(ServletInvocation invocation) throws ServletException {
    String servletName = null;
    String contextURI = invocation.getContextURI();
    if (_servletMap != null) {
        cleanUri = Invocation.stripPathParameters(contextURI);
        ServletMapping servletMap = _servletMap.map(cleanUri, vars);

        if (servletMap != null) {
            servletName = servletMap.getServletName();
        }
    }

    if (servletName == null) {
        InputStream is;
        is = _webApp.getResourceAsStream(contextURI);
        if (is != null) {
            is.close();
            servletName = _defaultServlet;
        }
    }
    MatchResult matchResult = null;
    if (matchResult == null && contextURI.endsWith("j_security_check")) {
      servletName = "j_security_check";
    }

    if (servletName == null) {
      servletName = _defaultServlet;
      vars.clear();
      if (matchResult != null)
        vars.add(matchResult.getContextUri());
      else
        vars.add(contextURI);
      addWelcomeFileDependency(invocation);
    }

    if (servletName == null) {
      log.fine(L.l("'{0}' has no default servlet defined", contextURI));
      return new ErrorFilterChain(404);
    }

    String servletPath = vars.get(0);
    invocation.setServletPath(servletPath);
    invocation.setPathInfo(/*...*/);

    if (servletName.equals("invoker"))
      servletName = handleInvoker(invocation);

    invocation.setServletName(servletName);
    ServletConfigImpl newConfig = _servletManager.getServlet(servletName);
    if (newConfig != null) config = newConfig;

    FilterChain chain = _servletManager.createServletChain(servletName, config, invocation);

    if (chain instanceof PageFilterChain) {
      PageFilterChain pageChain = (PageFilterChain) chain;
      chain = PrecompilePageFilterChain.create(invocation, pageChain);
    }

    return chain;
}

按照执行顺序，简单总结一下:

首先使用 ServletInvocation#stripPathParameters 删除前面提到剩下的路径参数，即删除 ; 到 / 之间或者到 URI 末尾的内容，得到的 cleanUri 是最终用于路由查找的 URI；
使用 _servletMap.map 查找对应的 Servlet；
如果没找到，使用 _webApp.getResourceAsStream 查找对应磁盘文件或者资源文件是否存在，_defaultServlet 为 resin-file；
如果 contextURI 以 j_security_check 结尾，则路由到名称为 j_security_check 的 Servlet；
最后查找 welcom file，默认包括 index.html、index.jsp 和 index.php；

_servletMap 是 UrlMap 类型，其中有一个 RegexEntry 数组，包含了所有(当前应用)已经注册的 Servlet 映射和路由。

在 Resin 中，每个路由都使用正则表达式来进行匹配，如果多个 Servlet 都匹配中了同一个 URI，则会根据匹配的精度选择最佳结果，从而符合 Java EE Servlet 标准中的路由映射定义。

对于精确匹配，比如 /hello，对应的正则是 ^/hello$；
对于路径匹配，比如 /admin/*，对应的正则是 ^/admin(?=/)|^/admin\z；
对于后缀匹配，比如 *.jsp，对应的正则是 ^.*\.jsp(?=/)|^.*\.jsp\z；

其中精确匹配的末尾是 $，而后缀匹配的末尾是 \z，这二者有何不同？经过翻阅文档得知，\z 表示字符串末尾，而 $ 表示行末，因此 \z 可以匹配换行符而 $ 不能！

继续往下看，getResourceAsStream 查找磁盘或者资源文件的实现如下:

public InputStream getResourceAsStream(String uripath)
{
  Path rootDirectory = getRootDirectory();
  Path path = rootDirectory.lookupNative(getRealPath(uripath));

    if (path.canRead())
      return path.openRead();
    else {
      String resource = "META-INF/resources" + uripath;
      return getClassLoader().getResourceAsStream(resource);
    }
}

这和预料中的差不多，后面确定 Servlet 都使用了字符串名称，比如 resin-file、j_security_check，实际查找是通过 _servletManager.getServlet(servletName) 获取对应的 Servlet 实例，由此我们得知 ServletManager#_servlets 字典中保存了所有注册的 Servlet:

j_security_check -> com.caucho.server.security.FormLoginServlet
resin-xtp -> com.caucho.jsp.XtpServlet
resin-jsp -> com.caucho.jsp.JspServlet
resin-jspx -> com.caucho.jsp.JspServlet
resin-file -> com.caucho.servlets.FileServlet
resin-php -> com.caucho.quercus.servlet.QuercusServlet
Hello -> com.example.resin.HelloServlet
txtServlet -> com.example.resin.TxtServlet
flagServlet -> com.example.resin.FlagServlet
adminServlet -> com.example.resin.AdminServlet

后四个是笔者自己写的 Servlet，其他的都是 Resin 默认添加的。默认的 Servlet resin-file 对应 FileServlet，也负责读取静态文件或者资源的 Servlet。至此就完成了 Servlet 的查找和映射，随后只需要构建 FilterChain 并逐级调用 Filter 后即可到达对应的业务代码中。

Bypass Tricks

类似于 Tomcat，根据对上述 Resin 源码的分析，我们也可以得出一些 Bypass Tricks，在原始 URI /api/flag 的基础上进行变异以实现正常路由到相同 Servlet 的目的:

hack/api/flag: 基于 readRequest 中判断 URI 的第一个字符不为 / 的变异；
/api/fla%67: 基于 normalizeUriEscape 解码的变异；
/api/fla%u0067: 基于 scanUriEscape 中特殊 URL 编码的变异；
/api//flag: 基于 normalizeUri 2.1 的变异；
/api/./flag: 基于 normalizeUri 2.2 的变异；
../api/flag: 基于 normalizeUri 2.3 的变异；
/api\flag: 基于 normalizeUri 2.4 的变异，对于分隔符都会转换为 /；
/api/flag%20(空格)，/api/flag.: 基于 normalizeUri 2.4 的变异，仅在 Windows 系统中有效；
/api/flag;a=b: 针对 stripPathParameters 的变异；
/api/flag%0a: 基于正则表达式 $ 不匹配换行的变异；

这些变异可以组合使用，从而形成更加丰富的 URI 结果。

小结

通过分析 Tomcat 和 Resin 的 URI 解析流程，我们可以发现很多共同点，比如都会进行 URL Decode、都会进行路径归一化以及删除路径参数。同时值得注意的是不同的 Web 容器实现上又有一定差异，比如 Tomcat 在路径归一化时超出根目录的会报错，而 Resin 则会静默保留到根目录；Tomcat 与 Resin 的路由方式不同，前者严格按照 Servlet 标准实现，而后者则简化成正则表达式实现。因此在分析不同的 Web 容器时，除了尝试常见的 URI 变异方法，还可以针对性地分析对应容器的内部实现，从而找到隐藏更深的问题。

文件系统

在前面分析 Tomcat 和 Resin 容器的时候，可以发现有一个共同点，即路由在查找所有 Servlet 都失败的情况下，会使用默认的 Servlet 去进行处理，这个默认 Servlet 的作用就是读取本地磁盘或者资源中的文件。

因此仅从读文件的情况下看，我们是否可以利用文件系统寻址文件的特性来变异文件名呢？答案是肯定的。按照惯例来说应该查看对应文件系统的实现来看，但是这涉及到内核源码的分析，稍微超出了本 Java Boy 的能力范围，所以这里我直接写了一个简单的 Fuzzer 来进行文件名变异:

private void checkName(int i, String filename) {
    File f = new File(filename);
    if (f.exists())
    System.out.println(String.format("%06x pass: [%s]", i, filename));
}

public void fuzzFilename(String originFile) {
    File file = new File(originFile);
    if ( !file.exists() ) {
        return;
    }
    System.out.println(originFile + " exists.");
    Path filePath = Paths.get(originFile);
    String name = filePath.getFileName().toString();
    Path parentPath = filePath.getParent();
    String dirName = parentPath != null ? parentPath.toString() : "";
    System.out.println(String.format("dirName: %s, name: %s", dirName, name));

    for (int i = 0; i <= 0x10FFFF; i++) {
        // if (!Character.isValidCodePoint(i)) continue;
        String fuzzChar = new String(Character.toChars(i));
        checkName(i, originFile + fuzzChar);
        checkName(i, fuzzChar + originFile);
        checkName(i, dirName + fuzzChar + name);
        checkName(i, dirName + fuzzChar + File.separator + name);
        checkName(i, dirName + File.separator + fuzzChar + name);
    }
}

在 Linux/MacOS 中，输出如下:

dirName: /tmp, name: 1.txt
00002f pass: [/tmp/1.txt/]
00002f pass: [//tmp/1.txt]
00002f pass: [/tmp//1.txt]

值得注意的只有第一个，即在文件末尾加上 / 依然可以寻址到文件。

在 Windows 就比较丰富了，输出如下:

test\1.txt exists.
dirName: test, name: 1.txt
000020 pass: [test\1.txt ]
00002e pass: [test.\1.txt]
00002e pass: [test\1.txt.]
00002f pass: [test/1.txt]
00002f pass: [test/\1.txt]
00002f pass: [test\/1.txt]
00002f pass: [test\1.txt/]
00005c pass: [test\1.txt\]
00005c pass: [test\1.txt]
00005c pass: [test\\1.txt]

可以看到，在 Windows 中，文件名末尾加空格，.、/ 以及 \ 都不影响文件的定位，甚至目录末尾也可以加 . 号，这对于请求变异来说无疑增加了许多可能。假设 URL 原本要请求的文件是 /ppp/secret.txt，那么在 Windows 中请求就可以变异成:

/ppp/SERET.TXT (大小写不敏感)
/ppp/secret.txt%20
/ppp.\seret.txt
/ppp/seret.txt%2e
/ppp/seret.txt/
…

值得一提的是，在 Windows 常用的 NTFS 文件系统中，还有一种特殊的文件表示成为备用数据流(Alternate Data Streams)，简称 ADS。NTFS 中每个文件都有至少一个数据流，即主数据流，数据流的完整表示方法为:

<文件名>:<数据流名>:<数据流类型>

默认数据流名称为空，因此对于文件 foo.txt 而言其默认数据流的全称应该是 foo.txt::$DATA，其中数据流名为空，类型为 $DATA。对于目录而言，不存在默认数据流，但是有默认的目录流(directory stream)。目录流类型为 $INDEX_ALLOCATION，默认的流名称为 $I30，因此下面的目录表示都是等价的:

C:\Users
C:\Users:$I30:$INDEX_ALLOCATION
C:\Users::$INDEX_ALLOCATION

该特性可以使我们在 Windows 中寻址文件和目录时候使用更加隐晦的变异方法。

参考文档:

URI 标准

既然上面在讨论的都是 URL，那自然免不了 “官方” 的解释。不管是 Servlet 容器还是 HTTP Server，所遵循的都是同一个标准，即:

RFC3986 - Uniform Resource Identifier (URI): Generic Syntax

关于该标准相信其他师傅多少都有提及过，只是各自的关注点不同。对于本文而言，关注点在路径部分。在 3.3 节中指明，path 以第一个问号 ? 或者井号 # 终止，或者是到 URI 的结尾。各部分的示意图如下所示:

  foo://example.com:8042/over/there?name=ferret#nose
  \_/   \______________/\_________/ \_________/ \__/
   |           |            |            |        |
scheme     authority       path        query   fragment
   |   _____________________|__
  / \ /                        \
  urn:example:animal:ferret:nose

所以一般路由寻址的时候是不包含 ? 后面的参数的，但其他的部分实现各有不同，Tomcat 在路径中包含 # 时会报错，但 Resin 则会当成合法的路径一部分去进行路由查找。

路径部分的 ABNF 定义如下:

path          = path-abempty    ; begins with "/" or is empty
              / path-absolute   ; begins with "/" but not "//"
              / path-noscheme   ; begins with a non-colon segment
              / path-rootless   ; begins with a segment
              / path-empty      ; zero characters

path-abempty  = *( "/" segment )
path-absolute = "/" [ segment-nz *( "/" segment ) ]
path-noscheme = segment-nz-nc *( "/" segment )
path-rootless = segment-nz *( "/" segment )
path-empty    = 0

segment       = *pchar
segment-nz    = 1*pchar
segment-nz-nc = 1*( unreserved / pct-encoded / sub-delims / "@" )
            ; non-zero-length segment without any colon ":"

pchar         = unreserved / pct-encoded / sub-delims / ":" / "@"

路径由段(segments)组成，不同段之间使用斜杠 / 进行分隔。

. 和 .. 称为 dot-segments，在对路径进行路由之前需要先去除这些段，在 5.2 章 Relative Resolution 中详细介绍了如何解析包含 dot-segment 的路径，甚至还给出了伪代码实现。

另外 path segment 中通常可以包含保留字符用来提供一些子组件，比如前面提到过的使用分号 ; 和等号 = 来为每个 segment 提供参数。标准中提到逗号 , 通常也有类似的作用，不过我们之前分析源码的时候发现 Tomcat 和 Resin 都对逗号没有特殊的处理。

鉴权案例

前面提到过，为了降低代码的耦合性，鉴权一般放到 Filter 中实现而不是在 Servlet 中实现。对于一般的开发者而言，可以很简单的写出一个鉴权 Filter，比如:

@WebFilter(filterName = "AdminFilter", urlPatterns = "/*")
public class AdminFilter extends HttpFilter {
    @Override
    public void doFilter(HttpServletRequest req, HttpServletResponse res, FilterChain chain) throws IOException, ServletException {
        String uri = req.getRequestURI();
        if (uri.startsWith("/api/flag")) {
            res.setStatus(403);
            res.getWriter().write("YOU SHALL NOT PASS: " + uri);
        } else {
            chain.doFilter(req, res);
        }
    }
}

看了前面的 Bypass Tricks，我们知道仅使用 startsWith 做鉴权是多么地不堪一击，但令人惊讶的是现实中确实存在着许多类似的鉴权代码。不仅有 startsWith，endsWith，甚至还有使用 indexOf 去比较 URI 进行鉴权的。

某 OA

当然，这类应用在红队一次又一次的毒打中逐渐成长了起来，也知道了在对 URI 鉴权之前需要先对其进行一定的清洗和过滤。下面是一个某知名 OA 应用中鉴权部分对 URI 的预处理代码:

public String path(String path) {
   path = this.uriDecode(path);
   if (path != null && path.indexOf("\\") != -1) {
      path = StringUtil.replace(path, "\\", "/", false);
   }

   if (path != null && path.indexOf("..") != -1) {
      path = StringUtil.replace(path, "\\.{2,}", "");
   }

   if (path != null && path.indexOf("./") != -1) {
      path = StringUtil.replace(path, "./", "", false);
   }

   if (path != null && path.indexOf(";") != -1) {
      path = StringUtil.replace(path, ";.*?/", "/");
   }

   if (path != null && path.indexOf(";") != -1) {
      path = StringUtil.replace(path, ";.*", "");
   }

   if (path != null && path.indexOf("//") != -1) {
      path = StringUtil.replace(path, "/{2,}", "/");
   }

   if (path != null) {
      path = StringUtil.replace(path, "\\s", "");
   }

   if (!path.equals("") && !path.startsWith("/")) {
      path = "/" + path;
   }

   return path;
}
private String uriDecode(String path) {
  try {
      if (path != null && path.indexOf("%") != -1) {
        return URLDecoder.decode(path);
      }
  } catch (Exception var3) {
      this.writeLog("uri decode error:" + path, true);
      this.writeError(var3);
  }

  return path;
}

首先 URI 解码，然后替换反斜杠，也别管 URI 的标准了，.. 直接删掉，路径参数也直接删掉，还有空格、// 之类的都进行了处理，看起来是不是无懈可击？但是其实仔细看一下会发现还是有一些问题，比如:

uriDecode 中可能会失败，导致根本没解码成功而返回原始的路径；
URI 解码之后，路径可能会存在大写，如果是 WIndows 中请求 JSP 等文件可以正确路由；
路径参数的删除在 ./ 之后，所以 .;xxx/ 处理后依旧存在 ./；
删除空格 \s 在归一化 // 之后，所以 /%20/ 依旧可以绕过替换返回 //；
…

可见尽管有时候开发者知道要过滤什么字符，但是手指也不听大脑使唤，导致写出的代码依旧漏洞百出。因此，更为科学的方案是使用知名的、经过检验的鉴权框架，而不是尝试自己处理。

Shiro

Apache Shiro 是一个简单易用的认证和鉴权管理框架，虽然本身支持许多场景，但常用于 Web 应用中的身份认证和路径鉴权。

web.xml 的配置比较简单，只需要引入 ShiroFilter 并将其映射到所有 URL，注意 filter-mapping 一般要在其他 Filter 之前:


    org.apache.shiro.web.env.EnvironmentLoaderListener



    ShiroFilter
    org.apache.shiro.web.servlet.ShiroFilter



    ShiroFilter
    /*
    REQUEST
    FORWARD
    INCLUDE
    ERROR
    ASYNC

具体的配置通过配置文件实现，默认在 WEB-INF/shiro.ini，一个示例如下:

[main]
authc.loginUrl = /login.jsp
filterChainResolver.globalFilters = null

[urls]
/login/* = anon
/admin/* = authc
/api/flag = authc

[users]
evilpan=111111

urls 中使用优先匹配，而不是最佳匹配，左边指定 URL 模式，右边指定对应的 Filter 名称。Shiro 中支持的 Filter 如下:

anon: org.apache.shiro.web.filter.authc.AnonymousFilter
authc: org.apache.shiro.web.filter.authc.FormAuthenticationFilter
authcBasic: org.apache.shiro.web.filter.authc.BasicHttpAuthenticationFilter
authcBearer: org.apache.shiro.web.filter.authc.BearerHttpAuthenticationFilter
invalidRequest: org.apache.shiro.web.filter.InvalidRequestFilter
logout: org.apache.shiro.web.filter.authc.LogoutFilter
noSessionCreation: org.apache.shiro.web.filter.session.NoSessionCreationFilter
perms: org.apache.shiro.web.filter.authz.PermissionsAuthorizationFilter
port: org.apache.shiro.web.filter.authz.PortFilter
rest: org.apache.shiro.web.filter.authz.HttpMethodPermissionFilter
roles: org.apache.shiro.web.filter.authz.RolesAuthorizationFilter
ssl: org.apache.shiro.web.filter.authz.SslFilter
user: org.apache.shiro.web.filter.authc.UserFilter

一般常用的是 authc 表示 SESSION 认证的 Filter，anon 表示可匿名访问即无需认证的 Filter。对于配置文件的其他字段及其解释可以参考官方文档，这里就不详细介绍了。

我们这里主要关心的是 Shiro 鉴权之前对 URL 路径做了什么样的处理。篇幅原因这里直接说结论，处理的方法为 org.apache.shiro.web.util.WebUtils#getPathWithinApplication，调用链路回溯如下所示:

getPathWithinApplication:114, WebUtils (org.apache.shiro.web.util)
getPathWithinApplication:105, PathMatchingFilter (org.apache.shiro.web.filter)
pathsMatch:124, PathMatchingFilter (org.apache.shiro.web.filter)
preHandle:195, PathMatchingFilter (org.apache.shiro.web.filter)
doFilterInternal:131, AdviceFilter (org.apache.shiro.web.servlet)
doFilter:154, OncePerRequestFilter (org.apache.shiro.web.servlet)
doFilter:66, ProxiedFilterChain (org.apache.shiro.web.servlet)
executeChain:458, AbstractShiroFilter (org.apache.shiro.web.servlet)
call:373, AbstractShiroFilter$1 (org.apache.shiro.web.servlet)
doCall:90, SubjectCallable (org.apache.shiro.subject.support)
call:83, SubjectCallable (org.apache.shiro.subject.support)
execute:387, DelegatingSubject (org.apache.shiro.subject.support)
doFilterInternal:370, AbstractShiroFilter (org.apache.shiro.web.servlet)
doFilter:154, OncePerRequestFilter (org.apache.shiro.web.servlet)
internalDoFilter:178, ApplicationFilterChain (org.apache.catalina.core)

getPathWithinApplication 的代码为:

public static String getPathWithinApplication(HttpServletRequest request) {
    return normalize(removeSemicolon(getServletPath(request) + getPathInfo(request)));
}

主要经过两步，分别是 removeSemicolon 去除分号以及 normalize 路径归一化。removeSemicolon 的实现只考虑路径末尾的分号:

private static String removeSemicolon(String uri) {
    int semicolonIndex = uri.indexOf(';');
    return (semicolonIndex != -1 ? uri.substring(0, semicolonIndex) : uri);
}

不过 normalize 的实现倒是比较完善，注释中也说明这是从 Tomcat 中 “借鉴” 的:

Normalize operations were was happily taken from org.apache.catalina.util.RequestUtil in Tomcat trunk, r939305

值得注意的是，这里传入的并不是原始的 URI，而是 getServletPath + getPathInfo，二者分别是:

HttpServletRequest.getServletPath()，在 Tomcat 中对应 mappingData.wrapperPath.toString()；
HttpServletRequest.getPathInfo()，在 Tomcat 中对应 mappingData.pathInfo.toString()；

在前面介绍 Tomcat 中路由映射的时候提到，mappingData 中的 wrapper 是在路由之后确定的，也就是说此时 wrapperPath 已经是 Web 容器处理之后的 URI，如果能寻址到 flagServlet，那么其值必然是 /api/flag，优雅地解决了 TOCTOU 不一致的问题。

当然这也不意味着无懈可击，否则 Shiro 也不会再加一层 removeSemicolon 和 normalize。因为 Web 容器具有多样性，不同路由策略的碎片化同样也可能造成 Shiro 的绕过。而现在的 getPathWithinApplication 也不是一开始就是这样的，而是在 CVE-2020-13933 出现之后才改成这样子，详情可以参考: ANNOUNCE CVE-2020-13933 Apache Shiro 1.6.0 released。

在对路径完成这一步过滤后，使用 pathMatches 进行匹配:

// org.apache.shiro.web.filter.mgt.PathMatchingFilterChainResolver#getChain
final String requestURI = getPathWithinApplication(request);
final String requestURINoTrailingSlash = removeTrailingSlash(requestURI);
for (String pathPattern : filterChainManager.getChainNames()) {
  if (pathMatches(pathPattern, requestURI)) {
    return filterChainManager.proxy(originalChain, pathPattern);
  } else {
    // 针对 Spring Web 的处理
    pathPattern = removeTrailingSlash(pathPattern);
      if (pathMatches(pathPattern, requestURINoTrailingSlash)) {
        return filterChainManager.proxy(originalChain, pathPattern);
      }
  }
}

注意这里针对 Spring 应用进行了特殊处理，因为在 Spring 中 /resource/data 和 /resource/data/ 都能路由到同一个资源，但 Shiro 的 /resource/data 无法匹配到后者，因此将路径和 pathPattern 都删除了末尾的 / 去进行二次匹配。这应该是针对 CVE-2021-41303 的补丁，可见即便是成熟的鉴权框架也依然会踩到 URL 鉴权的陷阱。

后记

本文介绍了使用 URL 进行鉴权的一类威胁模型，并以两个符合标准的 Servlet 容器 Tomcat 和 Resin 为例介绍了二者的路由查找方法，根据路由查找的过程提出了一系列可能的 URL 变异方式；然后对几个现实中的鉴权案例进行分析，包括某典型应用手搓的鉴权代码以及成熟的鉴权方案 Shiro，其中都存在或者出现过鉴权绕过的场景，从中我们可以加深对 URL 鉴权的理解，从而写出更加健壮和安全的代码。

另外，本文只是介绍了 Servlet 标准应用的路由特性，而现代 Java Web 应用中更多是基于 Spring 生态的全家桶方案，Spring MVC 包揽了 Web 容器的所有路由并使用自身的寻址实现，且配合 Spring Security 也形成一套 URL 鉴权方案。这部分限于篇幅原因并未在本文中提及，后续有机会的话会另起一篇文章进行介绍。

彩蛋🥚: 在分析 Resin 路由的时候，其实暴露了一个 “0day”，涉及到路径处理的核心顺序错误，不知道读者是否能够发现？

LINKS

版权声明: 自由转载-非商用-非衍生-保持署名 (CC 4.0 BY-SA)
原文地址: https://evilpan.com/2023/07/29/url-gotchas/
微信订阅: 『有价值炮灰』
– TO BE CONTINUED.

Spring Framework 历史漏洞研究

Fri, 21 Apr 2023 12:40:00 +0800

本文的主要目标是分析、总结、归纳历史上出现过的 Spring 框架漏洞，从而尝试找出其中的潜在模式，以达到温故知新的目的。当然作为一个 Java 新手，在直接分析漏洞之前，还是会先从开发者的角度去学习 Spring 中的一些核心概念，从而为后续的理解奠定基础。

前言

由于早期 J2EE 规范过于复杂且不采纳社区的建议，Spring 于 2003 年最初作为 J2EE 的竞争者而诞生了。随着时代的发展，Spring 与 JavaEE 形成了一种互补的关系，不拥抱 JavaEE 的平台规范，但是从其中精心挑选了个别规范进行整合，比如 Servlet、JPA、JMS 等。

当我们在谈论 Spring 的时候，可以是指代 Spring 框架项目本身，也可以是指代基于 Spring 框架之上的整个项目家族，即 Spring 全家桶，在后文介绍具体漏洞的时候也可以看到更多漏洞出现在框架之上的项目中。

Spring Framework

Spring 框架是一个功能强大的 Java 应用程序框架，旨在提供高效且可扩展的开发环境。其本身也是模块化的，应用程序可以选择所需要的模块。比如包含核心容器、配置模型和依赖注入机制的模块 spring-core，脚本引擎 SpEL，以及基于 Servlet 的 Spring MVC Web 和 Spring WebFlux 框架等。

除了 Spring 框架本身，还有其他项目，如 Spring Boot、Spring Security、Spring Data、Spring Cloud、Spring Batch 等，每个项目都有自己的源代码仓库和版本管理。完整的项目列表可以参考 spring.io/projects。本节主要介绍 Spring Framework 本身的核心概念以及历史漏洞，其他项目会在下面的章节中单独介绍。

注: 关于 Spring Framework 的详细介绍建议直接参考官方的文档 Spring Framework Documentation，这里只是摘录了一些笔者自以为的关键内容，仅作为补充理解。

依赖注入与 IoC

凡介绍 Spring 框架的文章都离不开 IoC，其全称为 Inversion of Control，即控制反转。看了网上很多文章，都说 IoC/依赖注入就是将 XML 配置文件中的 Bean 通过反射构造成实例的过程，却没有解释这么做的目的。

要理解 IoC 就需要先理解依赖注入(Dependency Injection，简称 DI)。在 Java 中，依赖注入本质上是一种设计模式。依赖注入的基本原则是应用组件不应该负责查找资源或者其他依赖的协作对象，配置对象的工作应该由容器负责，查找资源的逻辑应该从应用组件的代码中抽取出来，交给 DI 容器来完成。

举例来说，假设类 A 需要用到接口 B 的方法，那么就需要为类 A 和接口 B 建立关联，即依赖关系。最原始的方式是在 A 类中创建一个 B 接口的实例，但这种方法需要开发者手动维护二者的依赖关系，一旦依赖关系发生变动就需要对代码进行重构和修改。依赖注入就是为了解决这个问题而诞生的。通过依赖注入，二者的依赖关系由 DI 容器进行管理，当依赖关系变化时候只需要修改容器的配置文件即可。

简而言之，如果一个 Bean 是另一个 Bean 的依赖，这通常意味着一个 Bean 被设置为另一个 Bean 的一个属性。

在 Spring 中构成用户应用程序的骨干且由 Spring IoC 容器管理的对象称为 Bean。其结构和 Java Bean 类似，但生命周期由 Spring IoC 容器管理，Spring Bean 以及它们之间的依赖关系都反映在容器使用的配置元数据之中，配置元数据可以来自 XML 配置文件或者 Java 注解。

org.springframework.beans 和 org.springframework.context 包是 Spring Framework 的 IoC 容器的基础。其中 BeanFactory 接口提供了一种配置机制，能够管理任何类型的对象。

ApplicationContext 是 BeanFactory 的一个子接口，代表 Spring IoC 容器，负责实例化、配置和组装 bean。该接口有几个常见的内置实现，比如 ClassPathXmlApplicationContext 和 FileSystemXmlApplicationContext。

Spring 框架核心功能之一就是 IoC 容器，而对于开发者而言，需要的只是告诉容器哪些 bean 需要被管理，这个过程通常也是 Spring 的配置过程。Spring 中提供了两种配置 IoC 容器的方式，分别是基于 XML 的配置和基于注解的配置。

基于 XML 的配置示例如下:

 id="userService" class="com.example.UserService">
    name="userDao" ref="userDao"/>


 id="userDao" class="com.example.UserDao">

Spring 读取该配置文件后会通过 IoC 容器创建对应的 POJO 对象(Bean)，管理其生命周期并将对应依赖进行动态注入。

使用注解方式也可以达到类似的效果，如下所示:

@Component
public class UserService {

    @Autowired
    private UserDao userDao;

    // Required setters and methods
}

两种方式各有利弊，且二者 Spring 都提供了大量的细化配置方法，比如设置作用域(Scope)，工厂类和构造函数调用规则等，详细配置方法可以参考官方的文档。

Spring MVC

Spring Framework 作为一个 Web 框架，其核心功能自然要包含传统的 Web MVC 功能。前面说过，Spring 框架是以模块划分的，而该 MVC 框架自一开始就是 Spring 中的核心模块，其代码在 github.com/spring-projects/spring-framework 中的 spring-webmvc 子目录中，其正式名称为 “Spring Web MVC”，通常也被称为 Spring MVC。注意这只是 Spring Framework 中的一个模块，而并不是单独的项目。

在前文 Java 安全研究初探中介绍过，Servlet 是 Java EE Web 服务器中的重要标准之一，满足 Servlet 规范的应用便可以被标准的 Servlet 容器加载执行。对于 Spring MVC 而言同样拥抱了这个标准，其中重要的 Servlet 即为 DispatcherServlet。从 6.0 的源码中看，DispatcherServlet 的继承链为:

DispatcherServlet -> FrameworkServlet -> HttpServletBean -> HttpServlet

与所有其他 Servlet 一样，我们可以通过 web.xml 或者 ServletContext 接口来注册和初始化 DispatcherServlet，并通过添加控制器来实现 Web 请求处理。Spring MVC 提供了一个基于注解的编程模型，其中 @Controller 和 @RestController 组件使用注解来表达请求映射、请求输入、异常处理等内容。注解的控制器具有灵活的方法签名，不需要继承基类，也不需要实现特定的接口。下面是一个简单的例子:

@Controller
public class HelloController {

    @GetMapping("/hello")
    public String handle(Model model) {
        model.addAttribute("message", "Hello World!");
        return "index";
    }
}

上述控制器示例接受一个 Model 实例，并返回一个字符串，表示视图名称；实际上可以支持各种灵活的函数签名，Spring 框架会对其进行合适的解析。一个更常见的示例如下:

@RestController
@RequestMapping("/persons")
class PersonController {

    @GetMapping("/{id}")
    public Person getPerson(@PathVariable Long id) {
        return PersonDao.getById(id);
    }

    @PostMapping
    @ResponseStatus(HttpStatus.CREATED)
    public void add(@RequestBody Person person) {
        // ...
    }
}

@RequestMapping 表示类层面的共享映射，而 @RestController 可以认为是 @Controller 和 @ResponseBody 的组合。@ResponseBody 表示 controller 函数的返回直接绑定到 Web 请求的返回 body 中。

Controller 函数中可以通过返回 DeferredResult 或 Callable 来实现单个异步结果的返回，或者通过 ResponseBodyEmitter、SseEmitter 来实现多个异步结果的返回，最近比较火的 ChatGPT 流式响应就是基于 SSE (Server-Sent Events) 实现的。

Spring MVC 中对于请求和响应提供了灵活的处理接口，这里只是对其基本功能有个大致理解，后面介绍具体漏洞的时候再展开介绍。

Spring WebFlux

Spring WebFlux 是一个与 Spring MVC 经常相提并论的一个新兴 Web 框架，在 Spring Framework 5.0 中引入，模块名称为 spring-webflux。这是一个基于 reactive (响应式) 技术栈的 Web 框架，具有完全的异步支持，支持 Reactive Streams 背压等。

背压: 专业术语，指消费者可以告诉生产者自己需要多少的量，避免生成速率高于消费速率造成的缓冲溢出或者数据丢失。

Spring WebFlux 的使用与 Spring MVC 类似，最大的不同点在于 WebFlux 支持模型中的响应式类型，如 Mono 或者 io.reactivex.Single，下面是一个简单的示例:

@RestController
public class UserController {
    private final UserRepository userRepository;

    public UserController(UserRepository userRepository) {
        this.userRepository = userRepository;
    }

    @GetMapping("/users")
    public Flux<User> getAllUsers() {
        return userRepository.findAll();
    }

    @GetMapping("/users/{id}")
    public Mono<User> getUserById(@PathVariable String id) {
        return userRepository.findById(id);
    }
}

Spring MVC 本来就支持异步非阻塞，那为什么还要引入 WebFlux 呢？一个主要原因是性能，完全异步的处理可以减少并发的线程数量。而且引入异步 API 可以充分利用 Java 8 中引入的 lambda 表达式特性实现函数式编程，允许异步逻辑的声明式组合，如下所示:

@PostMapping("/owners/{ownerId}/pets/{petId}/edit")
public Mono<String> processSubmit(@Valid @ModelAttribute("pet") Mono<Pet> petMono) {
    return petMono
        .flatMap(pet -> {
            // ...
        })
        .onErrorResume(ex -> {
            // ...
        });
}

SpEL

SpEL 即为 Spring 表达式语言，其语法和标准的 JUEL 类似，但提供了额外的功能，如方法调用和字符串模版等丰富的功能。SpEL 是 Spring 框架中的核心部分之一，在 Spring 框架的 XML 配置、注解、MVC 控制器中都有所应用。

在 XML 中使用 SpEL 设置 bean 的属性:

 id="numberGuess" class="org.spring.samples.NumberGuess">
     name="randomNumber" value="#{ T(java.lang.Math).random() * 100.0 }"/>

在注解中使用 SpEL 设置字段默认值:

public class FieldValueTestBean {

    @Value("#{ systemProperties['user.region'] }")
    private String defaultLocale;

    // ...
}

SpEL 虽然出自 Spring，但也可以独立使用，例如:

ExpressionParser parser = new SpelExpressionParser();
Expression exp = parser.parseExpression("new String('hello world').toUpperCase()"); (1)
String message = exp.getValue(String.class);

值得一提的是，Expression.getValue 方法有多个重载，其中部分重载接受一个额外的 EvaluationContext 类型参数。EvaluationContext 接口在评估表达式以解析属性、方法或字段时使用，并帮助执行类型转换。Spring提供了两种实现，分别是:

StandardEvaluationContext: 支持 SpEL 语言的所有功能和配置选项，这是默认值；
SimpleEvaluationContext: 仅提供 SpEL 语言的基本功能和配置选项的子集，适用于不需要 SpEL 语言全部功能，且对表达式有限制的情况；

一般来说，使用默认的 StandardEvaluationContext 且表达式用户可控的情况下会导致任意的 Java 代码执行，此时通常会用 SimpleEvaluationContext 来限制表达式只能访问有限的属性。后文可以看到类似的漏洞。

历史漏洞

本节记录和分析一些历史上出现过的 Spring Framework 的漏洞。由于 Spring Framework 本身是 Spring 元宇宙的根基，因此一旦出现漏洞影响就非常广泛，值得我们重点关注。由于篇幅原因，这里的分析不会太过深入，并尽可能给出已有的优秀分析文章链接。

CVE-2010-1622

Spring MVC 允许开发者将业务对象 (Bean) 绑定到 HTML 表单中，并通过请求对其进行修改，例如下述请求:

POST /adduser HTTP/1.0
...
firstName=Tavis

如果绑定了业务对象 User，那么该请求背后最终会执行 user.firstName = "Tavis"，这是基于 JavaBean 的接口去实现的。Spring 还支持使用复杂的设置方式，比如 user.address.street=Test 会转换为:

frmObj.getUser().getAddress().setStreet("Test")

由于 Bean 类默认继承自 Object，且内省的时候没有过滤掉父类的属性，因此攻击者可以通过 class.classLoader 的方式调用 frmObj.getClass().getClassLoader() 从而进一步修改 ClassLoader 中的属性，导致任意代码执行。最初作者的建议是通过 Introspector.getBeanInfo(Person.class, Object.class) 指定 stopClass 的方式防止该问题，但 Spring 实际上通过黑名单的方式进行了修复，这也为后续的绕过埋下伏笔。

详细分析可以参考:

https://blog.o0o.nu/2010/06/cve-2010-1622.html

CVE-2013-4152

Spring MVC 中可以将请求的数据绑定到 Bean 对象中，请求数据可以是表单、XML、JSON 等，该漏洞就是通过 XML 请求绑定到 Bean 对象时解析 XML 外部实体导致的 XXE 注入问题。示例 Controller 如下:

@Controller
public class HomeController {
    @RequestMapping(value="/home", method=RequestMethod.POST, consumes="application/xml")
    public ModelAndView home(@RequestBody User user) {
        //System.out.println(user);
        return new ModelAndView("home", "message", user.getUserName());
    }
}

User 定义如下:

import javax.xml.bind.annotation.XmlElement;
import javax.xml.bind.annotation.XmlRootElement;

@XmlRootElement(name = "user")
public class User {
   private String userID;
   private String userName;
   @XmlElement
   public String getUserID() { return userID; }
   public void setUserID(String userID) { this.userID = userID; }
   @XmlElement
   public String getUserName() { return userName; }
   public void setUserName(String userName) { this.userName =userName; }
}

这类漏洞的修复方式取决于使用的 XML API:

DOM: 使用 DocumentBuilderFactory.setExpandEntityReferences(false); 禁用外部实体；
SAX: 使用 XMLReader.setFeature("http://xml.org/sax/features/external-general-entities", false); 禁用外部实体；
StAX: XMLInputFactory.setProperty(XMLInputFactory.IS_REPLACING_ENTITY_REFERENCES, false);；
Spring OXM: 类似 DOM，并使用 Jaxb2Marshaller 指定 DOMSource；

针对这个漏洞，关键的修复代码如下:

--- spring-web/src/main/java/org/springframework/http/converter/xml/Jaxb2CollectionHttpMessageConverter.java	(revision 2843b7d2ee12e3f9c458f6f816befd21b402e3b9)
+++ spring-web/src/main/java/org/springframework/http/converter/xml/Jaxb2CollectionHttpMessageConverter.java	(revision )
@@ -226,7 +226,9 @@
 	 * @return the created factory
 	 */
 	protected XMLInputFactory createXmlInputFactory() {
-		return XMLInputFactory.newInstance();
+		XMLInputFactory inputFactory = XMLInputFactory.newInstance();
+		inputFactory.setProperty(XMLInputFactory.IS_REPLACING_ENTITY_REFERENCES, false);
+		return inputFactory;
 	}
 
 }

详细信息可以参考:

另外还有几个类似的外部实体注入漏洞，如 CVE-2013-7315、CVE-2013-6429，另外由于上述修复不完全导致的绕过 CVE-2014-0054，因为上面只修了 Jaxb2CollectionHttpMessageConverter，没有修复 Jaxb2RootElementHttpMessageConverter。总的来说还是要仔细审计 XML 解析处理相关的功能，个人认为这也是由于 XXE 功能没有默认禁用导致的一大问题。

CVE-2014-3625

Spring MVC 虽然作为 MVC 框架，但同时也支持 Web 服务器中常见的功能，比如静态资源访问。例如我们可以通过配置 XML 去设定需要访问的静态资源，下面是一个简单的 spring-web-config.xml 示例:

  class="org.springframework.web.servlet.view.InternalResourceViewResolver">
      name="prefix" value="/WEB-INF/views/" />
      name="suffix" value=".jsp" />
 
 mapping="/resources/**" location="/resources/">

其中标签表示将 URL 路径 /resources 的请求映射到静态资源，路径为 Web 应用根目录的相对路径 /resources 下的文件。

或者也可以通过 Java 代码添加，参考 spring-showcase:

// org.springframework.samples.mvc.config.WebMvcConfig
@Override
public void addResourceHandlers(ResourceHandlerRegistry registry) {
    registry.addResourceHandler("/resources/**").addResourceLocations("/resources/");
}

该漏洞的 POC 比较简单，见下述 demo 代码:

$ git clone https://github.com/ilmila/springcss-cve-2014-3625/ && cd springcss-cve-2014-3625/
$ mvn jetty:run
$ curl 'http://localhost:8080/spring-css/resources/file:/etc/passwd'
root:x:0:0:root:/root:/bin/bash
...

漏洞成因出在静态资源解析的地方，调用链路为:

org.springframework.web.servlet.resource.ResourceHttpRequestHandler#handleRequest
org.springframework.web.servlet.resource.ResourceHttpRequestHandler#getResource
org.springframework.web.servlet.resource.PathResourceResolver#getResource
org.springframework.core.io.Resource#createRelative
org.springframework.core.io.PathResource#createRelative

CVE-2018-1270

该漏洞是 Spring Messaging 远程代码执行漏洞。Spring Messaging 也是 Spring 框架中的一个可选模块，前面并没介绍，其代码模块目录为 spring-messaging。主要提供应用间的消息传递机制，最典型的就是 Websocket 功能，以及在 Websocket 之上的 STOMP (Simple Text Oriented Messaging Protocol) 协议，此外还提供了针对不支持 Websocket 情况下的模拟替代方案 SockJS 等。

Messaging 主要针对全双工的异步传输，因此也采用了常见的发布/订阅机制。在多个客户端可以订阅同一个主题等待消息，以实现类似聊天室的效果。

回到该漏洞，其 PoC 如下，主要功能是订阅 /topic/greetings 时添加了自定义 selector 头:

function connect() {
    var header  = {"selector":"T(java.lang.Runtime).getRuntime().exec('calc.exe')"};
    var socket = new SockJS('/gs-guide-websocket');
    stompClient = Stomp.over(socket);
    stompClient.connect({}, function (frame) {
        setConnected(true);
        console.log('Connected: ' + frame);
        stompClient.subscribe('/topic/greetings', function (greeting) {
            showGreeting(JSON.parse(greeting.body).content);
        },header);
    });
}

该 selector 在服务端会被取出并当成 SpEL 表达式执行，如下:

// org/springframework/messaging/simp/broker/DefaultSubscriptionRegistry.java
  private MultiValueMap<String, String> filterSubscriptions(
      MultiValueMap<String, String> allMatches, Message message) {
    EvaluationContext context = null;
    for (String sessionId : allMatches.keySet()) {
      for (String subId : allMatches.get(sessionId)) {
        // ...
        Expression expression = sub.getSelectorExpression();
        if (context == null) {
          context = new StandardEvaluationContext(message);
          context.getPropertyAccessors().add(new SimpMessageHeaderPropertyAccessor());
        }
        // ..
        if (Boolean.TRUE.equals(expression.getValue(context, Boolean.class))) {
        result.add(sessionId, subId);
        }
      }
    }
    // ...

版本: 5.0.4.RELEASE

前面说过，expression.getValue 会执行对应的表达式，而如果表达式的内容可控，就可能会导致任意代码执行。除了这里，在该类的许多其他地方也有类似的问题，因此这一类问题的修复方案是将执行上下文即 EvaluationContext 设置为了 SimpleEvaluationContext，限制表达式的行为。具体的 patch 可以参考下面的链接:

从这个漏洞中可以看出，Spring 框架内有许多地方使用了 SpEL 来实现动态过滤、属性访问等功能，如果不加限制就可能造成非预期的危害。

CVE-2020-5398

这是一个 Spring Framework 的 RFD 漏洞。RFD，全称为 Reflected File Download，是在 Blackhat EU 2014 提出的一种新型 Web 攻击手法。其主要攻击思路是通过某些 Web 接口返回用户请求的特性，结合浏览器自动下载文件以及在 URL 中伪造文件后缀的技巧，实现针对目标域名的文件下载功能。例如，下面的域名通过路径参数 ; 添加额外的后缀，让浏览器自动识别下载文件为 ChromeSetup.bat，并且 HTTP 的响应中包含 GET 参数 q 的内容，通过 Windows 命令的 || 特性绕过前面的无用数据最终执行 calc.exe。

https://www.google.com/s;/ChromeSetup.bat?q=||calc

这只是一个粗略的介绍，关于 RFD 漏洞的细节可以参考后文中原作者的白皮书。

回到 Spring，这个漏洞导致 RFD 的原因是通过 Spring 的接口返回文件时，如果用户可以控制返回的部分文件名，就能实现 RFD 的效果。具体来说，是在使用 org.springframework.http.ContentDisposition 类返回的 Content-Disposition 头时，用户通过控制恶意的文件名影响该返回头。主要受影响的下面两个接口：

ContentDisposition.Builder#filename(String)
ContentDisposition.Builder#filename(String, US_ASCII)

CVE-2022-22965

这个漏洞即近期比较知名的 Spring4Shell 漏洞，但从漏洞原理来说，其核心其实是前文介绍过的 CVE-2010-1622 的一个绕过。前面说过，在修复 CVE-2010-1622 时，开发者使用了黑名单的方式，限制 Bean 属性名称不能为 classLoader 或者 protectionDomain，这在当时确实是解决了问题。但随着 Java 9 的推出，又引入了一些新的属性，比如 module，因此可以通过这个属性去绕过上面的限制再次对 classLoader 进行修改从而实现 RCE。

不过，该漏洞的 PoC 实际是利用 Tomcat 日志写文件的特性去实现的 webshell 写入，因为直接修改 classLoader 的方式有较多限制。网上虽然有很多分析文章，但大多数只是对着 PoC 单步调试，并没有提及该漏洞的核心。笔者认为，该漏洞的核心还是在于 Spring 对于 JavaBean 的内省 API 使用不当，即 Introspector.getBeanInfo 没有指定 stopClass 导致，不过看 Spring 的修复方式，还是想要在这条缝缝补补的路走到黑了。

该漏洞的补丁分了几个 commit，首先是第一次补丁:

diff --git a/spring-beans/src/main/java/org/springframework/beans/CachedIntrospectionResults.java b/spring-beans/src/main/java/org/springframework/beans/CachedIntrospectionResults.java
index 8332045197..bd234eb58f 100644
--- a/spring-beans/src/main/java/org/springframework/beans/CachedIntrospectionResults.java
+++ b/spring-beans/src/main/java/org/springframework/beans/CachedIntrospectionResults.java
@@ -22,6 +22,7 @@ import java.beans.Introspector;
 import java.beans.PropertyDescriptor;
 import java.lang.reflect.Method;
 import java.lang.reflect.Modifier;
+import java.net.URL;
 import java.security.ProtectionDomain;
 import java.util.Collections;
 import java.util.HashSet;
@@ -292,10 +293,12 @@ public final class CachedIntrospectionResults {
                                        // Only allow all name variants of Class properties
                                        continue;
                                }
-                               if (pd.getWriteMethod() == null && pd.getPropertyType() != null &&
-                                               (ClassLoader.class.isAssignableFrom(pd.getPropertyType()) ||
-                                                               ProtectionDomain.class.isAssignableFrom(pd.getPropertyType()))) {
-                                       // Ignore ClassLoader and ProtectionDomain read-only properties - no need to bind to those
+                               if (URL.class == beanClass && "content".equals(pd.getName())) {
+                                       // Only allow URL attribute introspection, not content resolution
+                                       continue;
+                               }
+                               if (pd.getWriteMethod() == null && isInvalidReadOnlyPropertyType(pd.getPropertyType())) {
+                                       // Ignore read-only properties such as ClassLoader - no need to bind to those
                                        continue;
                                }

限制了内省的获取属性的类型。黑名单的属性类型包括:

属性名为 content 且类型为 URL
没有 setter 的属性，且类型为黑名单，包括:
- AutoCloseable
- ClassLoader
- ProtectionDomain

然后过了两周又再次增强了一下:

diff --git a/spring-beans/src/main/java/org/springframework/beans/CachedIntrospectionResults.java b/spring-beans/src/main/java/org/springframework/beans/CachedIntrospectionResults.java
index 7b7a67d91c..4187097ce3 100644
--- a/spring-beans/src/main/java/org/springframework/beans/CachedIntrospectionResults.java
+++ b/spring-beans/src/main/java/org/springframework/beans/CachedIntrospectionResults.java
@@ -286,9 +287,13 @@ public final class CachedIntrospectionResults {
                        // This call is slow so we do it once.
                        PropertyDescriptor[] pds = this.beanInfo.getPropertyDescriptors();
                        for (PropertyDescriptor pd : pds) {
-                               if (Class.class == beanClass &&
-                                               ("classLoader".equals(pd.getName()) ||  "protectionDomain".equals(pd.getName()))) {
-                                       // Ignore Class.getClassLoader() and getProtectionDomain() methods - nobody needs to bind to those
+                               if (Class.class == beanClass && (!"name".equals(pd.getName()) && !pd.getName().endsWith("Name"))) {
+                                       // Only allow all name variants of Class properties
+                                       continue;
+                               }
+                               if (pd.getPropertyType() != null && (ClassLoader.class.isAssignableFrom(pd.getPropertyType())
+                                               || ProtectionDomain.class.isAssignableFrom(pd.getPropertyType()))) {
+                                       // Ignore ClassLoader and ProtectionDomain types - nobody needs to bind to those
                                        continue;
                                }

对 Class 类进行了进一步的限制，只允许获取其中 name 相关的属性。虽然满满的补丁感，但是有用！

后续的代码更新把 classLoader 等黑名单属性放到了 isInvalidReadOnlyPropertyType 之中，也就是现在我们看到的样子。

参考文章：

小结

本节简单学习了 Spring Framework 本身的一些特性和功能，并在此基础上随意选择了几个相关的漏洞进行分析，以尝试对 Spring 框架的整体结构、历史漏洞和代码质量有个初步认识。从中可以发现，Spring Framework 作为流行 Web 框架的基石，历史上出现过的严重漏洞并不多，RCE 类漏洞更多出现在 SpEL 中，MVC 框架里的 JavaBean 绑定也可以算是一个独特的攻击面。作为安全研究者，一方面可以对这些历史攻击面进行深入分析，以发掘新的绕过方式；另一方面也可以寻找一些新的攻击面，后者往往能造成更大的影响效果。

值得一提的是，受限于笔者的认知水平，这里介绍的漏洞并不完整，更多 Spring Framework 的漏洞可以参考官方的公告：

Spring Security Advisories - springio/security

同时，对于想要深入 Spring 框架内部以寻找新攻击面的研究者来说，仔细阅读其官方文档并结合源码进行调试分析或许是个更好的选择：

Spring 项目除了 Framework 本身，还有许多丰富的项目，如 Spring Boot、Spring Data、Spring Security 等，每个项目都有独立的代码仓库，这与 Spring Framework 的模块有所不同。项目列表可以参考：

spring.io/projects

后续有时间会继续对一些主流的 Spring Project 进行研究，结合整体的 Spring 生态也能对局部的设计有更深的理解。

版权声明: 自由转载-非商用-非衍生-保持署名 (CC 4.0 BY-SA)
原文地址: https://evilpan.com/2023/04/21/spring-framework-bugs/
微信订阅: 『有价值炮灰』
– TO BE CONTINUED.

Java 安全研究初探

Sat, 01 Apr 2023 12:40:00 +0800

尝试卷入 Java 安全

前言

Java 安全，通常指代的是 Java Web 安全。在刚开始学习的一段时间里，面对众多的框架和名词，比如 Spring、Weblogic、EJB、AKB，等等，总感觉狗啃泰山无从下嘴。于是就有了这篇文章，旨在记录学习过程中遇到的所有问题，希望也能对像我一样的初学者有所帮助。

Java EE

搞过 Java Web 开发的多少会知道 JavaEE。从字面上来看，它的意思是 Java Platform, Enterprise Edition，即 Java 平台企业版。这个名称有够抽象，实际上 Java EE 包含了一系列标准，这些标准主要用来为企业级应用提供分布式计算、Web 服务等的统一定义和接口。另外，这些标准在设计之初就考虑了安全性、拓展性、并发等能力。

Java EE 的前身为 J2EE、后来捐献给 Eclipse 基金会，改名为 Jakarta EE。在不引起混淆的情况下，后文统一称为 Java EE。

Java EE 是在 Java SE(Standard Edition) 的基础上建立的，并增加了许多额外的特性和技术来方便构建高可用的企业级应用。Java 中的标准一般定义在 JSR 中，即 Java Specification Requests。例如，Java EE 所涉及的标准就在 JSRs by Platform - Java EE，其中包含了一些已经撤回的。

从这些提案(标准)中，我们大概可以知道 Java EE 所涵盖的一些方向，比如:

jsr-9: XML Parsing Specification, 定义了 Java 中对 XML 进行处理的接口 (JAXP)；
jsr-19: Enterprise JavaBeans 2.0，即 EJB，提供了易管理的企业级组件定义和接口；
jsr-52: A Standard Tag Library for JavaServer PagesTM，定义了 JSP 中标签库的标准；
jsr-53: JavaTM Servlet 2.3 and JavaServer PagesTM 1.2 Specifications，定义了 Servlet 和 JSP 的标准；
jsr-367: JavaTM API for JSON Binding (JSON-B)，定义了 Java 对象到 JSON 之间转换(序列化/反序列化) 的标准；
…

除此之外还有许多其他的定义，如 EJB，JSF (JavaServer Faces)，CDI (Contexts and Dependency Injection)，JavaMail 等，这里其实可以不用太过关注，在需要深入理解的时候再阅读其文档即可。

参考资料:

Servlet

Servlet 可以说是 Java Web 开发中基础的基础。可能和我差不多的中年人都会知道早期 Web 开发大多是基于 CGI 的，即写一个二进制程序或者 Perl 脚本去处理 Web 服务器的 HTTP 请求，请求的内容会封装到环境变量里。Sun 公司在 1996 年发布 Servlet 技术就是为了和 CGI 进行竞争，Servlet 这个名字是 Server Applet 的缩写，即服务端小程序。

从上面的介绍也可以看到，Servlet 本身也是一个 Java EE 的标准，比如 Java Servlet 3.1 就是其中一个版本。一般开发者可能很少需要直接阅读标准文档，且文档中也说明其目标主要是 Web 服务器的开发者。不过作为安全研究人员，我们可以从中学习到很多 Servlet 的基础架构和设计思想。

从实现上来说，Servlet 是一个实现了特定接口的 Web 组件，由 Servlet 容器去加载并运行。容器 本身并不一定是 Web 服务器，但容器需要至少支持 HTTP 请求，并将请求的内容封装成 Servlet 接口的参数；因此容器通常与 Web 服务器集成或者作为其拓展而存在。目前常见的 Servlet 容器如 Tomcat、GlassFish、JBoss 等，同样也具备 Web 服务器的功能。

根据文档所述，一个基础的 Servlet 接口如下所示:

package javax.servlet;
import java.io.IOException;

public interface Servlet {
    void init(ServletConfig var1) throws ServletException;
    ServletConfig getServletConfig();
    void service(ServletRequest var1, ServletResponse var2) throws ServletException, IOException;
    String getServletInfo();
    void destroy();
}

其中重要的接口是 service 方法，用于处理客户端的请求，并填充所需的返回结果。init 和 destory 是生命周期方法，在 Servlet 被加载和销毁时只执行一次。 getServletConfig 返回的对象是类似 name/value 格式的配置信息，由用户配置文件中进行传入。

HelloServlet

为了方便开发者进行快速的原型开发，在 JDK 中已经实现了常用的 Servlet 功能，即 GenericServlet，而对于 HTTP 请求，又进一步实现了 HttpServlet 抽象类。这样，如果用户需要编写一个 Servlet 处理如 GET/POST 请求，只需要重写对应的方法即可。

使用 IDEA 自动创建的示例 Servlet 如下:

import java.io.*;
import javax.servlet.http.*;
import javax.servlet.annotation.*;

@WebServlet(name = "helloServlet", value = "/hello")
public class HelloServlet extends HttpServlet {
    private String message;

    public void init() {
        message = "Hello World!";
    }

    public void doGet(HttpServletRequest request, HttpServletResponse response) throws IOException {
        response.setContentType("text/html");

        // Hello
        PrintWriter out = response.getWriter();
        out.println("");
        out.println("" + message + "
");
        out.println("");
    }

    public void destroy() {
    }
}

值得注意的是，正常情况下定义好 HelloServlet 类之后，容器并不知道这个类的存在，也不知道应该将什么 HTTP 路径映射到这个 Servlet，传统上需要用户自己修改 web.xml 配置文件(这也是 Servlet 标准的一部分)，添加和标签来指定这些信息。在 Servlet 3.0 之后，就可以使用注解的方式配置 Servlet 了，如上面的 WebServlet 注解。

Filter

Servlet 中另一个常用的特性是 Filter，用于为所有 Servlet 添加全局性的鉴权和过滤，一个简单的示例如下:

import javax.servlet.*;
import javax.servlet.annotation.WebFilter;
import java.io.IOException;
import java.io.PrintWriter;

@WebFilter(filterName = "HelloFilter", urlPatterns = {"/*"})
public class HelloFilter implements Filter {

    @Override
    public void init(FilterConfig filterConfig) throws ServletException {

    }

    @Override
    public void doFilter(ServletRequest servletRequest, ServletResponse servletResponse, FilterChain filterChain) throws IOException, ServletException {
        String passwd = servletRequest.getParameter("passwd");
        if (passwd != null && passwd.equals("123456")) {
            filterChain.doFilter(servletRequest, servletResponse);
        } else {
            try (PrintWriter out = servletResponse.getWriter()) {
                out.println("passwd error!");
            }
        }
    }

    @Override
    public void destroy() {

    }
}

其中同样使用了注解来添加，如果使用配置文件的方式，可以在 web.xml 中加上对应的、标签。这里有个比较值得注意的点事 urlPatterns 的匹配方式，一开始我以为是正则表达式，但其实在 Servlet 的标准中有明确的定义，比如优先进行精确匹配，否则使用最长的路径匹配，然后是后缀匹配等，规则定义在标准的 12 章 (Mapping Requests to Servlets) 中，可以配合容器的源码去进行分析。

另外 Servlet 标准中还支持注册 Listener 作为监听器，实现上下文、会话、请求的监听能力，主要用于线上人数的统计和会话的监控和处理。实现方法与 Servlet/Filter 大同小异，这里就不再举例了。

Servlet 的标准经过了多个版本的迭代，一些关键的版本和特性如下:

Java Servlet 2.0 (1997): JDK 1.1
Java Servlet 2.1 (1998): 第一个官方版本的标准，增加 RequestDispatcher 和 ServletContext；
Java Servlet 2.2 (1999): 正式成为 J2EE 的一部分，引入 .war 独立 web 应用格式；
Java Servlet 2.3 (2001): 增加 Filter API，即上文介绍的过滤器；
Java Servlet 2.5 (2005): 要求 Java SE 5，开始支持注解；
Java Servlet 3.0 (2009): 改善注解处理，引入了 @WebServlet、@WebFilter 等注解支持部分参数化；支持文件上传；
Java Servlet 3.1 (2013): 支持非阻塞 I/O，Websocket；
Java Servlet 4.0 (2017): 支持 HTTP/2；
Jakarta Servlet 4.0.3 (2019): 捐赠给 Eclipse 开源基金，重命名 Java 商标；
Jakarta Servlet 5.0 (2020): 包名从 javax.servlet 转为 jakarta.servlet；
Jakarta Servlet 6.0 (2022): 增加了一些没人关心的特性；

完整的列表可以参考 Wikipedia 中的 Servlet API history 一节。

JSP

虽然我们可以用 Servlet 来生成网页中的动态内容，但这个过程相对繁琐。从上面的示例代码中可以看出，所有文本和标签都是硬编码，即使只做出微小的修改，也需要对源码进行重新编译和部署。JSP 解决了 Servlet 的这些问题，它是 Servlet 很好的补充，可以专门用作为用户呈现视图（View），而 Servlet 作为控制器（Controller）专门负责处理用户请求并转发或重定向到某个页面。

JSP 的全称是 Java Server Pages，包含一系列技术的组合，既表示动态网页的框架，也表示一种文件类型。JSP 的标准为 JSR 245，其中包含两个主要文档，分别是 JSP 的标准文档和 JSP EL 表达式的标准。

基本语法

JSP 的基本语法可以总结如下:

<% code %> scriptlet 可以用来包裹和执行 Java 代码，也可以用标签来进行包含；
<%! declaration; [ declaration; ]+ ... %> 用于变量声明，同；
<%= expr %> 用来包括和执行表达式，表达式的结果作为 HTML 的内容，同；
<%-- comment --%> 为 JSP 注释，注释中的内容会被 JSP 引擎忽略；
<%@ directive attribute="value" %> 指令，影响对应 Servlet 的类结构，后面细说；
使用 XML 控制 Servlet 引擎的的行为，称为 action；
…

完整的语法可以参考本节末尾的 JSP Tutorial 或者相关教程。

JspServlet

JSP 作为一个脚本引擎，其本质上也是通过 Servlet 实现的，即 JSP 会被容器编译为对应的 Servlet 并加载。例如，下述简单的 index.jsp 文件:

<%@ page contentType="text/html;charset=UTF-8" language="java" %>
 config = <%=config%>

在被 Tomcat 容器加载后会生成如下的 Java 文件:

package org.apache.jsp;

import javax.servlet.*;
import javax.servlet.http.*;
import javax.servlet.jsp.*;

public final class index_jsp extends org.apache.jasper.runtime.HttpJspBase
    implements org.apache.jasper.runtime.JspSourceDependent,
                 org.apache.jasper.runtime.JspSourceImports {

  private static final javax.servlet.jsp.JspFactory _jspxFactory =
          javax.servlet.jsp.JspFactory.getDefaultFactory();

  private static java.util.Map<java.lang.String,java.lang.Long> _jspx_dependants;

  private static final java.util.Set<java.lang.String> _jspx_imports_packages;

  private static final java.util.Set<java.lang.String> _jspx_imports_classes;

  static {
    _jspx_imports_packages = new java.util.HashSet<>();
    _jspx_imports_packages.add("javax.servlet");
    _jspx_imports_packages.add("javax.servlet.http");
    _jspx_imports_packages.add("javax.servlet.jsp");
    _jspx_imports_classes = null;
  }

  private volatile javax.el.ExpressionFactory _el_expressionfactory;
  private volatile org.apache.tomcat.InstanceManager _jsp_instancemanager;

  public java.util.Map<java.lang.String,java.lang.Long> getDependants() {
    return _jspx_dependants;
  }

  public java.util.Set<java.lang.String> getPackageImports() {
    return _jspx_imports_packages;
  }

  public java.util.Set<java.lang.String> getClassImports() {
    return _jspx_imports_classes;
  }

  public javax.el.ExpressionFactory _jsp_getExpressionFactory() {
    if (_el_expressionfactory == null) {
      synchronized (this) {
        if (_el_expressionfactory == null) {
          _el_expressionfactory = _jspxFactory.getJspApplicationContext(getServletConfig().getServletContext()).getExpressionFactory();
        }
      }
    }
    return _el_expressionfactory;
  }

  public org.apache.tomcat.InstanceManager _jsp_getInstanceManager() {
    if (_jsp_instancemanager == null) {
      synchronized (this) {
        if (_jsp_instancemanager == null) {
          _jsp_instancemanager = org.apache.jasper.runtime.InstanceManagerFactory.getInstanceManager(getServletConfig());
        }
      }
    }
    return _jsp_instancemanager;
  }

  public void _jspInit() {
  }

  public void _jspDestroy() {
  }

  public void _jspService(final javax.servlet.http.HttpServletRequest request, final javax.servlet.http.HttpServletResponse response)
      throws java.io.IOException, javax.servlet.ServletException {

    if (!javax.servlet.DispatcherType.ERROR.equals(request.getDispatcherType())) {
      final java.lang.String _jspx_method = request.getMethod();
      if ("OPTIONS".equals(_jspx_method)) {
        response.setHeader("Allow","GET, HEAD, POST, OPTIONS");
        return;
      }
      if (!"GET".equals(_jspx_method) && !"POST".equals(_jspx_method) && !"HEAD".equals(_jspx_method)) {
        response.setHeader("Allow","GET, HEAD, POST, OPTIONS");
        response.sendError(HttpServletResponse.SC_METHOD_NOT_ALLOWED, "JSPs only permit GET, POST or HEAD. Jasper also permits OPTIONS");
        return;
      }
    }

    final javax.servlet.jsp.PageContext pageContext;
    javax.servlet.http.HttpSession session = null;
    final javax.servlet.ServletContext application;
    final javax.servlet.ServletConfig config;
    javax.servlet.jsp.JspWriter out = null;
    final java.lang.Object page = this;
    javax.servlet.jsp.JspWriter _jspx_out = null;
    javax.servlet.jsp.PageContext _jspx_page_context = null;


    try {
      response.setContentType("text/html;charset=UTF-8");
      pageContext = _jspxFactory.getPageContext(this, request, response,
      			null, true, 8192, true);
      _jspx_page_context = pageContext;
      application = pageContext.getServletContext();
      config = pageContext.getServletConfig();
      session = pageContext.getSession();
      out = pageContext.getOut();
      _jspx_out = out;

      out.write("\n");
      out.write(" config = ");
      out.print(config);
      out.write(" 
");
    } catch (java.lang.Throwable t) {
      if (!(t instanceof javax.servlet.jsp.SkipPageException)){
        out = _jspx_out;
        if (out != null && out.getBufferSize() != 0)
          try {
            if (response.isCommitted()) {
              out.flush();
            } else {
              out.clearBuffer();
            }
          } catch (java.io.IOException e) {}
        if (_jspx_page_context != null) _jspx_page_context.handlePageException(t);
        else throw new ServletException(t);
      }
    } finally {
      _jspxFactory.releasePageContext(_jspx_page_context);
    }
  }
}

代码有点长，其中有几个重点:

生成的类名与 jsp 文件名相同，不合法的字符会转换为 _，比如 index.jsp 会生成 index_jsp， 1.jsp 会生成 _1_jsp；
生成的 Java 类继承自抽象类 HttpJspBase，这个类继承自 HttpServlet；
_jspInit、_jspDestory 对应 Servlet 中的生命周期函数；_jspService 中处理客户端的请求，JSP 中的 Java 代码也会转移到这里；

该类在第一次访问的时候才会生成、编译、加载，因此对于没访问过的页面是没有对应文件的。另外，在 _jspService 方法中为了方便 JSP 的代码编写，定义了几个常用的对象，比如:

request，对应客户端请求的 HttpServletRequest 对象；
response，对应返回的 HttpServletResponse 对象；
session，对应 HttpSession，存储当前请求会话信息；
application，对应 ServletContext，用于全局共享数据；
config，对应 ServletConfig 即 Servlet 的配置对象；
page，为 Object 类型，指向当前 Servlet 对象；
out，即控制页面输出的 JspWriter；
pageContext，当前页面共享数据对象；

这几个对象通常称为 JSP 的 “八大对象”，或者 “九大对象” (算上 exception 对象)。

标签库与 JSTL

前面介绍 JSP 语法的时候提到过 directive 的语法，即 <%@ directive attribute="value" %>。在 JSP 中有三种指令类型，分别是:

<%@ page ... %> 用于定义页面相关的属性，比如脚本语言类型、错误页面和缓存等；
<%@ include ... %> 用语言在脚本翻译阶段包含其他文件；
<%@ taglib ... %> 引入标签库的定义；

其中标签(tag)是指的是在 JSP 中一个可重用的动态组件，类似于 HTML 或者 XML 的标签，只不过多用于生成动态内容。taglib 就是一系列自定义标签的集合。JSP 支持让用户自定义标签，同时也提供了标准的标签库来方便开发，这个标准库就是 JSTL。JSTL 中常见的标签库有下面这些:

核心标签库 (uri=“http://java.sun.com/jsp/jstl/core")
- - 输出字符串
- - 条件处理
- - 集合遍历
格式化标签库 (uri=“http://java.sun.com/jsp/jstl/fmt")
- - 格式化并显示消息
- - 格式化日期
SQL 标签库 (uri=“http://java.sun.com/jsp/jstl/sql")
- - 指定数据源并使其可用于 SQL 操作
- - 执行 SQL 查询并迭代结果集
- - 通过执行 SQL 语句更新数据源
XML 标签库（uri=“http://java.sun.com/jsp/jstl/xml"）
- - 解析 XML 文档
- - 遍历 XML 文档
- - 输出结果
函数标签库 (uri=“http://java.sun.com/jsp/jstl/functions")

关于这些标签库提供的完整功能可以参考官方文档 JavaServer Pages Standard Tag Library 1.1 Tag Reference。一个使用核心标签库的示例 JSP 如下所示:

<%@ page contentType="text/html; charset=UTF-8" pageEncoding="UTF-8" %>
<%@ taglib uri="http://java.sun.com/jsp/jstl/core" prefix="c" %>

JSTL c:out Example

c:out 的输出类似于 <%= 的输出，只不过前者是针对表达式，关于表达式在后文中会另外进行介绍。

注意在 Tomcat 或者 Jetty 这种轻量级的容器内使用 JSTL 需要安装对应的依赖，可以参考 JSTL - Stackoverflow 中的相关介绍。

虽然在前后端分离的开发浪潮中 JSP 似乎已经日渐式微，但在网站快速原型开发中 JSP 还占有一席之地，而且许多历史项目也是基于 JSP 进行开发，因此对其了解还是有必要的。

参考资料:

Java 表达式语言

上节中我们说到 JSP 的标准中包含了两份文档，一份是 JSP 语言本身的标准，另一份则是表达式语言的标准。Java 表达式语言即 Expression Language，简称为 EL，最初就是为了在 JSTL 中使用便捷的表达式解析而出现的。虽然 JSP 中可以写 Java 代码，但这一方面对不懂 Java 语言的人不太友好，另一方面很多时候我们仅需要在 JSP 中执行比较、循环、加减乘除等简单操作，而引入完整的 Java 引擎显得有点 overkill 了。

在最初的版本中，Java EL 被称为 SPEL(Simplest Possible Expression Language) 或者 JUEL(Java Unified Expression Language)，注意不要和 Spring 的 SpEL(Spring Expression Language) 搞混。EL 的语法被设计得和 javascript 类似，比如:

无法强制类型转换，转换过程是隐式的；
单引号和双引号等价；
object.property 和 object['property'] 实现的效果基本相同；
抽象属性的类型，object.property 根据属性的类型不同，实际上可能会调用 object.get("property")、object.getProperty("property") 或者 object.getProperty() 等；

EL 的标准也经过了多个版本的迭代，在 EL 2.1 版本时，为了综合考虑 JSF 等技术的需要，对 EL 的功能进行了拓展，比如增加了延迟表达式(Deferred expressions)，使得表达式不用在 JSP 翻译的过程就被执行；另外提供了 get/set 去获取/修改对象属性的能力，以及方法表达式支持调用 Java 对象的方法。

EL 3.0 中正式将 EL 的标准从 JSP/JSF 的标准中独立出来，编号为 JSR-341。这个版本中在 EL 中增加了类似 Java8 Stream 和 lambda 表达式的功能，几个简单的示例如下:

public class ELTestServlet extends HttpServlet {
    @Override
    public void doGet(HttpServletRequest req, HttpServletResponse res)
            throws ServletException, IOException {
        
        List list = new ArrayList<>();
        list.add(Double.valueOf(1.0));
        list.add(Double.valueOf(2.0));
        list.add(Double.valueOf(3.0));

        ELProcessor elp = new ELProcessor();
        elp.defineBean("data", list);    

        Object message = (Double)elp.eval(
            "n = data.stream().count(); s = data.stream().sum(); sq = data.stream().map(i -> i*i).sum(); Math.sqrt(sq/n - Math.pow(s/n, 2))");
        res.getWriter().println(message);

        message = (Double)elp.eval(
            "n = 0; s = 0; sq = 0; data.stream().forEach(d -> (n = n + 1; s = s + d; sq = sq + d*d)); Math.sqrt(sq/n - Math.pow(s/n, 2))");
        res.getWriter().println(message);

        message = (Double)elp.eval(
            "n = 0; s = 0; sq = data.stream().reduce(0, (a, i) -> (n = n + 1; s = s + i; a + i*i)); Math.sqrt(sq/n - Math.pow(s/n, 2))"); 
        res.getWriter().println(message);
    }
}

目前最新的 EL 标准是 2020 年 4.0 版本，这个版本中将包名从 javax.el 移到了 jakarta.el。除了 Java EE 中定义的 EL 表达式标准和实现，在许多三方库中也实现了类似的表达式语言功能，包括但不限于:

OGNL: Object-Graph Navigation Language，一个开源的表达式语言实现，在许多其他项目中被使用，比如 Struts2、Spring Web Flow、MyBatis、FreeMarker 等；
MVEL: MVFLEX Expression Language，另一个开源的表达式语言实现，一些知名的 Java 项目使用其作为表达式引擎，比如 JBoss Drools、Hibernate ORM、JIRA 等；
SpEL: Spring 框架中使用的表达式语言，除了 Spring 宇宙中的组件，还有其他 Java 项目也是用了该引擎，比如 Thymeleaf、Apache Camel、Apache Sling 等；
JEXL: 即 Apache Commons JEXL(Java EXpression Language)，参考 Java EL 和 Apache Velocity 实现的一个表达式语言，语法接近于 JavaScript 和 Shell 脚本；

这类表达式语言通常作为模版语言在 Web 页面中使用，如果其中的表达式能够被恶意输入所控制，就可能出现任意代码执行的危害。历史上出现过许多由于 EL 表达式注入导致的远程代码执行，因此这算是 Java 中高危的攻击面之一。

JDBC

在传统 MVC 架构中，将内容呈现的过程分成模型(Model)，视图(View)，控制器(Controller)三个部分，现在我们已经介绍了控制器部分的 Servlet，视图层的 JSP，为了使得一个网页能够真正有价值，还缺少其中关键的模型部分，即数据来源。

JDBC (Java Database Connectivity) 就是 Java 访问数据库的一个标准。历史上在 JDK 1.1 中 JDBC 就已经是其中的一部分，也就是说 JDBC 本身也是 Java SE 的标准，但也包含在 Java EE 中。其包名可通过 java.sql 或者 javax.sql 进行访问。

JDBC 标准现在由 JCP 维护，主要经过以下几个版本的迭代:

JSR 54: JDBC 3.0 Specification (J2SE 1.4)
JSR 114: JDBC Rowset Implementations
JSR 221: JDBC 4.0 API Specification (Java SE 6)
JSR 221 Release 1: JDBC 4.1 (Java SE 7)
JSR 221 Release 2: JDBC 4.2 (Java SE 8)
JSR 221 Release 3: JDBC 4.3 (Java SE 9)

不同版本的 JDBC 主要引进了一些新的特性，比如 JDBC 4.0 支持自动加载数据库驱动，4.1 支持 try-with-resource，大对象(LOB)更新等；主要的框架并没有太大变化。

JDBC API 的常见用法如下:

 import java.sql.*;

 public class TestJdbc {
   public static void main(String[] args) throws Exception {
     // Class.forName("com.mysql.jdbc.Driver");

     // 1. Establishing the connection with the database
     Connection conn = DriverManager.getConnection(
       "jdbc:mysql://localhost:3306/mydb?useSSL=false", "root", "rxhtemp");

     // 2. Creating a statement object to execute a query
     Statement stmt = conn.createStatement();

     // 3. Executing the query and getting the ResultSet
     ResultSet rs = stmt.executeQuery("SELECT * FROM user");

     // 4. Processing the ResultSet
     while (rs.next()) {
       int id = rs.getInt("id");
       String name = rs.getString("name");
       System.out.println("ID: " + id + ", Name: " + name);
     }

     // 5. Closing the database resources
     rs.close();
     stmt.close();
     conn.close();
   }
 }

Class.forName 显式导入驱动的方式在新版本已经不需要了，不过这个方式有利于让开发者理解 JDBC 使用的具体数据库驱动，一些例子如下:

PostgreSQL : org.postgresql.Driver
Oracle : oracle.jdbc.driver.OracleDriver
Microsoft SQL Server : com.microsoft.sqlserver.jdbc.SQLServerDriver
SQLite : org.sqlite.JDBC
H2 : org.h2.Driver
Apache Derby : org.apache.derby.jdbc.ClientDriver
MariaDB : org.mariadb.jdbc.Driver
IBM DB2 : com.ibm.db2.jcc.DB2Driver
Informix : com.informix.jdbc.IfxDriver

如果想实现自己的驱动，需要实现 java.sql.Driver 接口，其中一些关键方法有 connect、acceptsURL 等。connect 方法中会接受到传入的 URL 以及相关属性(如账号、密码)。实际上 DriverManager 查询驱动的方式也很简单，即通过循环遍历已注册的驱动 registeredDrivers，然后逐个调用其 driver.connect 方法，如果发现不为空就返回。registeredDrivers 是个列表结构，因此先添加的驱动会优先执行。

另外如果驱动中实现的有问题，且攻击者可以污染传入的 URL 或者 Property，也有可能间接造成代码执行，关于这类攻击可以参考 New Exploit Technique In Java Deserialization Attack。

JMX

JMX 全称为 Java Management Extensions，即 Java 管理拓展，主要用于管理和监控 Java 程序。常见的监控资源有 CPU 占用率、线程数、JVM 内存等。下面是一些相关标准的定义:

JSR 3: Java Management Extensions (JMX) Specification，包含 JMX 1.0/1.1/1.2 的标准；
JSR 160: Java Management Extensions (JMX) Remote API；
JSR 262: Web Services Connector for Java Management Extensions (JMX) Agents；

我们常用的 JConsole、VisualVM，以及现在流行的 Spring Boot 框架中的 Spring Boot Actuator 内部都使用了 JMX 拓展，因此对其进行了解有助于我们更好地认识这些应用和框架。

组件

JMX 主要包括几个关键组件，下面分别进行介绍。

MBean，全称是 Managed Bean，类似于 Java Bean，主要用来进行消息传递。与 Java Bean 的区别是 JMX 中对这些 Bean 进行了额外的定义，兼容 JMX 标准的 MBean 才可以被加载。在 java.lang.management 中定义了许多 JDK 提供的 MBean，包括 Memory、Thread 相关的 MBean，用于传递 JVM 应用的内存和线程相关信息。我们平时使用 jconsole 去分析 Java 应用时所展现的数据大多来源于这些 MBean。

MBeanServer，主要用于 MBean 的管理，同名接口定义在 javax.management 中，包含 MBean 创建、注册以及删除等操作相关的接口。一般用户不会直接实现该接口，而是通过 MBeanServerFactory 工厂类去获取 MBeanServer 实例。通常一个 Java 虚拟机中只会有一个 MBeanServer，只有注册到 MBeanServer 中的 MBean 才能被进行管理，即能够被连接到 MBeanServer 的客户端远程访问其属性和相关方法。

Connector/Adaptor，这是直接面对客户端的组件，负责具体协议的连接或者转换。在 JMX 标准中提到，RMI Connector 是在 JMX 标准实现中唯一强制实现的协议。RMI (Remove Method Invocation) 是 Java 中的远程调用接口，其具体的传输协议可以不同，常见有以下两种:

JRMP (Java Remote Method Protocol)，这是 RMI 的默认传输协议，专为 Java 而开发，因此性能较好；
IIOP (Internet Inter-ORB Protocol)，CORBA 标准的一部分，依赖于 CORBA 类库，因此可以实现多语言传输 RMI 远程对象，更适用于跨平台开发；

除了 RMI Connector，JMX 中还定义了 Generic Connector 即通用连接器的标准。基于上文 JSR 160 提到的 JMX Remote API 来实现可配置和可插拔的连接器，包括传输协议和对象封装等接口。JMXMP，即 JMX Remote API over Message Service Protocol，就是一种通用连接器实现。客户端和服务器之间通过消息进行通信，消息可以是纯文本或二进制格式。JMXMP 支持基于 SSL/TLS 对连接进行加密，同时还有连接池、心跳等功能。

Adaptor 称为适配器，和连接器类似，主要将客户端对服务器中 MBean 的操作适配为其他协议，比如 SNMP 或者 HTTP 等。例如，Jolokia 就是一个常用的开源 JMX-HTTP 适配器，可以使远程的 JMX 客户端通过 HTTP/HTTPS 协议访问 JMX MBean。

示例

假设我们是某个服务端应用，需要对外暴露一些监控信息，这种情况下就可以自定义一个 MBean 实现。JMX 要求 MBean 首先需要是一个接口，且接口名字以 MBean 结尾，例如:

public interface DemoMBean {
    String getName();
    String getPassword();
    void say(String what);
}

一个具体的 MBean 需要实现上述接口:

class Demo implements DemoMBean {
    @Override
    public String getName() { return "evilpan"; }
    @Override
    public String getPassword() { return "jmxdemo"; }
    @Override
    public void say(String what) {
        System.out.println(getName() + " say: " + what);
    }
}

为了能够被客户端访问，需要将该 MBean 的实例注册到 MBeanServer:

MBeanServer server = ManagementFactory.getPlatformMBeanServer();
ObjectName userName = new ObjectName("com.evilpan:type=Foo,name=bar");
server.registerMBean(new Demo(), userName);

其中 userName 是在 JMX MBean 中显示的名称，上述示例在 jconsole 的 MBeans 中查看有以下结构:

 com.evilpan
 └─ Foo
    └─ bar
       ├─ Attributes
       │  ├─ Password
       │  └─ Name
       └─ Operations
          └─ say

点击 Attributes 中的 Name 和 Password 会调用对应的 getName 和 getPassword 方法来获取信息，而点击 say 可以调用对应 MBean 实例的方法，并指定相关参数。

这里是使用 jconsole attach 本地应用的方式连接 MBeanServer 的，实际应用中可以通过 RMI 协议去让客户端进行远程管理，关键代码如下:

MBeanServer server = ManagementFactory.getPlatformMBeanServer();
// Register MBean ...
LocateRegistry.createRegistry(7890);
JMXServiceURL url = new JMXServiceURL("service:jmx:rmi:///jndi/rmi://localhost:7890/jmxrmi");
JMXConnectorServer jcs = JMXConnectorServerFactory.newJMXConnectorServer(url, null, server);
jcs.start();

当然，实际上 Java 本身也提供了内置的 JMX 连接器功能，可以通过命令行启动指定属性去开启，比如:

java -Dcom.sun.management.jmxremote.port=7890 \
  -Dcom.sun.management.jmxremote.authenticate=false \
  -Dcom.sun.management.jmxremote.ssl=false \
  -cp target/classes com.example.demo.BeanTest

和上面自行添加 RMI 监听效果是一样的。其中 RMI registry 的端口为 7890，JMXServiceURL 路径的结尾可以随意指定，但如果需要用 jconsole来进行连接，则必须使用 /jmxrmi。

实际应用中更多使用 -Dcom.sun.management.config.file 指定 JMX 相关的配置

应用启动后也可以通过 nmap 来查看对应端口信息:

$ nmap localhost -p 7890,56097 -sVC
PORT     STATE SERVICE  VERSION
7890/tcp open  java-rmi Java RMI
| rmi-dumpregistry:
|   jmxrmi
|     javax.management.remote.rmi.RMIServerImpl_Stub
|     @127.0.0.1:56097
|     extends
|       java.rmi.server.RemoteStub
|       extends
|_        java.rmi.server.RemoteObject
56097/tcp open  java-rmi Java RMI

上面监听的 56097 端口是实际的 JMX-RMI Connector 监听端口，被注册为 RMI Nameing Registry 中的 jmxrmi 名称。

从上面的介绍中可以看出，JMX 在 Java 应用管理和监控中的作用很大，但同时也暴露了很大的风险，如果服务端的 JMX 管理端口能被攻击者访问，就可能泄露敏感数据，或者被调用任意的 MBean 方法从而导致代码执行等危害。另外由于 RMI 是 JMX 默认的连接器，因此历史上也出现过许多针对 RMI 的攻击和反序列化漏洞，这里就先不展开了，其中相关的利用技巧和深入介绍可以参考下面的文章:

后记

写到这里，可以说对 Java 安全有了一个比较基本的了解。Java 生态历经了几十年的发展，直到今天依旧在企业级服务端应用中占有半壁江山。从文中可以看到 Java 一直致力于提供高可用、可拓展的标准，有一些标准由于设计复杂接受度不高(如 EJB)，但也有很多标准从初稿到现在依然是主流(如 JNDI、JMX)。文中所介绍的几个功能应该算是 Java 初学者最先接触的技术，虽然只是冰山一角，但通过对这些技术的学习可以让我们管窥 Java EE 的全貌，也为后续针对性的研究打好基础。

版权声明: 自由转载-非商用-非衍生-保持署名 (CC 4.0 BY-SA)
原文地址: https://evilpan.com/2023/04/01/java-ee/
微信订阅: 『有价值炮灰』
– TO BE CONTINUED.

我TM就是管住不自己这双手啊

Sun, 20 Sep 2020 12:40:00 +0800

博客从 Jekyll 迁移到 Hugo，以及最近一些折腾的感悟。

个人博客那些事

其实从很早的时候就开始了个人博客网站的搭建，最初得益于 github.io 域名的开放。总的来说，我搭建博客的历史主要分为三个阶段。

第一阶段

第一阶段属于简单至上主义。这个时期使用 Jekyll 作为主要的静态博客生成引擎，可以方便地使用 Markdown 来进行写作，并且这也是 Github Pages 官方支持的。

Jekyll

最初是使用了一个简单的模板，后来随着需求日益增加，比如需要标签、目录、侧边栏等功能，于是又转投了另一个主题。

第二阶段

由于在第一阶段中日益增长的定制需求和静态博客的限制矛盾，这个时期开始了一段折腾的造轮子历程。在这个阶段，我用 Python (Django) 写了一个完整博客系统，命名为 berserk (因为当时喜欢听阿姆)。该博客支持以下功能:

支持 Markdown 渲染，文章目录、代码语法高亮、自适应文章布局
支持文章分类、标签，以及这些属性的数据库管理
支持页面访问统计、评论
支持后台管理 (基于定制的Django-Admin)
支持在后台使用类似 VIM 的键盘映射来编写文章
支持真实后台管理页面的隐藏以及虚假后台页面的蜜罐和告警 (没错)

此外因为当时工作接触了一些新潮前端概念，还尝试将一套前后端分离的模式融入到系统中。学习 ReactJS 并折腾了一段时间后发现和 Django 原本的模板系统格格不入，然后就又去掉了。

berserk

这个博客系统一直缝缝补补并使用了很一段时间，充满了各种奇怪的前后端 tricks。期间也遇到过各种问题，比如整天被乌克兰的机器人在评论区发广告，于是又加入了人机验证，诸如此类。……直到有一天发现这一切和我的初衷(写博客)似乎没什么直接关系，于是又怀念起了以前用 Jekyll 的那段开心时光。

第三阶段

在自建博客前后端被搞的焦头烂额之后，我又回到了 Jekyll 的怀抱。其实是在自建博客期间看到了许多优秀的 Jekyll 主题完全可以满足我的要求，所以才最终回归。并且在内心暗暗下决心: 再也不折腾了。

不过还是小小折腾了一下，在此期间对一个小众的主题进行了一些简单的定制和优化。这个阶段算是返璞归真，没有了后端的琐事，可以简单地对主题模板进行修改。基于对 Jekyll 模板的了解，这些事情算是驾轻就熟，可以说对博客页面的折腾已经到头了。

合影留念

这个系统也一直使用了较长的时间，一切都挺满意，除了头顶的几片乌云:

博客访问统计使用的是不算子，服务器在国外，而且数据不可控；
网页常规同步加载，在图片等资源多的时候会感觉速度很慢；
Jekyll 使用 Ruby，安装繁琐，构建速度极慢；
…

第3点的依赖问题可以通过 bundle 或者直接使用 docker 来解决，但是编译构建的速度着实堪忧，比如才几十篇文章，在服务器上构建就需要长达 15秒 的时间:

$ docker run -it --rm -v $PWD:/srv/jekyll -p 4000:4000 jekyll/jekyll jekyll serve -s /srv/jekyll
ruby 2.6.5p114 (2019-10-01 revision 67812) [x86_64-linux-musl]
Configuration file: /srv/jekyll/_config.yml
            Source: /srv/jekyll
       Destination: /srv/jekyll/_site
 Incremental build: disabled. Enable with --incremental
      Generating...
                    done in 15.28 seconds.
 Auto-regeneration: enabled for '/srv/jekyll'
    Server address: http://0.0.0.0:4000/
  Server running... press ctrl-c to stop.

所以，我又开始折腾了。……但是这次没有忘记初衷，而是选择了 Hugo 加一个比较活跃的主题，因为我不想在前端的修改上花费时间，也不想花太多时间去研究新的模板语法(不过最终还是提了pull request)。

meme

总之，博客还是从 Jekyll 迁移到了 Hugo。迁移过程不算太顺利，因为二者对 Markdown 的元数据理解不同，而且整站的路径也不一样，但通过编写迁移脚本可算实现了。

新的博客可以直接通过 https://evilpan.com 访问。

感悟

其实改来改去，对于最终的阅读者(如果有的话)并不会产生太大影响。就我个人而言，反而不太喜欢那些花里胡哨的博客主题，比如背景弄一些酷炫的 canvas 搞得电脑风扇直转。从阅读者的角度来说，(博客)网站只需要做到:

良好的阅读体验，包括字体、图片、颜色，别搞些绿底黄字的非人间配色；
文章长的话最好有目录，方便阅读；
链接的持久性，不要让阅读者在百度或者其他地方索引过来发现是 404；
RSS (当然也可以不提供，需要的人可以用 feed43 之类的爬虫，但是没必要)；

这些一般的博客引擎都能满足，实在没有瞎折腾的必要。而对于博客本身，其实最重要的只有一个 —— 文章质量！其他的都是扯谈，如果是内容农场那就另当别论。

关于 credit

很多人在自建博客时习惯把底部的 credit 去掉，比如 Power by Hugo / Theme By XXX 这种信息。我以前也会这样，一方面是为了简洁，另一方面也是希望能有一些“个性”，生怕宝藏主题被别人抄去了导致烂大街；或者就是干脆想让别人认为这是自己写出来的。

其实大可不必。首先你不是一个前端工程师，所以前端技能并不是别人想要从你身上学习的点。反过来说，如果你是前端，那么自己写一套主题那也应该是常规操作，投机取巧并不能让你自己有所受益；其次，留下主题信息可以让更多看到的人去使用是件好事，获得更多关注后就可能潜在引入更多的开源贡献，最终能让你自己获得更好的使用体验；最后，credit 是对原作者劳动成果的一个起码尊重，谁也不想自己辛苦开发或者写的东西被白嫖党滥用。

在看许多国外的 slides 或者文章时候经常看到对于图片、截图如果不是自己画的都会有明显说明来源何处，国内经常就是拿来就用，当然俺也一样，不过已经在改了。

关于时间

年轻的时候喜欢做加法，奉行 艺多不压身 的准则，对于各种不同领域都喜欢去探索和学习，现在也还是会有很多冲动。但是随着任务列表的逐渐变长，里面的很多项目很可能会一直沉睡在收藏夹中。到了一定的阶段，就需要学会管住自己的双手，把时间用在刀刃上。也就是说，需要学会给人生做减法了。

除了前面提到的博客系统，我还做过很多浪费时间的事情，比如自己写 XSS 盲注后台、DNS服务器(SSRF)、GPS钓鱼系统、写各种命令行工具去实现本可以在网页做到的功能。……

一个朴素的钓鱼系统后台

各种命令行工具，有查单词的:

$ dictionary.py restrain
##########################
### Youdao Translation ###
##########################
restrain: 抑制
us:[rɪˈstreɪn], uk:[rɪˈstreɪn]
=== basic ===
vt. 抑制，控制；约束；制止
=== web ===
restrain: 阻止,抑制,限制
Ratio restrain: 比率制动
restrain test: 栓固试验

$ abbr.py PUA
[+] found 25 results
+------+----------------------------------------+-----------------------------------+------+
| name |                  desc                  |               domain              | rate |
+------+----------------------------------------+-----------------------------------+------+
| PUA  |    Pandemic Unemployment Assistance    |    Miscellaneous / Unclassified   |  5   |
| PUA  |   Potentially Unwanted Applications    |    Miscellaneous / Unclassified   |  4   |
| PUA  |    Potentially Unwanted Application    |        Computing / Software       |  4   |
| PUA  |             Pick Up Artist             |    Community / Performing Arts    |  3   |
| PUA  |            Public Use Area             |    Miscellaneous / Unclassified   |  2   |
| PUA  |         Puas, Papua New Guinea         |      Regional / Airport Codes     |  2   |
| PUA  |            Private Use Area            |             Community             |  2   |
| PUA  |          Personal User Agent           |    Miscellaneous / Unclassified   |  2   |
| PUA  | Professional Underwriters Agency, Inc. |    Business / Companies & Firms   |  1   |
| PUA  |    Professional Underwriters Agency    |        Business / Agencies        |  1   |
| PUA  |           Present under Arms           |    Miscellaneous / Unclassified   |  1   |
| PUA  |       Premium Upgrade Assurance        |    Miscellaneous / Unclassified   |  1   |
| PUA  |    Potentialy Unwanted Application     |    Miscellaneous / Unclassified   |  1   |
| PUA  |       Potentially Unwanted Apps        |    Miscellaneous / Unclassified   |  1   |
| PUA  |      Possession and Use Agreement      |    Miscellaneous / Unclassified   |  1   |
| PUA  |      Portland Urologic Associates      |    Business / Companies & Firms   |  1   |
| PUA  |            Plasma Uric Acid            |   Academic & Science / Chemistry  |  1   |
| PUA  |            Pick Up Artists             |          Community / Art          |  1   |
| PUA  |    Pharos University in Alexandria     | Academic & Science / Universities |  1   |
| PUA  |   Peoples University of the Americas   | Academic & Science / Universities |  1   |
| PUA  |      Pediatric Urology Associates      |        Medical / Pediatric        |  1   |
| PUA  |     Payment Undertaking Agreement      |    Miscellaneous / Unclassified   |  1   |
| PUA  |  Partido de Unificación Anticomunista  |     International / Guatemalan    |  1   |
| PUA  |           Paid Up Additions            |    Miscellaneous / Unclassified   |  1   |
| PUA  | Paul University, Awka - Anambra State  |         Academic & Science        |  0   |
+------+----------------------------------------+-----------------------------------+------+

有查股票的:

命令行炒股

有查 IP 地址的:

$ iplocate.py --on 1.1.1.1
>>>>>> results for 1.1.1.1 <<<<<<
[*] GeoLite : 澳大利亚(AU) - None
[*] Kn0007  : CLOUDFLARE.COMCLOUDFLARE.COM
[*] DBIP    : OC(Oceania),AU(Australia) New South Wales, Sydney
[*] Tencent : 澳大利亚 code(-1) lnglat(149.1333,-35.2667)
[*] IPIP    : ["CLOUDFLARE.COM","","","",""]

复杂一点的还有代理池管理工具，书签管理工具等等:

代理池管理

有些小工具就是三下五除二就弄好了，但是有些就颇花了些时间。要说有没有必要，其实很多都没必要，想要开车并不表示需要自己造轮子。原型开发的过程还是很有趣的，但是其中有许多项目做完之后也就爽那么一下，然后就很长时间都没用过。

为了避免这种做无用功的尴尬，重要的是管理好自己的想法。对于时不时冒出来的 idea 可以先记录下来，到周末或者某个固定时间再进行排序，评估哪些可以做、需要做，哪些可以借助已有的轮子。站在巨人的肩膀上，而不是盲目追求写代码的快感。

曾经的想法是**“因为我可以做，所以我就去做”**，但重要的是管理好自己的精力和时间。学习也是一样，各种新概念层出不穷，开始学习之前需要先评估这究竟是不是你需要的，而不是因为看起来很热门就去投入。

Be curious , but don’t get drown.

关于白嫖

在迁移博客的时候发现 Chrome 新版本对于 https 站点中的所有 HTTP 资源都拒绝加载了，导致以前七牛 CDN 上的图片都无法显示，而七牛的 HTTPS 流量又是收费的，所以我决定换一个图床。为了找一个新的 HTTPS 免费图床，我翻了很多记录，发现很多免费站点都已经无法访问了，最终是选择使用某个博客平台的图片上传功能，为了批量上传还分析了该平台的验签和加密算法。

虽然最终目标实现了，但我也耗费了大半天的时间。都是传统的白嫖思想在作祟，因为从小习惯了免费。免费的聊天工具，免费的游戏，免费的操作系统，免费的杀毒软件，……这其实完全没有道理。如果一个东西做的很好，但是完全不赚钱，那么开发者是否还会投入那么多精力去维护呢？一腔热情投入开源工作，还要面对各种小白的挑刺以及伸手党的催促，个中滋味只有经历过才能体会到吧。

我们花几百块钱吃一顿饭觉得合情合理，但是花几十块钱购买在线服务或者软件就踌躇不决。但是说到底，白嫖终究不是长久之计。一个免费 CDN 需要在流量和速度上进行限制，一个免费的云服务器不会提供可用性保证，一个免费的图床可能说挂就挂，能在下线前告诉你一声已经仁至义尽了。

白嫖在线的服务需要自己承担稳定性和迁移风险，白嫖本地应用需要忍受广告和推送，这世上本就没有免费的午餐。如果上天能给我个再来一次的机会，我想说:

最近看到一篇新闻感觉很有意思，微信推出看一看、小视频等功能，不是因为用户需要，而是面对头条对 用户时间 的蚕食感到不安 —— 用户每天花在微信的时间从 X 小时下降到了 Y 小时，而在头条系产品中投入的时间从 M 小时增加到了 N 小时。第一次对"时间就是金钱"有了别样的认识。

你以为你白嫖赚到了，其实最后被嫖的是你自己。

OPSEC与查水表

Sun, 19 Apr 2020 22:40:00 +0800

偶然在网上看到某“黑客”在吹嘘自己如何通过代理/跳板搞事情，还隐藏了自身痕迹。这样真的有效吗？本文也从技术层面去谈谈这个问题。

什么是OPSEC

OPSEC，全称为Operations Security，即行动安全，也叫作战安全。最先是美国军队提出的一套行动纲领，用于保障国防机密信息安全，包括行动mission、作战单元部署位置和时间、人事交易等等。美军部队中还有专门作战安全主管(OPSEC Officer)，外事不决可以随时询问。

OPSEC不是那种明确定义有1234的行为准则，也不是什么关于特定操作的奇淫技巧，而是一个流程。遵循这个流程可以让你获得最大的安全性。也就是说，OPSEC保障的是行动(Operations)的安全性，不论行动是什么。

一个行动安全流程周期主要分为五个步骤：

下面简要解释一下每个步骤的含义。

1. Analysis

明确你的关键信息(Critical Infomation)，即定义你在这次行动中所需要保护的东西。比如你的IP、C&C、所用工具，组织归属等等。

定义一定要明确，就像KPI一样是求仁得仁的结果。如果你不知道怎么定义，可以参考四象限法则CALI：能力(Capabilities)，活动(Activities)，限制(Limitations)和目的(Intentions)，然后创建一个对应的关键信息列表。

2. Understanding

研究也可以理解为威胁分析，在网络中属于威胁情报的范畴，实际上是为上一步所定义的关键信息列表确定潜在的威胁。这一步写下这些攻击面。

3. Monitoring

在知道自己所面临的攻击面之后，就需要对这些攻击面所可能面临的漏洞。这里说的漏洞不一定是软件漏洞，而是可以突破攻击面的方法。这一步写下这些漏洞。

4. Evaluation

风险评估。现在已经了解了威胁和漏洞，接下来的一步就是创建典型的可能性与影响矩阵，并说明对手滥用这些漏洞的后果。

5. Countermeasures

基于风险评估，确定优先级以及要采取的对应措施。世上没有100%的安全，需要在预算和效果之间进行权衡。

什么是水表

OK，介绍完了OPSEC，我们再来回到最初的问题。这里预设的“行动”场景是网络活动，那么查水表就是目标或者执法机构的溯源和打击过程。当然水表也分为境内和境外的，境外部分是神仙打架，我们主要聚焦于境内的场景。

之前写过一篇介绍内容农场的文章，说到很多写手为了流量肆意编造大新闻，这种可以说是一抓一个准，因为都有实名制要求。那么很多黑产就开动脑筋了，通过购买四件套再匿名作案，是不是就抓不到我啦？

不好意思，抓你的办法有很多，其中一个就是IP定位。早些时候某大厂还提供了高精度IP定位的服务出售，不过因为涉及隐私这种服务已经逐渐下架了。虽然不对外提供，但是很多公司还是有数据的，甚至互通有无形成广告联盟，跟踪特朗普都不在话下：

OPSEC实践

因此，我们就以IP定位为例，来举例说明OPSEC是如何实践的。

第一步，目标定义。这里需要隐藏是我们的真实身份。

第二步，威胁分析。暴露真实身份的场景有很多，其中一个就是物理位置的暴露；暴露物理地址的方式也有很多，IP、基站、WiFi、蓝牙Beacon等等。这里主要关注IP地址。

第三步，漏洞分析。根据TCP/IP原理，研究有可能被利用来找到我们IP地址的exploit。这步是我们着重关注的。

首先，假设自己是无限权限的安全响应人员，在资产受到攻击后进行溯源排查。止血后第一步就是分析应用日志，从日志中定位到攻击者的入口IP地址。这个地址，有几种情况。

对方没用代理。大数据IP定位或者直接联系ISP查档，GG
对方使用PPPOE动态IP，大数据定位或者ISP查入户端口绑定，GG
对方使用代理。一封协查函联系代理服务器提供商或者IDC机房调取日志，取得对应时间的连接地址，goto 1
对方使用境外代理。网络中心调取日志，筛选出攻击时间窗口内连接该境外IP的国内IP，根据其他信息可以大大减少排查范围。

第四步，威胁评估。被查真实IP的后果就是查水表，不多说。

第五步，对策分析。在第三步中我们可以发现，涉及境外的排查显然难度徒增。因此一个对策是使用多级境外代理，或者混合匿名网络Tor/I2P。虽然还是受到时间窗口溯源的威胁，但成本已经极高。

第六步，循环。你以为这样就能高枕无忧了吗？对抗是一个不断升级的过程。比如Tor网络，女巫攻击和中继确认攻击了解一下？更何况在某些国家绝大部分入口节点都是作为鱼饵在管理的，配合上时间窗口锁定目标也只是成本问题罢了。另外客户端上也有不同办法泄露地址，比如PDF外连，浏览器漏洞等等。有些APT使用自组网的僵尸网络(肉鸡)隐藏痕迹，这也是不断对抗升级的结果。

其他

前几年看云风的博客，说他们机房机器异常，但是当时查流量怎么也没找到记录。于是云风怀疑是不是黑客自己重写了TCP/IP协议栈来绕过本地监控。

当然这是有点脑洞大开了，非标准的IP包一般在中间路由器就很可能被丢掉，除非CC直接插在服务器或者交换机上。基于IP的其他Tunnel倒是有的，比如ICMP隧道，但本质上IP到IP的信息并未丢掉，所以不会在根本上影响排查。至于常说的shadow袜子、SSR、V二Ray等，只是传输层或者会话层的加密，与安全性就更扯不上关系了。

后记

本文介绍了OPSEC的基本概念，并以IP地址为例简单分析其实践方法。国外对OPSEC早已有了成熟的运用，比如CIA的HIVE(Vault7)，FSB的Fronton等。安全从业人员还是要努力提高自己的姿势水平，不要对力量一无所知才行呀。

参考资料

对称加密与攻击案例分析

Sun, 02 Jun 2019 22:40:00 +0800

本文主要介绍常见的对称加密算法和它们的原理，然后分析一些实际存在的密码学攻击案例，包括流加密密钥重用漏洞、ECB块重排攻击以及CBC的Padding Oracle攻击等。

对称加密

当今我们所使用的加密算法，大致可以分为两类，即对称加密与非对称加密。其中非对称加密所能加密的内容长度一般受密钥长度的限制，且加密速度较慢，因此通常会与对称加密算法结合使用，即使用对称加密来对明文进行加密，再使用私钥对对称加密的密钥进行加密。本文主要关注对称加密。

对称加密在消息通信的两端共享相同密钥，加密算法一般分为两种类型：

流加密（Stream Ciphers）：逐字节加密数据
块加密（Block Ciphers）：逐块加密数据

其中块加密的块大小与具体加密算法的实现有关，常见的块大小有128、256位等。

流加密

流加密会逐字节加密数据，最常见的流加密算法就是SSL中用到的RC4算法了。其本质上是以密钥为种子（seed）产生的随机数来对明文进行逐字节异或。

0 xor 0 = 0
0 xor 1 = 1
1 xor 0 = 1
1 xor 1 = 0

流加密本质上依赖于随机数生成器的随机性，其随机性越强，加密强度就越大。

块加密

块加密也称为分组加密，也是大多数人比较熟悉的。AES、DES、3DES、Towfish等常见的加密算法都是块加密。在块加密中，原始数据会被分割成若干个大小为N的块，并分别对这些块进行加密。由于我们不能保证数据是N的倍数，因此需要对数据进行填充（Padding），这增加了实现的复杂度。一般来说，与流加密相反，块加密的解密流程和加密流程往往是不同的。

Padding

一种常见的填充方式是不论数据大小是否对齐块边界，都进行填充，而填充的内容为填充的字节数。比如块大小为8字节，那么可能有以下填充：

‘AAAAAAA’ + ‘\x01’
‘AAAAAA’ + ‘\x02\x02’
…
‘AA’ + ‘\x06’ * 6
‘A’ + ‘\x07’ * 7
‘\x08’ * 8

这就是PKCS#7中所定义的填充方式。

加密模式

块加密算法对数据进行逐块加密，有很多加密模式（mode）用于实现块的加密。这些加密模式大都可以归类为两种，即ECB模式和CBC模式。

ECB

ECB全称为Electronic CodeBook，是块加密中比较简单的加密模式。在ECB模式中，每一块明文数据都被独立地进行加密来生成加密块。这意味着如果你发现两个加密块有相同的内容，那么就可以确定这两个加密块的原文也是相同的。

这看起来好像没什么大不了的，但我们可以考虑这么一种情况，比如要加密的对象是一张图像，我们使用ECB加密算法，并且设置块大小为8字节（DES），加密后的图像如下：

虽然和原图有所区别，但也足以明显地看出原图的大致内容。

CBC

CBC全称为Cipher-Block Chaining，算是最常见的块加密模式了。在CBC模式中，每个明文块都会在加密前被使用前一个明文块的秘文进行异或；解密过程则正好相反。其中第一个明文块会被使用IV即初始化向量进行异或。

由于CBC模式中各个块会相互链接，在第一个加密块（Block0）中翻转某一位，则会在解密后导致对应的下一个明文块中（Block1）相同的位进行翻转。这项特性也导致了许多有趣的bug，后面会说到。

常见攻击

下面我们来介绍一下在现实中很常见的一些加密算法缺陷所导致的攻击场景。

流加密重用攻击

也常称为Stream Cipher Reuse Attack，指多次使用相同的流加密密钥可导致明文泄露。前面说过，流加密实际上是使用密钥生成随机序列，然后用该序列来对明文逐位异或加密。假设生成的随机序列为C(K)，加密函数为E()，那么对于明文A、B来说，则：

E(A) = A xor C
E(B) = B xor C

进行简单的数学运算：

E(A) xor E(B) = (A xor C) xor (B xor C) = A xor B xor C xor C = A xor B

这意味着如果攻击者可以拿到A、B的密文E(A)、E(B)，以及攻击者自己的明文B，就可以在无需知道密钥的情况下计算出A的明文：

A = E(A) xor E(B) xor B

眼见为实，我们使用RC4流加密为示例，首先使用openssl生成两个文件的密文（使用相同密钥）：

$ cat 1.txt
hello
$ cat 2.txt
world

$ openssl rc4 -nosalt -in 1.txt > 1.enc
$ openssl rc4 -nosalt -in 2.txt > 2.enc

接着，在已知1.enc、2.enc以及2.txt的情况下，还原1.txt的内容：

#!/usr/bin/env python3

def load(file):
    with open(file, 'rb') as f:
        data = f.read()
    print('loaded', len(data), 'bytes from', file)
    return data

def xor(lhs, rhs):
    return bytes(a ^ b for a, b in zip(lhs, rhs))

#  A = load('./1.txt')
A_enc = load('./1.enc')
B = load('./2.txt')
B_enc = load('./2.enc')

print('E(A) =', A_enc)
print('E(B) =', B_enc)
print('B =', B)
print('A =', xor(xor(B, B_enc), A_enc))

输出：

$ python3 stream.py
loaded 6 bytes from ./1.enc
loaded 6 bytes from ./2.txt
loaded 6 bytes from ./2.enc
E(A) = b'\xa1\xb1`\x1b\xa7\x97'
E(B) = b'\xbe\xbb~\x1b\xac\x97'
B = b'world\n'
A = b'hello\n'

在密钥未知的情况下，依然成功还原了1.txt的明文内容。防御这种攻击的方法就是尽可能不要重用流加密的密钥，常见的实现是在加密前将密钥与随机数nonce进行运算。

ECB块重排攻击

前文说过，在块加密中ECB模式中每个块都是独立加密的。因此攻击者可以在未知密钥的情况下，对密文中的块进行重新排列，组合成合法的可解密的新密文。

考虑这么一种场景，某CMS的cookie格式为DES-ECB加密后的数据，而明文格式如下：

admin=0;username=pan

由于DES使用的块大小是8字节，因此上述明文可以切分成三个块，其中@为填充符号：

admin=0;
username
=pan@@@@

假设我们可以控制自己的用户名（在注册时），那么有什么办法可以在不知道密钥的情况下将自己提取为管理员呢（即admin=1）？首先将用户名设置为pan@@@@admin=1;，此时明文块的内容如下：

admin=0;
username
=pan@@@@
admin=1;

我们所需要做的，就是在加密完成后，将服务器返回的cookie使用最后一个块替换第一个块，这样一来就获得了一个具有管理员权限的合法cookie了。

完整例子就不整了，这里只证明一下这种方式的可行性，首先使用DES-ECB加密明文：

$ cat admin.txt
admin=0;username=pan
$ openssl des-ecb -nosalt -in admin.txt > admin.enc
$ xxd admin.enc
00000000: 0293 07cd 88f3 026e c61e 1284 1a6e 6853  .......n.....nhS
00000010: e0b2 7169 3ee4 0b9a                      ..qi>...

然后修改密文，将前两个块（8字节）替换，然后使用相同的密钥进行解密：

$ xxd admin1.enc
00000000: c61e 1284 1a6e 6853 0293 07cd 88f3 026e  .....nhS.......n
00000010: e0b2 7169 3ee4 0b9a                      ..qi>...
$ openssl des-ecb -nosalt -d -in admin1.enc
usernameadmin=0;=pan

可以看到，该攻击方法确实是对ECB块加密算法有效的。

类似的利用方式还有在能够解密的情况下，将其他密文的对应块替换到自己的密文块中，从而获取其他密文块的明文数据。比如上述例子如果可以通过cookie获取用户名，那么可以将其他密文块放到用户名部分从而获取其他加密的信息。

该攻击和其他类似的攻击其实有一个共同点，我们无法获取和猜解原始数据，但可以通过修改密文数据并让服务器去成功解密。因此应对此攻击的方法就很明显了，即在加密后再添加MAC校验。

注意这里说的是先加密后MAC，如果顺序反了，那在处理数据时就要先解密再校验MAC，这有可能会导致一系列安全问题，比如下面将提到的密文填塞（Padding Oracle）攻击。

Padding Oracle Attack

在介绍该攻击之前，可以先回顾一下关于填充的知识。在PKCS#7系统中，我们可以通过最后一个块的最后一个字节得知填充的大小以及校验填充是否合法。

密文填塞（Padding Oracle Attack）攻击通常出现在CBC块加密模式以及PKCS#7填充的情况下。如果服务器在解密数据时对于填充合法的密文和填充不合法的密文有不同的返回，我们就能利用这种先验知识（Oracle）来填塞数据。

再回想一下我们介绍CBC块加密时说过，在一个加密块（Block N）中翻转某一位，则会在解密后导致对应的下一个明文块（Block N+1）中相同的位进行翻转。由于这个特性，我们可以在不知道密钥的情况下，使用服务器来猜解出明文数据。

最后一字节

具体怎么做呢？再次仔细思考一下CBC模式的解密流程，若要解密一个块，则需要其本身的密文C2以及前一个块的密文C1，解密的流程如下：

在这种攻击场景下，我们（攻击者）可以控制输入密文块的内容，并且获取服务器的差异化返回，即是否填充错误。假设C2是最后一个块，那么通过变异C1，就可以猜解C2明文。猜解过程如下：

将C1前15字节随机设置，第16字节设置为’\x00’
将修改后的密文块发送给服务器解密

由于我们修改了C1的最后一个字节，那么根据上文介绍，在解密后C2的明文P2最后一个字节也会进行改变，变成什么我们还不知道，但是我们知道：

P2[15] = I2[15] xor C1[15]

其中I2是解密算法如AES解密后的中间值，我们不关心具体解密算法，但总有这么个值。然后，根据服务器的返回我们知道有两种可能：

返回填充不合法。此时P2[15]未知。
返回填充合法。此时P2[15]肯定为0x01，因为只有这样才能出现合法的填充。

如果是第一种情况，我们就继续变异C1[15]，直到出现合法的填充，即第二种情况。假设我们在变异到C1[15] = 0x26时才出现合法填充，则此时有：

P2[15] = I2[15] xor C1[15]
I2[15] = P2[15] xor C1[15] = 0x01 xor 0x26 = 0x27

回顾一下上图，I2的产生与C1无关，只与C2和密钥key相关，但是我们却计算出了I2[15]的值！因此我们可以用I2[15]异或上变异前的C1[15]从而获得原始的明文。

P2[15] = 0x27 xor C1[15]

这就是Padding Oracle攻击的思路。

下一个字节

为了完成攻击，我们继续使用类似方式猜解I2中更多的内容。

将C1前14字节设置为随机值
C1[14]设置为0x00
C1[15]设置为能令P2[15] = 0x02的值

P2[15] = I2[15] xor C1[15]
C1[15] = P2[15] xor I2[15] = 0x02 xor 0x27 = 0x25

即将C1[15]固定为0x25，继续爆破C1[14]知道出现合法的填充，此时P2[14]=0x02，假设出现合法填充时候爆破的C1[14]值为0x68：

P2[14] = I2[14] xor C1[14] = 0x02
I2[14] = P2[14] xor C1[14] = 0x02 xor 0x68 = 0x6A

再一次，我们获得了真实的I2[14]值，从何可以算出原始的明文P2[14]。以此类推，最终我们可以计算出完整的明文P2内容。

下一个块

根据上述方法，我们已经可以还原最后一个密文块的明文了。而对于CBC模式，每个密文块的解密仅和当前块以及前一个块相关，因此上述攻击可以应用到所有块中，除了第一个。

第一个块的加解密使用初始化向量IV进行，对此没有通用破解方法。但是CBC加密中IV也不是必须保密的，因此在实践中通常会组合到密文的最前面或者最后面，其长度和块大小相同。如果一定要解密第一个块，可以使用这种猜测方法。

示例

实践出真知，我们来看一个具体的例子。首先用Flask写一个简单的应用，如下：

#!/usr/bin/env python3
import binascii
import string
import random

from Crypto.Cipher import AES
from Crypto.Util.Padding import pad, unpad
from flask import Flask, request

app = Flask(__name__)
db = {}
BSIZE = 16
secret = b'\x26' * BSIZE

def get_iv():
    return b'\x00' * BSIZE

def decrypt(data):
    data = data.encode()
    data = binascii.unhexlify(data)
    iv = data[:BSIZE]
    engine = AES.new(key=secret, mode=AES.MODE_CBC, iv=iv)
    data = data[BSIZE:]
    data = engine.decrypt(data)
    data = unpad(data, BSIZE)
    return data.decode()

def encrypt(data):
    data = data.encode()
    iv = get_iv()
    engine = AES.new(key=secret, mode=AES.MODE_CBC, iv=iv)
    return binascii.hexlify(iv + engine.encrypt(pad(data, BSIZE))).decode()

@app.route('/dec/')
def dec(data):
    # print('dec:', data)
    try:
        key = decrypt(data)
    except Exception as e:
        return 'Error: ' + str(e)
    if key not in db:
        return 'Error: invalid key'
    return db[key]

@app.route('/enc/')
def enc(key):
    db[key] = 'valid'
    return encrypt(key)

app.run(debug=False)

该应用可以接收一个明文返回其密文（enc），也可以接收密文返回对应信息。

$ curl http://localhost:5000/enc/See_you_in_Red_Square_at_4_pm
00000000000000000000000000000000c8ab1c881b40d54d81d1efab429ad239dac1d6573e7c26d533ffc3cbc23a8455

$ curl http://localhost:5000/dec/00000000000000000000000000000000c8ab1c881b40d54d81d1efab429ad239dac1d6573e7c26d533ffc3cbc23a8455
valid

$ curl http://localhost:5000/dec/00000000000000000000000000000000c8ab1c881b40d54d81d1efab429ad239dac1d6573e7c26d533ffc3cbc23a8466
Error: Padding is incorrect.

作为攻击者，我们拿到的只有加密后的信息，目的就是要将其解密，查看明文内容：

00000000000000000000000000000000c8ab1c881b40d54d81d1efab429ad239dac1d6573e7c26d533ffc3cbc23a8455

方便起见，我们假设已知服务器使用的是AES-128-CBC加密算法，且IV组合在密文头部。其实不知道也没关系，只不过需要多试几次罢了。根据前面介绍的原理，我们先将密文分割成128/8=16字节的3个块：

block[0] = '00000000000000000000000000000000'
block[1] = 'c8ab1c881b40d54d81d1efab429ad239'
block[2] = 'dac1d6573e7c26d533ffc3cbc23a8455'

经测试，当服务器遇到填充错误会返回Error: Padding is incorrect.或者Error: PKCS#7 padding is incorrect.，那么这就可以作为我们Padding Oracle攻击的依据。

首先将block[1]最后一字节从0x00开始到0xff不断变异尝试，发现当值为0x3b时候出现了非Padding错误，此时：

I2[15] = _C1[15] ^ _P2[15] = 0x3b ^ 0x01 = 0x3a

则明文最后一字节为：

P2[15] = I2[15] xor C1[15] = 0x3a ^ 0x39 = 0x03

依此类推，不断从后往前猜解每个字节的值。一个简单的自动化脚本如下：

#!/usr/bin/env python3
import time
import requests
import binascii

url = 'http://localhost:5000/dec/' 
data = '00000000000000000000000000000000c8ab1c881b40d54d81d1efab429ad239dac1d6573e7c26d533ffc3cbc23a8455'
BSIZE = 16

def test(data):
    r = requests.get(url + data)
    return r.text

b = binascii.unhexlify(data)
nblocks = int(len(b) / BSIZE)
blocks = []
print('nblocks:', nblocks)
for i in range(nblocks):
    blk = b[i*BSIZE: (i+1)*BSIZE]
    print(f'block[{i}] =', binascii.hexlify(blk))
    blocks.append(blk)
print('iv:', b[:BSIZE])

blockID = -1
prevID = blockID - 1

print(f'decrypting block[{blockID}], prev =', binascii.hexlify(blocks[prevID]))

plaintext = bytearray(16)
inter = bytearray(16)
for byteIdx in range(BSIZE-1, -1, -1):
    prevBlock = bytearray(blocks[prevID])
    print(f'mutating block[{prevID}][{byteIdx}]')
    origin = prevBlock[byteIdx]
    padValue = BSIZE - byteIdx
    # 将byteIdx之前的值可以任意随机设置
    for i in range(byteIdx):
        prevBlock[i] = 0x11
    # 将byteIdx之后的值设置为令其明文为padValue的值
    for i in range(byteIdx + 1, BSIZE):
        prevBlock[i] = inter[i] ^ padValue
    print('begin:', prevBlock.hex())
    found = False
    for val in range(0x100):
        prevBlock[byteIdx] = val
        _blocks = blocks.copy()
        _blocks[prevID] = bytes(prevBlock)
        payload = b''.join(_blocks)
        payload = binascii.hexlify(payload).decode()
        resp = test(payload)
        # print(f'testing', binascii.hexlify(prevBlock), '->', resp, end='\r')
        if 'incorrect' in resp:
            continue
        i2 = padValue ^ val
        p2 = origin ^ i2
        inter[byteIdx] = i2
        plaintext[byteIdx] = p2
        print(f'found c={val}, i={padValue}^{val}={i2}, o={origin}, p={p2}')
        found = True
        break
    if not found:
        print('Error: no valid value found')
        break
print('plaintext =', plaintext)

运算结果为：

$ python3 padding_oracle_exp.py
nblocks: 3
block[0] = b'00000000000000000000000000000000'
block[1] = b'c8ab1c881b40d54d81d1efab429ad239'
block[2] = b'dac1d6573e7c26d533ffc3cbc23a8455'
iv: b'\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00'
decrypting block[-1], prev = b'c8ab1c881b40d54d81d1efab429ad239'
mutating block[-2][15]
begin: 11111111111111111111111111111139
found c=59, i=1^59=58, o=57, p=3
mutating block[-2][14]
begin: 1111111111111111111111111111d238
found c=211, i=2^211=209, o=210, p=3
mutating block[-2][13]
begin: 111111111111111111111111119ad239
found c=154, i=3^154=153, o=154, p=3
mutating block[-2][12]
begin: 111111111111111111111111429dd53e
found c=43, i=4^43=47, o=66, p=109
mutating block[-2][11]
begin: 1111111111111111111111ab2a9cd43f
found c=222, i=5^222=219, o=171, p=112
mutating block[-2][10]
begin: 11111111111111111111efdd299fd73c
found c=182, i=6^182=176, o=239, p=95
mutating block[-2][9]
begin: 111111111111111111d1b7dc289ed63d
found c=226, i=7^226=229, o=209, p=52
mutating block[-2][8]
begin: 111111111111111181edb8d32791d932
found c=214, i=8^214=222, o=129, p=95
mutating block[-2][7]
begin: 111111111111114dd7ecb9d22690d833
found c=48, i=9^48=57, o=77, p=116
mutating block[-2][6]
begin: 111111111111d533d4efbad12593db30
found c=190, i=10^190=180, o=213, p=97
mutating block[-2][5]
begin: 111111111140bf32d5eebbd02492da31
found c=20, i=11^20=31, o=64, p=95
mutating block[-2][4]
begin: 111111111b13b835d2e9bcd72395dd36
found c=114, i=12^114=126, o=27, p=101
mutating block[-2][3]
begin: 111111887312b934d3e8bdd62294dc37
found c=247, i=13^247=250, o=136, p=114
mutating block[-2][2]
begin: 11111cf47011ba37d0ebbed52197df34
found c=115, i=14^115=125, o=28, p=97
mutating block[-2][1]
begin: 11ab72f57110bb36d1eabfd42096de35
found c=209, i=15^209=222, o=171, p=117
mutating block[-2][0]
begin: c8ce6dea6e0fa429cef5a0cb3f89c12a
found c=169, i=16^169=185, o=200, p=113
plaintext = bytearray(b'quare_at_4_pm\x03\x03\x03')

这样，我们就在无需知道服务端密钥的情况下，成功还原了最后一个块的明文。逐块处理，就可以还原完整的内容了。当然还有值得优化的地方，比如爆破出最后一字节明文后，可以根据Padding原理直接跳过若干字节，加快爆破的速度，以及使用IV还原第一个块等。

小结

本文介绍了生活中常见的对称加密算法，包括流加密和块加密。其中流加密为逐字节加密，类如RC4等算法容易受到密钥重用攻击的影响，导致攻击者在无需知道密钥的情况下还原密文；而块加密将数据分割为一个个块再分别进行加密，ECB中各个块独立加密，容易收到重排攻击的影响，CBC中每个块加密后会与前一个块密文进行异或，在填充规律已知的情况下，容易收到Padding Oracle攻击的影响。缓解密钥重用的方式一般是增加随机数nonce，而绕过密钥获取/修改明文的攻击则可以通过对加密数据添加完整性保护（MAC）。加密算法本身没有漏洞，但是使用不当也能导致严重的安全问题，关键是需要理解所使用的加密算法基本原理。