每次规模比较大的漏洞，JNDI好像都不会缺席。最近人尽皆知的Log4j2漏洞也和它有关，让人不由得怀疑，是不是作者开的后门。
因为JNDI这个玩意，别说用过，很多人连听都没听说过。这么冷门酸爽的东西，有什么理由把它放在一个日志框架里呢?恐怕只有作者想得通。
数据库驱动
很多人接触JNDI，是从数据库的驱动开始的。当然，随着SpringBoot单体发布模式的流行，现在用这种方式来获取数据库配置的古董公司，是越来越少了。
比如，我们可以在tomcat的server.xml里，配置一个叫做xjjdogDB的资源。
- <Resource name="jdbc/xjjdogDB" auth="Container" type="javax.sql.DataSource"
- maxTotal="100" maxIdle="30" maxWaitMillis="10000"
- username="xjjdog" password="123456" driverClassName="com.mysql.jdbc.Driver"
- url="jdbc:mysql://localhost:3306/xjjdog_db"/>
那么，我们只需要在SpringBoot中配置上JNDI这个名字，它就能加载正确的配置。前提是我们需要把SpringBoot服务打包成WAR包发布。像JBoss这样的宣称企业级服务器的软件，就喜欢这么干。
- spring:
- datasource:
- jndi-name: jdbc/xjjdogDB
从这里，我们可以看出。JNDI到底是个神马玩意呢?你可以认为它是一个配置中心，也可以认为它是一个命名服务。其根本功能，就是让你可以通过一个简短的字符串，就能获取一系列的复杂配置和初始化后的功能。
这样，我们就可以避免将这些配置直接写在项目里。程序启动起来，到底加载的什么东西，要看运行的环境配置的什么东西。
具体实现的话，不就是一个可以根据key获取value的HashMap嘛。
危险由此而来
关键是这个value，它不是String，它是一个Object。要从字符串变身为一个正常的类，还要做到通用，那就不得不依靠反射。
这张图是Oracle官方的一张关于JNDI的介绍。上面的都不是关键，关键的地方在于，JNDI通过SPI机制，可以和LDAP、RMI等各种技术，产生联动。
任何为了追求方便而不遵守常规的便捷通道，都会产生问题。SPI是为数不多的打破Java类加载机制的技术，和Unsafe类一样，强大但并不那么推荐使用。
如上图，就是NamingManager类里面的方法getObjectFactoryFromReference。当它从本地加载相应类的时候，如果加载不到，它干了一件不该干但又不得不干的事情，那就是从网络上的代码里面构造相应的对象!
这下，在炫肌肉的同时，可完犊子了。如上图，我们只需要在8000端口启动一个nginx。或者直接使用python启动一个小小的web服务器。
- python -m http.server 8000
能够发起外网请求的服务器，将会乖乖的自动从我们指定的服务器上捞下非法的class文件进行加载。
制作这些攻击性的playload也非常容易，有marshalsec这样的工具，可以很方便的生成。
根据java的类加载机制，在static代码块里面，就可以干一些实际的代码执行逻辑。我们只需要把编译后的a.class放在该放的地方，JNDI这玩意就能够加载它。
- public class a {
- static {
- try {
- String[] cmd = {"calc.exe"};
- java.lang.Runtime.getRuntime().exec(cmd).waitFor();
- } catch ( Exception e ) {
- e.printStackTrace();
- }
- }
- }
上面的代码将会在你部署的服务器上启动一个calc计算器。当然，它还可以干更多事情。
END
从上面可以看出，Java的反射很强大，但是也很危险。SPI功能继承了这个特性，勇猛的暴露了它的弱点。我觉得功能很好啊，但它为什么要存在于日志框架呢?
这可能是因为卷吧。毕竟一个日志框架，也是要有元宇宙的梦想的!
