小編給大家分享一下Nexus Repository Manager 3幾次表達(dá)式解析漏洞的示例分析，相信大部分人都還不怎么了解，因此分享這篇文章給大家參考一下，希望大家閱讀完這篇文章后大有收獲，下面讓我們一起去了解一下吧！
公司專(zhuān)注于為企業(yè)提供成都網(wǎng)站設(shè)計(jì)、網(wǎng)站建設(shè)、外貿(mào)網(wǎng)站建設(shè)、微信公眾號(hào)開(kāi)發(fā)、電子商務(wù)商城網(wǎng)站建設(shè)，微信小程序定制開(kāi)發(fā)，軟件按需搭建網(wǎng)站等一站式互聯(lián)網(wǎng)企業(yè)服務(wù)。憑借多年豐富的經(jīng)驗(yàn)，我們會(huì)仔細(xì)了解各客戶的需求而做出多方面的分析、設(shè)計(jì)、整合，為客戶設(shè)計(jì)出具風(fēng)格及創(chuàng)意性的商業(yè)解決方案，成都創(chuàng)新互聯(lián)更提供一系列網(wǎng)站制作和網(wǎng)站推廣的服務(wù)。
Nexus Repository Manager 3最近曝出兩個(gè)el表達(dá)式解析漏洞，編號(hào)為CVE-2020-10199，CVE-2020-10204，都是由Github Secutiry Lab團(tuán)隊(duì)的@pwntester發(fā)現(xiàn)。由于之前Nexus3的漏洞沒(méi)有去跟蹤，所以當(dāng)時(shí)diff得很頭疼，并且Nexus3 bug與安全修復(fù)都是混在一起，更不容易猜到哪個(gè)可能是漏洞位置了。后面與@r00t4dm師傅一起復(fù)現(xiàn)出了CVE-2020-10204，CVE-2020-10204是CVE-2018-16621的繞過(guò)，之后又有師傅弄出了CVE-2020-10199，這三個(gè)漏洞的根源是一樣的，其實(shí)并不止這三處，官方可能已經(jīng)修復(fù)了好幾處這樣的漏洞，由于歷史不太好追溯回去，所以加了可能，通過(guò)后面的分析，就能看到了。還有之前的CVE-2019-7238，這是一個(gè)jexl表達(dá)式解析，一并在這里分析下，以及對(duì)它的修復(fù)問(wèn)題，之前看到有的分析文章說(shuō)這個(gè)漏洞是加了個(gè)權(quán)限來(lái)修復(fù)，可能那時(shí)是真的只加了個(gè)權(quán)限吧，不過(guò)我測(cè)試用的較新的版本，加了權(quán)限貌似也沒(méi)用，在Nexus3高版本已經(jīng)使用了jexl白名單的沙箱。
文中會(huì)用到三個(gè)Nexus3環(huán)境：
nexus-3.14.0-04
nexus-3.21.1-01
nexus-3.21.2-03
nexus-3.14.0-04用于測(cè)試jexl表達(dá)式解析，nexus-3.21.1-01用于測(cè)試jexl表達(dá)式解析與el表達(dá)式解析以及diff，nexus-3.21.2-03用于測(cè)試el表達(dá)式解析以及diff
CVE-2020-10199、CVE-2020-10204漏洞的修復(fù)界限是3.21.1與3.21.2，但是github開(kāi)源的代碼分支好像不對(duì)應(yīng)，所以只得去下載壓縮包來(lái)對(duì)比了。在官方下載了nexus-3.21.1-01與nexus-3.21.2-03，但是beyond對(duì)比需要目錄名一樣，文件名一樣，而不同版本的代碼有的文件與文件名都不一樣。我是先分別反編譯了對(duì)應(yīng)目錄下的所有jar包，然后用腳本將nexus-3.21.1-01中所有的文件與文件名中含有3.21.1-01的替換為了3.21.2-03，同時(shí)刪除了META文件夾，這個(gè)文件夾對(duì)漏洞diff沒(méi)什么用并且影響diff分析，所以都刪除了，下面是處理后的效果：
如果沒(méi)有調(diào)試和熟悉之前的Nexus3漏洞，直接去看diff可能會(huì)看得很頭疼，沒(méi)有目標(biāo)的diff。
抓下nexus3發(fā)的包，隨意的點(diǎn)點(diǎn)點(diǎn)，可以看到大多數(shù)請(qǐng)求都是POST類(lèi)型的，URI都是/service/extdirect：
post內(nèi)容如下：
重慶分公司
重慶分公司
{"action":"coreui_Repository","method":"getBrowseableFormats","data":null,"type":"rpc","tid":7}可以看下其他請(qǐng)求，json中都有action與method這兩個(gè)key，在代碼中搜索下coreui_Repository這個(gè)關(guān)鍵字：
可以看到這樣的地方，展開(kāi)看下代碼：
通過(guò)注解方式注入了action，上面post的method->getBrowseableFormats也在中，通過(guò)注解注入了對(duì)應(yīng)的method：
所以之后這樣的請(qǐng)求，我們就很好定位路由與對(duì)應(yīng)的處理類(lèi)了
Nexus3的API也出現(xiàn)了漏洞，來(lái)看下怎么定位API的路由，在后臺(tái)能看到Nexus3提供的所有API。
點(diǎn)幾個(gè)看下包，有GET、POST、DELETE、PUT等類(lèi)型的請(qǐng)求：
沒(méi)有了之前的action與method，這里用URI來(lái)定位，直接搜索/service/rest/beta/security/content-selectors定位不到，所以縮短關(guān)鍵字，用/beta/security/content-selectors來(lái)定位：
通過(guò)@Path注解來(lái)注入U(xiǎn)RI，對(duì)應(yīng)的處理方式也使用了對(duì)應(yīng)的@GET、@POST來(lái)注解
可能還有其他類(lèi)型的路由，不過(guò)也可以使用上面類(lèi)似的方式進(jìn)行搜索來(lái)定位。還有Nexus的權(quán)限問(wèn)題，可以看到上面有的請(qǐng)求通過(guò)@RequiresPermissions來(lái)設(shè)置了權(quán)限，不過(guò)還是以實(shí)際的測(cè)試權(quán)限為準(zhǔn)，有的在到達(dá)之前也進(jìn)行了權(quán)限校驗(yàn)，有的操作雖然在web頁(yè)面的admin頁(yè)面，不過(guò)本不需要admin權(quán)限，可能無(wú)權(quán)限或者只需要普通權(quán)限。
在跟蹤調(diào)試了CVE-2018-16621與CVE-2020-10204之后，感覺(jué)buildConstraintViolationWithTemplate這個(gè)keyword可以作為這個(gè)漏洞的根源，因?yàn)閺恼{(diào)用?？梢钥闯鲞@個(gè)函數(shù)的調(diào)用處于Nexus包與hibernate-validator包的分界，并且計(jì)算器的彈出也是在它之后進(jìn)入hibernate-validator的處理流程，即buildConstraintViolationWithTemplate(xxx).addConstraintViolation()，最終在hibernate-validator包中的ElTermResolver中通過(guò)valueExpression.getValue(context)完成了表達(dá)式的執(zhí)行，與@r00t4dm師傅也說(shuō)到了這個(gè)：
于是反編譯了Nexus3所有jar包，然后搜索這個(gè)關(guān)鍵詞（使用的修復(fù)版本搜索，主要是看有沒(méi)有遺漏的地方?jīng)]修復(fù)；Nexue3有開(kāi)源部分代碼，也可以直接在源碼搜索）：
F:\compare-file\nexus-3.21.2-03-win64\nexus-3.21.2-03\system\com\sonatype\nexus\plugins\nexus-healthcheck-base\3.21.2-03\nexus-healthcheck-base-3.21.2-03\com\sonatype\nexus\clm\validator\ClmAuthenticationValidator.java:
26 return this.validate(ClmAuthenticationType.valueOf(iqConnectionXo.getAuthenticationType(), ClmAuthenticationType.USER), iqConnectionXo.getUsername(), iqConnectionXo.getPassword(), context);
27 } else {
28: context.buildConstraintViolationWithTemplate("unsupported annotated object " + value).addConstraintViolation();
29 return false;
30 }
..
35 case 1:
36 if (StringUtils.isBlank(username)) {
37: context.buildConstraintViolationWithTemplate("User Authentication method requires the username to be set.").addPropertyNode("username").addConstraintViolation();
38 }
39
40 if (StringUtils.isBlank(password)) {
41: context.buildConstraintViolationWithTemplate("User Authentication method requires the password to be set.").addPropertyNode("password").addConstraintViolation();
42 }
43
..
52 }
53
54: context.buildConstraintViolationWithTemplate("To proceed with PKI Authentication, clear the username and password fields. Otherwise, please select User Authentication.").addPropertyNode("authenticationType").addConstraintViolation();
55 return false;
56 default:
57: context.buildConstraintViolationWithTemplate("unsupported authentication type " + authenticationType).addConstraintViolation();
58 return false;
59 }F:\compare-file\nexus-3.21.2-03-win64\nexus-3.21.2-03\system\org\hibernate\validator\hibernate-validator\6.1.0.Final\hibernate-validator-6.1.0.Final\org\hibernate\validator\internal\constraintvalidators\hv\ScriptAssertValidator.java:34 if (!validationResult && !this.reportOn.isEmpty()) {35 constraintValidatorContext.disableDefaultConstraintViolation();36: constraintValidatorContext.buildConstraintViolationWithTemplate(this.message).addPropertyNode(this.reportOn).addConstraintViolation();37 }38 F:\compare-file\nexus-3.21.2-03-win64\nexus-3.21.2-03\system\org\hibernate\validator\hibernate-validator\6.1.0.Final\hibernate-validator-6.1.0.Final\org\hibernate\validator\internal\engine\constraintvalidation\ConstraintValidatorContextImpl.java:
55 }
56
57: public ConstraintViolationBuilder buildConstraintViolationWithTemplate(String messageTemplate) {
58 return new ConstraintValidatorContextImpl.ConstraintViolationBuilderImpl(messageTemplate, this.getCopyOfBasePath());
59 }F:\compare-file\nexus-3.21.2-03-win64\nexus-3.21.2-03\system\org\sonatype\nexus\nexus-cleanup\3.21.0-02\nexus-cleanup-3.21.0-02\org\sonatype\nexus\cleanup\storage\config\CleanupPolicyAssetNamePatternValidator.java:18 } catch (RegexCriteriaValidator.InvalidExpressionException var4) {19 context.disableDefaultConstraintViolation();20: context.buildConstraintViolationWithTemplate(var4.getMessage()).addConstraintViolation();21 return false;22 }F:\compare-file\nexus-3.21.2-03-win64\nexus-3.21.2-03\system\org\sonatype\nexus\nexus-cleanup\3.21.2-03\nexus-cleanup-3.21.2-03\org\sonatype\nexus\cleanup\storage\config\CleanupPolicyAssetNamePatternValidator.java:
18 } catch (RegexCriteriaValidator.InvalidExpressionException var4) {
19 context.disableDefaultConstraintViolation();
20: context.buildConstraintViolationWithTemplate(this.getEscapeHelper().stripJavaEl(var4.getMessage())).addConstraintViolation();
21 return false;
22 }F:\compare-file\nexus-3.21.2-03-win64\nexus-3.21.2-03\system\org\sonatype\nexus\nexus-scheduling\3.21.2-03\nexus-scheduling-3.21.2-03\org\sonatype\nexus\scheduling\constraints\CronExpressionValidator.java:
29 } catch (IllegalArgumentException var4) {
30 context.disableDefaultConstraintViolation();
31: context.buildConstraintViolationWithTemplate(this.getEscapeHelper().stripJavaEl(var4.getMessage())).addConstraintViolation();
32 return false;
33 }F:\compare-file\nexus-3.21.2-03-win64\nexus-3.21.2-03\system\org\sonatype\nexus\nexus-security\3.21.2-03\nexus-security-3.21.2-03\org\sonatype\nexus\security\privilege\PrivilegesExistValidator.java:
42 if (!privilegeId.matches("^[a-zA-Z0-9\\-]{1}[a-zA-Z0-9_\\-\\.]*$")) {
43 context.disableDefaultConstraintViolation();
44: context.buildConstraintViolationWithTemplate("Invalid privilege id: " + this.getEscapeHelper().stripJavaEl(privilegeId) + ". " + "Only letters, digits, underscores(_), hyphens(-), and dots(.) are allowed and may not start with underscore or dot.").addConstraintViolation(); 45 return false; 46 } .. 55 } else { 56 context.disableDefaultConstraintViolation(); 57: context.buildConstraintViolationWithTemplate("Missing privileges: " + missing).addConstraintViolation(); 58 return false; 59 }F:\compare-file\nexus-3.21.2-03-win64\nexus-3.21.2-03\system\org\sonatype\nexus\nexus-security\3.21.2-03\nexus-security-3.21.2-03\org\sonatype\nexus\security\role\RoleNotContainSelfValidator.java: 49 if (this.containsRole(id, roleId, processedRoleIds)) { 50 context.disableDefaultConstraintViolation(); 51: context.buildConstraintViolationWithTemplate(this.message).addConstraintViolation(); 52 return false; 53 }F:\compare-file\nexus-3.21.2-03-win64\nexus-3.21.2-03\system\org\sonatype\nexus\nexus-security\3.21.2-03\nexus-security-3.21.2-03\org\sonatype\nexus\security\role\RolesExistValidator.java: 42 } else { 43 context.disableDefaultConstraintViolation(); 44: context.buildConstraintViolationWithTemplate("Missing roles: " + missing).addConstraintViolation();
45 return false;
46 }F:\compare-file\nexus-3.21.2-03-win64\nexus-3.21.2-03\system\org\sonatype\nexus\nexus-validation\3.21.2-03\nexus-validation-3.21.2-03\org\sonatype\nexus\validation\ConstraintViolationFactory.java:
75 public boolean isValid(ConstraintViolationFactory.HelperBean bean, ConstraintValidatorContext context) {
76 context.disableDefaultConstraintViolation();
77: ConstraintViolationBuilder builder = context.buildConstraintViolationWithTemplate(this.getEscapeHelper().stripJavaEl(bean.getMessage()));
78 NodeBuilderCustomizableContext nodeBuilder = null;
79 String[] var8;后面作者也發(fā)布了漏洞分析，確實(shí)用了buildConstraintViolationWithTemplate作為了漏洞的根源，利用這個(gè)關(guān)鍵點(diǎn)做的污點(diǎn)跟蹤分析。
從上面的搜索結(jié)果中可以看到，el表達(dá)式導(dǎo)致的那三個(gè)CVE關(guān)鍵點(diǎn)也在其中，同時(shí)還有其他幾個(gè)地方，有幾個(gè)使用了this.getEscapeHelper().stripJavaEl做了清除，還有幾個(gè)，看起來(lái)似乎也可以，心里一陣狂喜？然而，其他幾個(gè)沒(méi)有做清除的地方雖然能通過(guò)路由進(jìn)入，但是利用不了，后面會(huì)挑選其中的一個(gè)做下分析。所以在開(kāi)始說(shuō)了官方可能修復(fù)了幾個(gè)類(lèi)似的地方，猜想有兩種可能：
官方自己察覺(jué)到了那幾個(gè)地方也會(huì)存在el解析漏洞，所以做了清除
有其他漏洞發(fā)現(xiàn)者提交了那幾個(gè)做了清除的漏洞點(diǎn)，因?yàn)槟菐讉€(gè)地方可以利用；但是沒(méi)清除的那幾個(gè)地方由于沒(méi)法利用，所以發(fā)現(xiàn)者并沒(méi)有提交，官方也沒(méi)有去做清除
不過(guò)感覺(jué)后一種可能性更大，畢竟官方不太可能有的地方做清除，有的地方不做清除，要做也是一起做清除工作。
這個(gè)漏洞對(duì)應(yīng)上面的搜索結(jié)果是RolesExistValidator，既然搜索到了關(guān)鍵點(diǎn)，自己來(lái)手動(dòng)逆向回溯下看能不能回溯到有路由處理的地方，這里用簡(jiǎn)單的搜索回溯下。
關(guān)鍵點(diǎn)在RolesExistValidator的isValid，調(diào)用了buildConstraintViolationWithTemplate。搜索下有沒(méi)有調(diào)用RolesExistValidator的地方：
在RolesExist中有調(diào)用，這種寫(xiě)法一般會(huì)把RolesExist當(dāng)作注解來(lái)使用，并且進(jìn)行校驗(yàn)時(shí)會(huì)調(diào)用RolesExistValidator.isValid()。繼續(xù)搜索RolesExist：
有好幾處直接使用了RolesExist對(duì)roles屬性進(jìn)行注解，可以一個(gè)一個(gè)去回溯，不過(guò)按照Role這個(gè)關(guān)鍵字RoleXO可能性更大，所以先看這個(gè)（UserXO也可以的），繼續(xù)搜索RoleXO：
會(huì)有很多其他干擾的，比如第一個(gè)紅色標(biāo)注RoleXOResponse，這種可以忽略，我們找直接使用RoleXO的地方。在RoleComponent中，看到第二個(gè)紅色標(biāo)注這種注解大概就知道，這里能進(jìn)入路由了。第三個(gè)紅色標(biāo)注使用了roleXO，并且有roles關(guān)鍵字，上面RolesExist也是對(duì)roles進(jìn)行注解的，所以這里猜測(cè)是對(duì)roleXO進(jìn)行屬性注入。有的地方反編譯出來(lái)的代碼不好理解，可以結(jié)合源碼看：
可以看到這里就是將提交的參數(shù)注入給了roleXO，RoleComponent對(duì)應(yīng)的路由如下：
通過(guò)上面的分析，我們大概知道了能進(jìn)入到最終的RolesExistValidator，不過(guò)中間可能還有很多條件需要滿足，需要構(gòu)造payload然后一步一步測(cè)。這個(gè)路由對(duì)應(yīng)的web頁(yè)面位置如下：
測(cè)試（這里使用的3.21.1版本，CVE-2018-16621是之前的漏洞，在3.21.1早修復(fù)了，不過(guò)3.21.1又被繞過(guò)了，所以下面使用的是繞過(guò)的情況，將$換成$\\x去繞過(guò)，繞過(guò)在后面兩個(gè)CVE再說(shuō)）：
修復(fù)方式：
加上了getEscapeHelper().stripJavaEL對(duì)el表達(dá)式做了清除，將${替換為了{(lán)，之后的兩個(gè)CVE就是對(duì)這個(gè)修復(fù)方式的繞過(guò)：
這就是上面說(shuō)到的對(duì)之前stripJavaEL修復(fù)的繞過(guò)，這里就不細(xì)分析了，利用$\\x格式就不會(huì)被替換掉（使用3.21.1版本測(cè)試）：
這個(gè)漏洞對(duì)應(yīng)上面搜索結(jié)果是ConstraintViolationFactory：
buildConstraintViolationWith（標(biāo)號(hào)1）出現(xiàn)在了HelperValidator（標(biāo)號(hào)2）的isValid中，HelperValidator又被注解在HelperAnnotation（標(biāo)號(hào)3、4）之上，HelperAnnotation注解在了HelperBean（標(biāo)號(hào)5）之上，在ConstraintViolationFactory.createViolation方法中使用到了HelperBean（標(biāo)號(hào)6、7）。按照這個(gè)思路要找調(diào)用了ConstraintViolationFactory.createViolation的地方。
也來(lái)手動(dòng)逆向回溯下看能不能回溯到有路由處理的地方。
搜索ConstraintViolationFactory：
有好幾個(gè)，這里使用第一個(gè)BowerGroupRepositoriesApiResource分析，點(diǎn)進(jìn)去看就能看出它是一個(gè)API路由：
ConstraintViolationFactory被傳遞給了super，在BowerGroupRepositoriesApiResource并沒(méi)有調(diào)用ConstraintViolationFactory的其他函數(shù)，不過(guò)它的兩個(gè)方法，也是調(diào)用了super對(duì)應(yīng)的方法。它的super是AbstractGroupRepositoriesApiResource類(lèi)：
BowerGroupRepositoriesApiResource構(gòu)造函數(shù)中調(diào)用的super，在AbstractGroupRepositoriesApiResource賦值了ConstraintViolationFactory（標(biāo)號(hào)1），ConstraintViolationFactory的使用（標(biāo)號(hào)2），調(diào)用了createViolation（在后面可以看到memberNames參數(shù)），這也是之前要到達(dá)漏洞點(diǎn)所需要的，這個(gè)調(diào)用處于validateGroupMembers中（標(biāo)號(hào)3），validateGroupMembers的調(diào)用在createRepository（標(biāo)號(hào)4）和updateRepository（標(biāo)號(hào)5）中都進(jìn)行了調(diào)用，而這兩個(gè)方法通過(guò)上面的注解也可以看出，通過(guò)外部傳遞請(qǐng)求能到達(dá)。
BowerGroupRepositoriesApiResource的路由為/beta/repositories/bower/group，在后臺(tái)API找到它來(lái)進(jìn)行調(diào)用（使用3.21.1測(cè)試）：
還有AbstractGroupRepositoriesApiResource的其他幾個(gè)子類(lèi)也是可以的：
對(duì)應(yīng)上面搜索結(jié)果的CleanupPolicyAssetNamePatternValidator，可以看到這里并沒(méi)有做StripEL清除操作：
這個(gè)變量是通過(guò)報(bào)錯(cuò)拋出放到buildConstraintViolationWithTemplate中的，要是報(bào)錯(cuò)信息中包含了value值，那么這里就是可以利用的。
搜索CleanupPolicyAssetNamePatternValidator：
在CleanupPolicyAssetNamePattern類(lèi)注解中使用了，繼續(xù)搜索CleanupPolicyAssetNamePattern：
在CleanupPolicyCriteria中的屬性regex被CleanupPolicyAssetNamePattern注解了，繼續(xù)搜索CleanupPolicyCriteria：
在CleanupPolicyComponent中的to CleanupPolicy方法中有調(diào)用，其中的cleanupPolicyXO.getCriteria也正好是CleanupPolicyCriteria對(duì)象。toCleanupPolicy在CleanupPolicyComponent的可通過(guò)路由進(jìn)入的create、previewCleanup方法又調(diào)用了toCleanupPolicy。
構(gòu)造payload測(cè)試：
然而這里并不能利用，value值不會(huì)被包含在報(bào)錯(cuò)信息中，去看了下RegexCriteriaValidator.validate，無(wú)論如何構(gòu)造，最終也只會(huì)拋出value中的一個(gè)字符，所以這里并不能利用。
與這個(gè)類(lèi)似的是CronExpressionValidator，那里也是通過(guò)拋出異常，但是那里是可以利用的，不過(guò)被修復(fù)了，可能之前已經(jīng)有人提交過(guò)了。還有其他幾個(gè)沒(méi)做清除的地方，要么被if、else跳過(guò)了，要么不能利用。
人工去回溯查找的方式，如果關(guān)鍵字被調(diào)用的地方不多可能還好，不過(guò)要是被大量使用，可能就不是那么好處理了。不過(guò)上面幾個(gè)漏洞，可以看到通過(guò)手動(dòng)回溯查找還是可行的。
可以參考下@iswin大佬之前的分析https://www.anquanke.com/post/id/171116，這里就不再去調(diào)試截圖了。這里想寫(xiě)下之前對(duì)這個(gè)漏洞的修復(fù)，說(shuō)是加了權(quán)限來(lái)修復(fù)，要是只加了權(quán)限，那不是還能提交一下？不過(guò)，測(cè)試了下3.21.1版本，就算用admin權(quán)限也無(wú)法利用了，想去看下是不是能繞過(guò)。在3.14.0中測(cè)試，確實(shí)是可以的：
但是3.21.1中，就算加了權(quán)限，也是不行的。后面分別調(diào)試對(duì)比了下，以及通過(guò)下面這個(gè)測(cè)試：
JexlEngine jexl = new JexlBuilder().create();String jexlExp = "''.class.forName('java.lang.Runtime').getRuntime().exec('calc.exe')";JexlExpression e = jexl.createExpression(jexlExp);JexlContext jc = new MapContext();jc.set("foo", "aaa");e.evaluate(jc);才知道3.14.0與上面這個(gè)測(cè)試使用的是org.apache.commons.jexl3.internal.introspection.Uberspect處理，它的getMethod方法如下：
而在3.21.1中Nexus設(shè)置的是org.apache.commons.jexl3.internal.introspection.SandboxJexlUberspect，這個(gè)SandboxJexlUberspect，它的get Method方法如下：
可以看出只允許調(diào)用String、Map、Collection類(lèi)型的有限幾個(gè)方法了。
看完上面的內(nèi)容，相信對(duì)Nexus3的漏洞大體有了解了，不會(huì)再無(wú)從下手的感覺(jué)。嘗試看下下其他地方，例如后臺(tái)有個(gè)LDAP，可進(jìn)行jndi connect操作，不過(guò)那里調(diào)用的是context.getAttribute，雖然會(huì)遠(yuǎn)程請(qǐng)求class文件，不過(guò)并不會(huì)加載class，所以并沒(méi)有危害。
有的漏洞的根源點(diǎn)可能會(huì)在一個(gè)應(yīng)用中出現(xiàn)相似的地方，就像上面那個(gè)buildConstraintViolationWithTemplate這個(gè)keyword一樣，運(yùn)氣好說(shuō)不定一個(gè)簡(jiǎn)單的搜索都能碰到一些相似漏洞（不過(guò)我運(yùn)氣貌似差了點(diǎn)，通過(guò)上面的搜索可以看到某些地方的修復(fù)，說(shuō)明已經(jīng)有人先行一步了，直接調(diào)用了buildConstraintViolationWithTemplate并且可用的地方似乎已經(jīng)沒(méi)有了）
仔細(xì)看下上面幾個(gè)漏洞的payload，好像相似度很高，所以可以弄個(gè)類(lèi)似fuzz參數(shù)的工具，搜集這個(gè)應(yīng)用的歷史漏洞payload，每個(gè)參數(shù)都可以測(cè)試下對(duì)應(yīng)的payload，運(yùn)氣好可能會(huì)撞到一些相似漏洞
以上是“Nexus Repository Manager 3幾次表達(dá)式解析漏洞的示例分析”這篇文章的所有內(nèi)容，感謝各位的閱讀！相信大家都有了一定的了解，希望分享的內(nèi)容對(duì)大家有所幫助，如果還想學(xué)習(xí)更多知識(shí)，歡迎關(guān)注創(chuàng)新互聯(lián)行業(yè)資訊頻道！
