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

JDBC（Java DataBase Connectivity）是一种用于执行Sql语句的Java Api，即Java数据库连接，是Java语言中用来规范客户端程序如何来访问数据库的应用程序接口，可以为多种关系数据库提供统一访问，提供了诸如查询和更新数据库中数据的方法，是Java访问数据库的标准规范。简单理解为链接数据库、对数据库操作都需要通过jdbc来实现。

挺早之前有个Apache DolphinScheduler 任意文件读取漏洞，之前有看过这个，后面又有好兄弟问我，就研究了一下。本来简单的diff了一下，以为发现了问题，但是事情没有我想的那么简单~

最近@phithon在知识星球中分享了一个多重编码的webshell姿势后，出于对代码实现的好奇简单看了看tomcat的具体实现以及尝试是否能够更深入的目的也便有了本篇

接着前面的分析，这里主要是两个由JtaTransactionManager类的readObject方法调用过程中而造成的JNDI注入，其中第一个(CVE-2018-3191)是使用T3进行发送序列化数据，而第二个(CVE-2020-2551)这个经典的漏洞是通过IIOP来进行序列化数据的传递的

抽空在H1上看到了一个和JDBC Attack有关的案例，于是就简单看了下。

SPI（Service Provider Interface），是JDK内置的一种服务提供发现机制，可以用来启用框架扩展和替换组件，主要是被框架的开发人员使用，比如java.sql.Driver接口，其他不同厂商可以针对同一接口做出不同的实现，MySQL和PostgreSQL都有不同的实现提供给用户，而Java的SPI机制可以为某个接口寻找服务实现。

继续抽空学习Weblogic CVE中有关T3协议的漏洞利用方式！

这篇是继上篇中的T3协议进行漏洞利用，继续分析Weblogic CVE的有关利用方式和修复手法

代理模式是常用的 java 设计模式，他的特征是代理类与委托类有同样的接口，代理类主要负责为委托类预处理消息、过滤消息、把消息转发给委托类，以及事后处理消息等。代理类与委托类之间通常会存在关联关系，一个代理类的对象与一个委托类的对象关联，代理类的对象本身并不真正实现服务，而是通过调用委托类的对象的相关方法，来提供特定的服务。