<script type="text/javascript"> 
     function checkUploadFile() { 
     var file = document.getElementById("file").value; 
         if (file == null || file==""){ 
                 alert("未选定文件") 
         return false; 
 } 
     var allow_ext = ".jpg|.png|.gif|.jpeg"; 
     var ext_name = file.substring(file.lastIndexOf(".")); 
         if (allow_ext.indexOf(ext_name)==-1){ 
             var errMsg = "该类型文件不允许上传"; 
             alert(errMsg); 
                     return false; 
         } 
     } 
</script>

后端过滤不严格的实际场景有很多，如后缀名过滤不严格、上传类型过滤不严格等。针对这两种原因，我们分别用示例代码来进行说明。

public boolean checkMimeType(String filename){ 
     String type = null;
     Path path = Paths.get(filename); 
     File file = new File(path); 
     URLConnection connection = file.toURL().openConnection(); 
         String mimeType = connection.getContentType(); 
             If(assertEquals(mimeType, "image/png")) 
                 return true; 
     else{ 
         return false; 
    } 
} 
... 
 public String uploadFile(HttpServletRequest request) throws IOException { 
         MultipartHttpServletRequest multipartRequest = (MultipartHttpServletRequest)request; 
     Map<String, MultipartFile> fileMap = multipartRequest.getFileMap(); 
         if(fileMap == null || fileMap.size() == 0){ 
             System.out.println("please choose your files！"); 
                 return "error"; 
     } 
     String root = request.getServletContext().getRealPath("/upload"); 
             File savePathFile = new File(root); 
             if(!savePathFile.exists()){ 
                     savePathFile.mkdirs(); 
     } 
         String fileName = null; 
         String suffixName = null; 
         MultipartFile mf = null; 
         InputStream fileIn = null; 
         List<InputStream> isList = new ArrayList<InputStream>(); 
             for (Map.Entry<String, MultipartFile> entity : fileMap.entrySet()) 
    { 
             mf = entity.getValue(); 
             fileName = mf.getOriginalFilename(); 
         if(checkMimeType(fileName)){ 
             suffixName = fileName.substring(fileName.lastIndexOf("."), 
    fileName.length()); 
         try { 
                 fileIn = mf.getInputStream(); 
                     isList.add(mf.getInputStream()); 
                     LocalFileUtils.upload(fileIn, root, fileName); 
         } catch (IOException e) { 
         e.printStackTrace(); 
     }finally { 
     if(fileIn != null){ 
         fileIn.close();

         } 
         } 
     }else{ 
         return "error"; 
         } 
     } 
 return "index"; 
}

仔细阅读代码会发现，该上传代码片段针对上传文件的检测只有一个环节，即通过 checkMimeType() 函数来判断用户上传文件的 MimeType 的类型是否为image/png 类型，若是，则上传成功；若不是，则会上传失败。这里开发者的思路是没有问题的，但出现的问题和由前端过滤导致的任意文件上传有异曲同工之妙，在 checkMimeType() 函数中使用的是 getContentType() 方法来获取文件的 MimeType ，攻击者可以通过这种方式在前端修改文件类型，从而绕过上传。如 JSP 类型文件的MimeType 是 text/html ，我们可以通过抓包改包的方式将其修改为 image/png 类型。

public String uploadFile(HttpServletRequest request) throws IOException { 
     MultipartHttpServletRequest multipartRequest = (MultipartHttpServletRequest) request; 
     Map<String, MultipartFile> fileMap = multipartRequest.getFileMap(); 
         if(fileMap == null || fileMap.size() == 0){ 
             System.out.println("please choose your files！"); 
         return "error"; 
     } 
         String root = request.getServletContext().getRealPath("/upload"); 
         File savePathFile = new File(root); 
             if(!savePathFile.exists()){ 
                     savePathFile.mkdirs(); 
         } 
             String fileName = null; 
             String suffixName = null; 
             MultipartFile mf = null; 
             InputStream fileIn = null; 
                 List<InputStream> isList = new ArrayList<InputStream>(); 
                         for (Map.Entry<String, MultipartFile> entity : fileMap.entrySet()) 
{ 
         mf = entity.getValue(); 
         fileName = mf.getOriginalFilename(); 
         suffixName = fileName.substring(fileName.indexOf("."), fileName. 
length());
         if(suffixName.equals("jsp")){ 
             return "error"; 
         }else{ 
             try { 
                 fileIn = mf.getInputStream(); 
                 isList.add(mf.getInputStream()); 
                 LocalFileUtils.upload(fileIn, root, fileName); 
             } catch (IOException e) { 
         e.printStackTrace(); 
         }finally { 
         if(fileIn != null){ 
     fileIn.close(); 
             } 
         } 
     } 
 } 
 return "index"; 
}

（三） 文件下载/读取漏洞

        与任意文件上传漏洞对应的是任意文件下载/ 读取漏洞。在文件上传中我们通常用到的是 FileOutputStream ，而在文件下载中，我们用到的通常是 FileInputStream 。引发任意文件下载/ 读取漏洞的原因通常是对传入的路径未做严格的校验，导致攻击者可以自定义路径，从而达到任意文件下载/ 读取的效果，如下代码是一个任意文件下载漏洞的示例：

protected void doPost(HttpServletRequest request,HttpServletResponse response) throws ServletException,IOException {
         String rootPath = this.getServletContext().getRealPath("/"); 
         String filename = request.getParameter("filename"); 
         filename = filename.trim(); 
         InputStream inStream = null; 
             byte[] b = new byte[1024]; 
             int len = 0; 
     try { 
         if (filename != null) { 
             inStream = new FileInputStream(rootPath + "/Public/download/" + 
    filename); 
             response.reset(); 
             response.setContentType("application/x-msdownload"); 
         response.addHeader("Content-Disposition", "attachment; filename=\
"" + filename + "\""); 
     while ((len = inStream.read(b)) > 0) { 
             response.getOutputStream().write(b, 0, len); 
     } 
             response.getOutputStream().close(); 
         inStream.close(); 
     }else{ 
     return ; 
 } 
             } catch (Exception e) { 
         e.printStackTrace(); 
 } 
}

        ZrLog 是使用 Java 开发的博客程序。在 ZrLog 2.1.0 产品后台存在文件写入漏洞，攻击者可以利用产品后台的“设置/ 错误页面编辑”功能进行文件写入。通过利用可进行存储型 XSS 漏洞攻击，或替换 ZrLog 网站的配置文件 web.xml ，致使网站崩溃；该漏洞出现的文件路径为：\zrlog\web\src\main\java\com\zrlog\web\controller\ admin\api\TemplateController.java，具体位置如图 4 -1 所示

这段代码是网站管理员在网站后台的“设置 / 错误页面编辑 / 提交”处进行错误页面自定义的部分代码。可以发现 file 字符串由 PathKit.getWebRootPath() 和 getPara(name:"file")两个字符串拼接而成。其中 PathKit.getWebRootPath() 的返回值是网站根目录的路径执行getPara("file") 方法，如图 4 -2 所示

可以发现该方法的返回值是 this.request.getParameter(name) ，而 this.request 是

javax.servlet.http.HttpServletRequest 对象，如图 4 -3 所示。

由此可见，这套 CMS 在进行“错误页面编辑”时，未经过任何过滤就进行了文件路径和文件名的拼接。

1. 攻击者登录 ZrLog 的管理后台。
2. 攻击者使用 Burp Suite 抓取“错误页面编辑”的数据包。
3. 攻击者使用 Burp Suite 修改“错误页面编辑”的数据包。
4. 攻击者发送数据包。

• 攻击者登录 ZrLog 的管理后台。
• 攻击者使用 Burp Suite 抓取“错误页面编辑”的数据包，如图 4-4 所示

        由图 4-4 可以发现，攻击者可以在发送 payload 前更改文件名和文件内容。

• 攻击者使用 Burp Suite 修改“错误页面编辑”的数据包，如进行包含恶意JavaScript 脚本的 HTML 文件写入

file=%2Ferror%2Fsafedog.html&content=<script>alert(document.cookie)</script>

在浏览器中访问 http://192.168.114.238:8080/zrlog/error/safedog.html ，查看攻击效果，如图 4-6 所示

由图 4 -6 可以发现，攻击者可以通过修改文件名和文件内容，进行存储型 XSS攻击。最后我们只需要修改 payload 的路径信息，就可以达到使网站崩溃的效果，如以下 payload ：

file=/WEB-INF/web.xml&content=

        可以发现，web.xml 的内容被置空。

再访问 http://192.168.114.238:8080/zrlog/ ，可以看到已经瘫痪的站点，如图 4 -8 所示

        对于此类型漏洞的防护以及文件下载/ 读取与任意文件上传类似。首先，就是要保证接收的路径不被用户控制，而且要对写入的内容进行校验；其次，文件写入漏洞一般利用的是源程序本身 自带 的功能，因此审计者对于此类型的漏洞进行审计时，要格外关注源程序是否具有写入文件的站点功能。此外 HTTP 请求中的 PUT 方法也可以创建并写入文件，例如比较经典的 ActiveMQ 任意文件写入漏洞（CVE-2016-3088）就是利用 PUT 方法写入文件；又例如 Apache Tomcat 7.0.0 –7.0.81 版本中，如果开启了 PUT 功能，会导致 Apache Tomcat 任意文件上传漏洞（CVE-2017-12615），攻击者可以利用该漏洞创建并写入文件

（五）．文件解压漏洞

        文件解压是 Java 中一个比较常见的功能，但是该功能的安全问题往往也容易被忽视。由文件解压导致的漏洞五花八门，利用的效果也各有不同，如路径遍历、文件覆盖、拒绝服务、文件写入等。

import zipfile 
if __name__ == "__main__": 
 try: 
     #binary = b'ddddsss' 
     binary = b'<script>alert("helloworld")</script>' 
     zipFile = zipfile.ZipFile("test5.zip", "a", zipfile.ZIP_DEFLATED) 
     info = zipfile.ZipInfo("test5.zip") 
     zipFile.writestr("../../../safedog.html", binary) 
         zipFile.close() 
     except IOError as e: 
     raise e

注意，使用好压打开 test5.zip ，可以发现 safedog.html 所处的路径是 “test5.zip\..\..\.. ”，如图 5 -3  所示