- 漏洞原理
- 原始碼分析與復現
- 影響版本
漏洞原理
核心點就是shiro和spring對uri進行配合匹配的時候有缺陷導致的，shiro中很輕易就能繞過，其次spring中對;分號好像情有獨鍾，被大牛們發現後也就一下子繞過了。
主流payload：/xxx/..;/admin/
具體後臺路由不一定是admin，得看情況而定，但是下面的分析都由admin為後臺路由進行分析。
原始碼分析與復現
環境說明：後臺路由為admin
下面我用vulhub開啟對應的靶場
接著訪問uri：/xxx/..;/admin/
xxx是隨便填，而最重要的認證繞過的是..;能夠讓你走到admin後臺，復現成功了。
在該漏洞中，認證過程需要走兩個框架，一個是shiro另一個是spring，uri第一個進入的是shiro接著判斷完了才交給spring，這個交給spring的時候也出了問題，下面開始講解過程。
1.shiro中可能會有這樣的過濾器對uri進行匹配，分支判斷是否需要認證
這裡是配置map.put會出現問題，所以是否出現認證繞過還得看匹配的規則寫的如何，這不重要，我們約定配置為：/admin/** 然後該規則下需要authc，表示需要進行身份認證，這看起來很正常，admin路由確實要求身份認證。
2.接著我們下面開始分析當請求http://xxx.xxxx.com/xxx/..;/admin在後臺是如何走的：
首先經過shiro處理，直接看最重要的部分，shiro對;分號的處理。
作用：直接匹配59，即;的ascii碼值，發現有分號就返回分號前的欄位，否則返回整個uri。
那麼這裡就拿到uri：xxx/..
3.接下去的函式都是規範化，比如//處理成/這些就不說了，直接看最後給到攔截器判斷的requestURI值為/xx/..，pathMatches就會根據攔截器判斷是否為/admin/**，那麼很顯然不是，現在就相當於你bypass掉了shiro的認證。
4.shiro認證完了就到spring對uri進行認證了
如何拿到uri的這部分就跳過了，交到spring的uri是完整的，即/xxx/..;/admin/， 所以說這就是交給spring的時候沒有同步好uri的處理結果，那麼在spring中主要分析他怎麼處理;的即可
最主要跟進removeSemicolonContentInternal(requestUri)方法，他的作用就是：移除uri中/與/之間的;分號以及;分號後面的內容
根據這句話可以得知最後的uri應該是：/xxx/../admin/ == /admin/。
../ 為回到上一層目錄，就到admin了，認證繞過結束，收工。
影響版本
Shiro < 1.5.3
SpringBoot 的版本 < 2.3
參考文章：
https://www.freebuf.com/articles/web/362350.html
https://blog.spoock.com/2020/05/09/cve-2020-1957/
https://cn-sec.com/archives/1312489.html