NexusRepositoryManager3幾次表達(dá)式解析漏洞的示例分析

小編給大家分享一下Nexus Repository Manager 3幾次表達(dá)式解析漏洞的示例分析，相信大部分人都還不怎么了解，因此分享這篇文章給大家參考一下，希望大家閱讀完這篇文章后大有收獲，下面讓我們一起去了解一下吧！

公司專注于為企業(yè)提供成都網(wǎng)站設(shè)計、網(wǎng)站建設(shè)、外貿(mào)網(wǎng)站建設(shè)、微信公眾號開發(fā)、電子商務(wù)商城網(wǎng)站建設(shè)，微信小程序定制開發(fā)，軟件按需搭建網(wǎng)站等一站式互聯(lián)網(wǎng)企業(yè)服務(wù)。憑借多年豐富的經(jīng)驗，我們會仔細(xì)了解各客戶的需求而做出多方面的分析、設(shè)計、整合，為客戶設(shè)計出具風(fēng)格及創(chuàng)意性的商業(yè)解決方案，成都創(chuàng)新互聯(lián)更提供一系列網(wǎng)站制作和網(wǎng)站推廣的服務(wù)。

Nexus Repository Manager 3最近曝出兩個el表達(dá)式解析漏洞，編號為CVE-2020-10199，CVE-2020-10204，都是由Github Secutiry Lab團(tuán)隊的@pwntester發(fā)現(xiàn)。由于之前Nexus3的漏洞沒有去跟蹤，所以當(dāng)時diff得很頭疼，并且Nexus3 bug與安全修復(fù)都是混在一起，更不容易猜到哪個可能是漏洞位置了。后面與@r00t4dm師傅一起復(fù)現(xiàn)出了CVE-2020-10204，CVE-2020-10204是CVE-2018-16621的繞過，之后又有師傅弄出了CVE-2020-10199，這三個漏洞的根源是一樣的，其實并不止這三處，官方可能已經(jīng)修復(fù)了好幾處這樣的漏洞，由于歷史不太好追溯回去，所以加了可能，通過后面的分析，就能看到了。還有之前的CVE-2019-7238，這是一個jexl表達(dá)式解析，一并在這里分析下，以及對它的修復(fù)問題，之前看到有的分析文章說這個漏洞是加了個權(quán)限來修復(fù)，可能那時是真的只加了個權(quán)限吧，不過我測試用的較新的版本，加了權(quán)限貌似也沒用，在Nexus3高版本已經(jīng)使用了jexl白名單的沙箱。

測試環(huán)境

文中會用到三個Nexus3環(huán)境：

nexus-3.14.0-04

nexus-3.21.1-01

nexus-3.21.2-03

nexus-3.14.0-04用于測試jexl表達(dá)式解析，nexus-3.21.1-01用于測試jexl表達(dá)式解析與el表達(dá)式解析以及diff，nexus-3.21.2-03用于測試el表達(dá)式解析以及diff

漏洞diff

CVE-2020-10199、CVE-2020-10204漏洞的修復(fù)界限是3.21.1與3.21.2，但是github開源的代碼分支好像不對應(yīng)，所以只得去下載壓縮包來對比了。在官方下載了nexus-3.21.1-01與nexus-3.21.2-03，但是beyond對比需要目錄名一樣，文件名一樣，而不同版本的代碼有的文件與文件名都不一樣。我是先分別反編譯了對應(yīng)目錄下的所有jar包，然后用腳本將nexus-3.21.1-01中所有的文件與文件名中含有3.21.1-01的替換為了3.21.2-03，同時刪除了META文件夾，這個文件夾對漏洞diff沒什么用并且影響diff分析，所以都刪除了，下面是處理后的效果：

如果沒有調(diào)試和熟悉之前的Nexus3漏洞，直接去看diff可能會看得很頭疼，沒有目標(biāo)的diff。

路由以及對應(yīng)的處理類

一般路由

抓下nexus3發(fā)的包，隨意的點(diǎn)點(diǎn)點(diǎn)，可以看到大多數(shù)請求都是POST類型的，URI都是/service/extdirect：

post內(nèi)容如下：

{"action":"coreui_Repository","method":"getBrowseableFormats","data":null,"type":"rpc","tid":7}

可以看下其他請求，json中都有action與method這兩個key，在代碼中搜索下coreui_Repository這個關(guān)鍵字：

可以看到這樣的地方，展開看下代碼：

通過注解方式注入了action，上面post的method->getBrowseableFormats也在中，通過注解注入了對應(yīng)的method：

所以之后這樣的請求，我們就很好定位路由與對應(yīng)的處理類了

API路由

Nexus3的API也出現(xiàn)了漏洞，來看下怎么定位API的路由，在后臺能看到Nexus3提供的所有API。

點(diǎn)幾個看下包，有GET、POST、DELETE、PUT等類型的請求：

沒有了之前的action與method，這里用URI來定位，直接搜索/service/rest/beta/security/content-selectors定位不到，所以縮短關(guān)鍵字，用/beta/security/content-selectors來定位：

通過@Path注解來注入URI，對應(yīng)的處理方式也使用了對應(yīng)的@GET、@POST來注解

可能還有其他類型的路由，不過也可以使用上面類似的方式進(jìn)行搜索來定位。還有Nexus的權(quán)限問題，可以看到上面有的請求通過@RequiresPermissions來設(shè)置了權(quán)限，不過還是以實際的測試權(quán)限為準(zhǔn)，有的在到達(dá)之前也進(jìn)行了權(quán)限校驗，有的操作雖然在web頁面的admin頁面，不過本不需要admin權(quán)限，可能無權(quán)限或者只需要普通權(quán)限。

buildConstraintViolationWithTemplate造成的幾次Java EL漏洞

在跟蹤調(diào)試了CVE-2018-16621與CVE-2020-10204之后，感覺buildConstraintViolationWithTemplate這個keyword可以作為這個漏洞的根源，因為從調(diào)用棧可以看出這個函數(shù)的調(diào)用處于Nexus包與hibernate-validator包的分界，并且計算器的彈出也是在它之后進(jìn)入hibernate-validator的處理流程，即buildConstraintViolationWithTemplate(xxx).addConstraintViolation()，最終在hibernate-validator包中的ElTermResolver中通過valueExpression.getValue(context)完成了表達(dá)式的執(zhí)行，與@r00t4dm師傅也說到了這個：

于是反編譯了Nexus3所有jar包，然后搜索這個關(guān)鍵詞（使用的修復(fù)版本搜索，主要是看有沒有遺漏的地方?jīng)]修復(fù)；Nexue3有開源部分代碼，也可以直接在源碼搜索）：

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ā)布了漏洞分析，確實用了buildConstraintViolationWithTemplate作為了漏洞的根源，利用這個關(guān)鍵點(diǎn)做的污點(diǎn)跟蹤分析。

從上面的搜索結(jié)果中可以看到，el表達(dá)式導(dǎo)致的那三個CVE關(guān)鍵點(diǎn)也在其中，同時還有其他幾個地方，有幾個使用了this.getEscapeHelper().stripJavaEl做了清除，還有幾個，看起來似乎也可以，心里一陣狂喜？然而，其他幾個沒有做清除的地方雖然能通過路由進(jìn)入，但是利用不了，后面會挑選其中的一個做下分析。所以在開始說了官方可能修復(fù)了幾個類似的地方，猜想有兩種可能：

官方自己察覺到了那幾個地方也會存在el解析漏洞，所以做了清除

有其他漏洞發(fā)現(xiàn)者提交了那幾個做了清除的漏洞點(diǎn)，因為那幾個地方可以利用；但是沒清除的那幾個地方由于沒法利用，所以發(fā)現(xiàn)者并沒有提交，官方也沒有去做清除

不過感覺后一種可能性更大，畢竟官方不太可能有的地方做清除，有的地方不做清除，要做也是一起做清除工作。

CVE-2018-16621分析

這個漏洞對應(yīng)上面的搜索結(jié)果是RolesExistValidator，既然搜索到了關(guān)鍵點(diǎn)，自己來手動逆向回溯下看能不能回溯到有路由處理的地方，這里用簡單的搜索回溯下。

關(guān)鍵點(diǎn)在RolesExistValidator的isValid，調(diào)用了buildConstraintViolationWithTemplate。搜索下有沒有調(diào)用RolesExistValidator的地方：

在RolesExist中有調(diào)用，這種寫法一般會把RolesExist當(dāng)作注解來使用，并且進(jìn)行校驗時會調(diào)用RolesExistValidator.isValid()。繼續(xù)搜索RolesExist：

有好幾處直接使用了RolesExist對roles屬性進(jìn)行注解，可以一個一個去回溯，不過按照Role這個關(guān)鍵字RoleXO可能性更大，所以先看這個（UserXO也可以的），繼續(xù)搜索RoleXO：

會有很多其他干擾的，比如第一個紅色標(biāo)注RoleXOResponse，這種可以忽略，我們找直接使用RoleXO的地方。在RoleComponent中，看到第二個紅色標(biāo)注這種注解大概就知道，這里能進(jìn)入路由了。第三個紅色標(biāo)注使用了roleXO，并且有roles關(guān)鍵字，上面RolesExist也是對roles進(jìn)行注解的，所以這里猜測是對roleXO進(jìn)行屬性注入。有的地方反編譯出來的代碼不好理解，可以結(jié)合源碼看：

可以看到這里就是將提交的參數(shù)注入給了roleXO，RoleComponent對應(yīng)的路由如下：

通過上面的分析，我們大概知道了能進(jìn)入到最終的RolesExistValidator，不過中間可能還有很多條件需要滿足，需要構(gòu)造payload然后一步一步測。這個路由對應(yīng)的web頁面位置如下：

測試（這里使用的3.21.1版本，CVE-2018-16621是之前的漏洞，在3.21.1早修復(fù)了，不過3.21.1又被繞過了，所以下面使用的是繞過的情況，將$換成$\\x去繞過，繞過在后面兩個CVE再說）：

修復(fù)方式：

加上了getEscapeHelper().stripJavaEL對el表達(dá)式做了清除，將${替換為了{(lán)，之后的兩個CVE就是對這個修復(fù)方式的繞過：

CVE-2020-10204分析

這就是上面說到的對之前stripJavaEL修復(fù)的繞過，這里就不細(xì)分析了，利用$\\x格式就不會被替換掉（使用3.21.1版本測試）：

CVE-2020-10199分析

這個漏洞對應(yīng)上面搜索結(jié)果是ConstraintViolationFactory：

buildConstraintViolationWith（標(biāo)號1）出現(xiàn)在了HelperValidator（標(biāo)號2）的isValid中，HelperValidator又被注解在HelperAnnotation（標(biāo)號3、4）之上，HelperAnnotation注解在了HelperBean（標(biāo)號5）之上，在ConstraintViolationFactory.createViolation方法中使用到了HelperBean（標(biāo)號6、7）。按照這個思路要找調(diào)用了ConstraintViolationFactory.createViolation的地方。

也來手動逆向回溯下看能不能回溯到有路由處理的地方。

搜索ConstraintViolationFactory：

有好幾個，這里使用第一個BowerGroupRepositoriesApiResource分析，點(diǎn)進(jìn)去看就能看出它是一個API路由：

ConstraintViolationFactory被傳遞給了super，在BowerGroupRepositoriesApiResource并沒有調(diào)用ConstraintViolationFactory的其他函數(shù)，不過它的兩個方法，也是調(diào)用了super對應(yīng)的方法。它的super是AbstractGroupRepositoriesApiResource類：

BowerGroupRepositoriesApiResource構(gòu)造函數(shù)中調(diào)用的super，在AbstractGroupRepositoriesApiResource賦值了ConstraintViolationFactory（標(biāo)號1），ConstraintViolationFactory的使用（標(biāo)號2），調(diào)用了createViolation（在后面可以看到memberNames參數(shù)），這也是之前要到達(dá)漏洞點(diǎn)所需要的，這個調(diào)用處于validateGroupMembers中（標(biāo)號3），validateGroupMembers的調(diào)用在createRepository（標(biāo)號4）和updateRepository（標(biāo)號5）中都進(jìn)行了調(diào)用，而這兩個方法通過上面的注解也可以看出，通過外部傳遞請求能到達(dá)。

BowerGroupRepositoriesApiResource的路由為/beta/repositories/bower/group，在后臺API找到它來進(jìn)行調(diào)用（使用3.21.1測試）：

還有AbstractGroupRepositoriesApiResource的其他幾個子類也是可以的：

CleanupPolicyAssetNamePatternValidator未做清除點(diǎn)分析

對應(yīng)上面搜索結(jié)果的CleanupPolicyAssetNamePatternValidator，可以看到這里并沒有做StripEL清除操作：

這個變量是通過報錯拋出放到buildConstraintViolationWithTemplate中的，要是報錯信息中包含了value值，那么這里就是可以利用的。

搜索CleanupPolicyAssetNamePatternValidator：

在CleanupPolicyAssetNamePattern類注解中使用了，繼續(xù)搜索CleanupPolicyAssetNamePattern：

在CleanupPolicyCriteria中的屬性regex被CleanupPolicyAssetNamePattern注解了，繼續(xù)搜索CleanupPolicyCriteria：

在CleanupPolicyComponent中的to CleanupPolicy方法中有調(diào)用，其中的cleanupPolicyXO.getCriteria也正好是CleanupPolicyCriteria對象。toCleanupPolicy在CleanupPolicyComponent的可通過路由進(jìn)入的create、previewCleanup方法又調(diào)用了toCleanupPolicy。

構(gòu)造payload測試：

然而這里并不能利用，value值不會被包含在報錯信息中，去看了下RegexCriteriaValidator.validate，無論如何構(gòu)造，最終也只會拋出value中的一個字符，所以這里并不能利用。

與這個類似的是CronExpressionValidator，那里也是通過拋出異常，但是那里是可以利用的，不過被修復(fù)了，可能之前已經(jīng)有人提交過了。還有其他幾個沒做清除的地方，要么被if、else跳過了，要么不能利用。

人工去回溯查找的方式，如果關(guān)鍵字被調(diào)用的地方不多可能還好，不過要是被大量使用，可能就不是那么好處理了。不過上面幾個漏洞，可以看到通過手動回溯查找還是可行的。

JXEL造成的漏洞（CVE-2019-7238）

可以參考下@iswin大佬之前的分析https://www.anquanke.com/post/id/171116，這里就不再去調(diào)試截圖了。這里想寫下之前對這個漏洞的修復(fù)，說是加了權(quán)限來修復(fù)，要是只加了權(quán)限，那不是還能提交一下？不過，測試了下3.21.1版本，就算用admin權(quán)限也無法利用了，想去看下是不是能繞過。在3.14.0中測試，確實是可以的：

但是3.21.1中，就算加了權(quán)限，也是不行的。后面分別調(diào)試對比了下，以及通過下面這個測試：

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與上面這個測試使用的是org.apache.commons.jexl3.internal.introspection.Uberspect處理，它的getMethod方法如下：

而在3.21.1中Nexus設(shè)置的是org.apache.commons.jexl3.internal.introspection.SandboxJexlUberspect，這個SandboxJexlUberspect，它的get Method方法如下：

可以看出只允許調(diào)用String、Map、Collection類型的有限幾個方法了。

總結(jié)

看完上面的內(nèi)容，相信對Nexus3的漏洞大體有了解了，不會再無從下手的感覺。嘗試看下下其他地方，例如后臺有個LDAP，可進(jìn)行jndi connect操作，不過那里調(diào)用的是context.getAttribute，雖然會遠(yuǎn)程請求class文件，不過并不會加載class，所以并沒有危害。

有的漏洞的根源點(diǎn)可能會在一個應(yīng)用中出現(xiàn)相似的地方，就像上面那個buildConstraintViolationWithTemplate這個keyword一樣，運(yùn)氣好說不定一個簡單的搜索都能碰到一些相似漏洞（不過我運(yùn)氣貌似差了點(diǎn)，通過上面的搜索可以看到某些地方的修復(fù)，說明已經(jīng)有人先行一步了，直接調(diào)用了buildConstraintViolationWithTemplate并且可用的地方似乎已經(jīng)沒有了）

仔細(xì)看下上面幾個漏洞的payload，好像相似度很高，所以可以弄個類似fuzz參數(shù)的工具，搜集這個應(yīng)用的歷史漏洞payload，每個參數(shù)都可以測試下對應(yīng)的payload，運(yùn)氣好可能會撞到一些相似漏洞

以上是“Nexus Repository Manager 3幾次表達(dá)式解析漏洞的示例分析”這篇文章的所有內(nèi)容，感謝各位的閱讀！相信大家都有了一定的了解，希望分享的內(nèi)容對大家有所幫助，如果還想學(xué)習(xí)更多知識，歡迎關(guān)注創(chuàng)新互聯(lián)行業(yè)資訊頻道！

名稱欄目：NexusRepositoryManager3幾次表達(dá)式解析漏洞的示例分析
URL網(wǎng)址：http://muchs.cn/article48/ghioep.html

成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián)，為您提供搜索引擎優(yōu)化、企業(yè)網(wǎng)站制作、外貿(mào)建站、微信公眾號、網(wǎng)站建設(shè)、靜態(tài)網(wǎng)站

廣告

聲明：本網(wǎng)站發(fā)布的內(nèi)容（圖片、視頻和文字）以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主，如果涉及侵權(quán)請盡快告知，我們將會在第一時間刪除。文章觀點(diǎn)不代表本網(wǎng)站立場，如需處理請聯(lián)系客服。電話：028-86922220；郵箱：631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載，或轉(zhuǎn)載時需注明來源： 創(chuàng)新互聯(lián)