每次規模比較大的漏洞，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功能繼承了這個特性，勇猛的暴露了它的弱點。我覺得功能很好啊，但它為什么要存在于日志框架呢?

這可能是因為卷吧。畢竟一個日志框架，也是要有元宇宙的夢想的!