本發(fā)明涉及互聯(lián)網(wǎng)安全技術(shù)領(lǐng)域，尤其涉及一種對(duì)應(yīng)用漏洞進(jìn)行修復(fù)的裝置、方法以及系統(tǒng)。

背景技術(shù)：

隨著互聯(lián)網(wǎng)的日益普及，越來越多的企業(yè)通過網(wǎng)絡(luò)服務(wù)器以及應(yīng)用服務(wù)器中的各類應(yīng)用向用戶提供各種產(chǎn)品和服務(wù)。應(yīng)用無處不在，而且通常運(yùn)行在企業(yè)內(nèi)部能夠訪問敏感數(shù)據(jù)，而大型機(jī)構(gòu)運(yùn)行的應(yīng)用越來越復(fù)雜和多樣，其中還包含了許多第三方的軟件庫。而統(tǒng)計(jì)數(shù)字表明，應(yīng)用中存在的漏洞，導(dǎo)致用戶面臨著諸多風(fēng)險(xiǎn)，比如可能遭受跨站腳本攻擊、SQL注入攻擊、惡意軟件攻擊及其他一些攻擊。

現(xiàn)有技術(shù)中，動(dòng)態(tài)與靜態(tài)應(yīng)用程序安全測(cè)試(DAST和SAST)是比較常用的漏洞檢查工具，這些軟件工具對(duì)應(yīng)用進(jìn)行分析，嘗試發(fā)現(xiàn)應(yīng)用中的漏洞，但是難以發(fā)現(xiàn)應(yīng)用所依賴的第三方程序和服務(wù)器的漏洞。而且很多應(yīng)用只提供接口，無法得到代碼，即使發(fā)現(xiàn)有漏洞也無法進(jìn)行修復(fù)。另外，即使第三方軟件商愿意修補(bǔ)漏洞，但是這通常需要等待較長的一段時(shí)間，在這段時(shí)間內(nèi)應(yīng)用仍然暴露在危險(xiǎn)中，利用漏洞的攻擊仍然無法予以防護(hù)。進(jìn)一步地，即使第三方軟件廠商修復(fù)了漏洞，升級(jí)依賴庫和服務(wù)器也會(huì)給應(yīng)用帶來較高的風(fēng)險(xiǎn)(比如兼容性問題、升級(jí)后引入新的漏洞等)。

因此，需要提出一種更便捷更有效的應(yīng)用漏洞修復(fù)方案。

技術(shù)實(shí)現(xiàn)要素：

為此，本發(fā)明提供一種應(yīng)用安全監(jiān)控方案，以力圖解決或者至少緩解上面存在的至少一個(gè)問題。

根據(jù)本發(fā)明的一個(gè)方面，提供了一種對(duì)應(yīng)用漏洞進(jìn)行修復(fù)的裝置，駐留在應(yīng)用服務(wù)器中，應(yīng)用服務(wù)器與安全服務(wù)器通過網(wǎng)絡(luò)連接，安全服務(wù)器存儲(chǔ)有至少一個(gè)漏洞的至少一條漏洞信息，漏洞信息指示存在漏洞的對(duì)象以及該對(duì)象中漏洞位置所在的第一對(duì)象，并包括對(duì)應(yīng)的防護(hù)片段，該裝置包括：通信模塊，適于向安全服務(wù)器獲取漏洞信息；掃描模塊，適于根據(jù)漏洞信息檢測(cè)應(yīng)用是否依賴于存在漏洞的對(duì)象；監(jiān)控模塊，適于若掃描模塊檢測(cè)到應(yīng)用依賴于存在漏洞的對(duì)象，從該漏洞的漏洞信息獲取漏洞位置所在的第一對(duì)象，檢測(cè)加載第一對(duì)象的操作，第一對(duì)象能夠被執(zhí)行以完成相應(yīng)邏輯；插裝模塊，適于當(dāng)監(jiān)控模塊檢測(cè)到所述第一對(duì)象將被加載至內(nèi)存時(shí)，從漏洞信息獲取對(duì)應(yīng)的防護(hù)片段；還適于將獲取的防護(hù)片段插裝至所述第一對(duì)象中，以生成第二對(duì)象；處理引擎，適于在要執(zhí)行第一對(duì)象時(shí)，執(zhí)行第二對(duì)象以完成執(zhí)行第一對(duì)象時(shí)的相應(yīng)邏輯，其中，還適于執(zhí)行第二對(duì)象中的防護(hù)片段，以便根據(jù)完成相應(yīng)邏輯的關(guān)鍵參數(shù)判斷是否存在利用漏洞的惡意事件，若是，攔截該惡意事件并記錄事件信息。

可選地，在根據(jù)本發(fā)明的裝置中，存在漏洞的對(duì)象包括下列中的至少一種：存在漏洞的web容器、第三方框架、應(yīng)用服務(wù)器、庫和類。

可選地，在根據(jù)本發(fā)明的裝置中，第一對(duì)象包括下列中的至少一種：類、接口、以及其中定義的方法、參數(shù)、返回值和變量。

可選地，在根據(jù)本發(fā)明的裝置中，漏洞信息還指示防護(hù)片段在第一對(duì)象中的插裝位置，插裝模塊還適于將防護(hù)片段插入到相應(yīng)的插裝位置，生成第二對(duì)象。

可選地，在根據(jù)本發(fā)明的裝置中，插裝位置包括下列位置中的至少一個(gè)：第一對(duì)象初始化的位置、第一對(duì)象中的方法開始執(zhí)行和/或結(jié)束執(zhí)行的位置。

可選地，在根據(jù)本發(fā)明的裝置中，事件信息包括用戶請(qǐng)求詳情，程序堆棧信息和漏洞描述。

可選地，在根據(jù)本發(fā)明的裝置中，漏洞包括下列中的至少一個(gè)：Struts框架的操作類加載器漏洞、Session Cookie中未設(shè)置HttpOnly的漏洞、JavaSDK中parseDouble造成的拒絕服務(wù)漏洞Java反序列化攻擊漏洞、以及Struts框架遠(yuǎn)程代碼執(zhí)行漏洞。

可選地，在根據(jù)本發(fā)明的裝置中，通信模塊還適于將所述事件信息發(fā)送至所述安全服務(wù)器，以便存儲(chǔ)并生成報(bào)表供用戶查詢。

根據(jù)本發(fā)明的另一方面，提供了一種應(yīng)用漏洞修復(fù)系統(tǒng)，包括：根據(jù)本發(fā)明的應(yīng)用漏洞修復(fù)裝置；以及安全服務(wù)器，適于存儲(chǔ)至少一個(gè)漏洞的至少一條漏洞信息，漏洞信息指示存在漏洞的對(duì)象以及該對(duì)象中漏洞位置所在的第一對(duì)象，并包括對(duì)應(yīng)的防護(hù)片段；還適于接收并存儲(chǔ)惡意事件的事件信息，并根據(jù)事件信息生成報(bào)表供用戶查詢。

根據(jù)本發(fā)明的另一方面，提供了一種對(duì)應(yīng)用漏洞進(jìn)行修復(fù)的方法，適于在應(yīng)用服務(wù)器中執(zhí)行，應(yīng)用服務(wù)器與安全服務(wù)器通過網(wǎng)絡(luò)連接，安全服務(wù)器存儲(chǔ)有至少一個(gè)漏洞的至少一條漏洞信息，漏洞信息指示存在漏洞的對(duì)象以及該對(duì)象中漏洞位置所在的第一對(duì)象，并包括對(duì)應(yīng)的防護(hù)片段，該方法包括：向安全服務(wù)器獲取漏洞信息；根據(jù)漏洞信息檢測(cè)應(yīng)用是否依賴于存在漏洞的對(duì)象；若檢測(cè)到應(yīng)用依賴于存在漏洞的對(duì)象，從該漏洞的漏洞信息獲取漏洞位置所在的第一對(duì)象，檢測(cè)加載第一對(duì)象的操作，第一對(duì)象能夠被執(zhí)行以完成相應(yīng)邏輯；當(dāng)檢測(cè)到第一對(duì)象將被加載至內(nèi)存時(shí)，從漏洞信息獲取對(duì)應(yīng)的防護(hù)片段；將獲取的防護(hù)片段插裝至第一對(duì)象中，以生成第二對(duì)象；在要執(zhí)行第一對(duì)象時(shí)，執(zhí)行第二對(duì)象以完成執(zhí)行第一對(duì)象時(shí)的相應(yīng)邏輯，其中，執(zhí)行第二對(duì)象中的防護(hù)片段，以便根據(jù)完成相應(yīng)邏輯的關(guān)鍵參數(shù)判斷是否存在利用漏洞的惡意事件，若是，攔截該惡意事件并記錄事件信息。

可選地，在根據(jù)本發(fā)明的方法中，存在漏洞的對(duì)象包括下列中的至少一種：存在漏洞的web容器、第三方框架、應(yīng)用服務(wù)器、庫和類。

可選地，在根據(jù)本發(fā)明的方法中，第一對(duì)象包括下列中的至少一種：類、接口、以及其中定義的方法、參數(shù)、返回值和變量。

可選地，在根據(jù)本發(fā)明的方法中，漏洞信息還指示防護(hù)片段在第一對(duì)象中的插裝位置，將獲取的防護(hù)片段插裝至第一對(duì)象中的步驟包括：將防護(hù)片段插入到相應(yīng)的插裝位置，生成第二對(duì)象。

可選地，在根據(jù)本發(fā)明的方法中，插裝位置包括下列位置中的至少一個(gè)：第一對(duì)象初始化的位置、第一對(duì)象中的方法開始執(zhí)行和/或結(jié)束執(zhí)行的位置。

可選地，在根據(jù)本發(fā)明的方法中，事件信息包括用戶請(qǐng)求詳情，程序堆棧信息和漏洞描述。

可選地，在根據(jù)本發(fā)明的方法中，漏洞包括下列中的至少一個(gè)：Struts框架的操作類加載器漏洞、Session Cookie中未設(shè)置HttpOnly的漏洞、JavaSDK中parseDouble造成的拒絕服務(wù)漏洞Java反序列化攻擊漏洞、以及Struts框架遠(yuǎn)程代碼執(zhí)行漏洞。

可選地，在根據(jù)本發(fā)明的方法中，還包括步驟：將事件信息發(fā)送至所述安全服務(wù)器，以便存儲(chǔ)并生成報(bào)表供用戶查詢。

本發(fā)明的應(yīng)用漏洞修復(fù)方案通過檢測(cè)應(yīng)用是否依賴于存在漏洞的對(duì)象，并在存在漏洞的對(duì)象中自動(dòng)插裝防護(hù)片段，來快速修復(fù)漏洞，無需漫長的掃描修復(fù)過程，免去了用戶修改或者升級(jí)應(yīng)用依賴的對(duì)象的困難和面臨的風(fēng)險(xiǎn)。

同時(shí)，整個(gè)方案易于部署管理，只需簡(jiǎn)單配置，無需修改應(yīng)用的代碼，省去了開發(fā)者手動(dòng)添加代碼的麻煩。

附圖說明

為了實(shí)現(xiàn)上述以及相關(guān)目的，本文結(jié)合下面的描述和附圖來描述某些說明性方面，這些方面指示了可以實(shí)踐本文所公開的原理的各種方式，并且所有方面及其等效方面旨在落入所要求保護(hù)的主題的范圍內(nèi)。通過結(jié)合附圖閱讀下面的詳細(xì)描述，本公開的上述以及其它目的、特征和優(yōu)勢(shì)將變得更加明顯。遍及本公開，相同的附圖標(biāo)記通常指代相同的部件或元素。

圖1示出了根據(jù)本發(fā)明的一個(gè)示例性實(shí)施方式的應(yīng)用漏洞修復(fù)系統(tǒng)100的結(jié)構(gòu)框圖；

圖2示出了根據(jù)本發(fā)明的一個(gè)示例性實(shí)施方式的對(duì)應(yīng)用漏洞進(jìn)行修復(fù)的裝置110的結(jié)構(gòu)框圖；以及

圖3示出了根據(jù)本發(fā)明一個(gè)示例性實(shí)施方式的對(duì)應(yīng)用漏洞進(jìn)行修復(fù)的方法200的流程圖。

具體實(shí)施方式

下面將參照附圖更詳細(xì)地描述本公開的示例性實(shí)施例。雖然附圖中顯示了本公開的示例性實(shí)施例，然而應(yīng)當(dāng)理解，可以以各種形式實(shí)現(xiàn)本公開而不應(yīng)被這里闡述的實(shí)施例所限制。相反，提供這些實(shí)施例是為了能夠更透徹地理解本公開，并且能夠?qū)⒈竟_的范圍完整的傳達(dá)給本領(lǐng)域的技術(shù)人員。

圖1示出了根據(jù)本發(fā)明一個(gè)示例性實(shí)施方式的應(yīng)用漏洞修復(fù)系統(tǒng)100的結(jié)構(gòu)框圖。如圖1所示，應(yīng)用漏洞修復(fù)系統(tǒng)100可以包括對(duì)應(yīng)用漏洞進(jìn)行修復(fù)的裝置110和安全服務(wù)器120。其中，安全服務(wù)器120存儲(chǔ)有至少一個(gè)漏洞的至少一條漏洞信息，漏洞信息指示存在漏洞的對(duì)象以及該對(duì)象中漏洞位置所在的第一對(duì)象，并包括對(duì)應(yīng)的防護(hù)片段。

存在漏洞的對(duì)象和對(duì)象中漏洞位置所在的第一對(duì)象可以從網(wǎng)絡(luò)收集而獲得，對(duì)應(yīng)的防護(hù)片段可以通過分析程序的源代碼(開源軟件)和接口(商業(yè)軟件)而獲得。例如，漏洞及其漏洞信息至少可以包括下列中的至少一個(gè)：Struts框架的操作類加載器漏洞，發(fā)生在web框架Struts1和Struts2里；Session Cookie中未設(shè)置HttpOnly的漏洞，發(fā)生在web服務(wù)器tomcat6.0.20和WebSphere8.0中；JavaSDK中parseDouble造成的拒絕服務(wù)漏洞，發(fā)生在jre1.5.0_27及之前的版本中；Java反序列化攻擊漏洞，發(fā)生在庫Apache Commons Collections(3.x and 4.x)、Spring Beans/Core(4.x),and Groovy(2.3.x)中；Struts框架遠(yuǎn)程代碼執(zhí)行漏洞，發(fā)生在2.3.20版到2.3.28版。

對(duì)應(yīng)用漏洞進(jìn)行修復(fù)的裝置110駐留在應(yīng)用服務(wù)器中，應(yīng)用服務(wù)器可以通過網(wǎng)絡(luò)與安全服務(wù)器120連接。應(yīng)用服務(wù)器上存儲(chǔ)有一個(gè)或多個(gè)應(yīng)用，以便應(yīng)用服務(wù)器接收到用戶的訪問請(qǐng)求時(shí)調(diào)用相應(yīng)的應(yīng)用進(jìn)行處理。用戶可以通過web瀏覽器或應(yīng)用客戶端經(jīng)由網(wǎng)絡(luò)訪問應(yīng)用服務(wù)器。應(yīng)用服務(wù)器接收用戶的訪問請(qǐng)求，并為了響應(yīng)和處理該訪問請(qǐng)求，需要調(diào)用應(yīng)用服務(wù)器中的應(yīng)用。訪問請(qǐng)求可以是經(jīng)由http(s)協(xié)議而傳輸?shù)綉?yīng)用服務(wù)器120。

應(yīng)用服務(wù)器調(diào)用應(yīng)用處理用戶訪問請(qǐng)求，此時(shí)根據(jù)本發(fā)明的對(duì)應(yīng)用漏洞進(jìn)行修復(fù)的裝置110包含在應(yīng)用服務(wù)器中，可以工作在運(yùn)行時(shí)環(huán)境，深入應(yīng)用內(nèi)部，了解應(yīng)用的上下文，檢測(cè)應(yīng)用是否依賴于存在漏洞的對(duì)象，若是，使用防護(hù)片段注入技術(shù)來更精準(zhǔn)更迅速地修復(fù)漏洞，同時(shí)對(duì)應(yīng)用運(yùn)行的系統(tǒng)性能產(chǎn)生的影響也較小。

圖2示出了根據(jù)本發(fā)明一個(gè)示例性實(shí)施方式的對(duì)應(yīng)用漏洞進(jìn)行修復(fù)的裝置110的結(jié)構(gòu)框圖。如圖2所示，對(duì)應(yīng)用漏洞進(jìn)行修復(fù)的裝置110可以包括通信模塊111、掃描模塊112、監(jiān)控模塊113、插裝模塊114和處理引擎115。

通信模塊111向安全服務(wù)器120獲取其存儲(chǔ)的漏洞信息。漏洞信息指示了存在漏洞的對(duì)象，監(jiān)控模塊112與通信模塊111連接，可以對(duì)應(yīng)用進(jìn)行掃描，根據(jù)獲取的漏洞信息檢測(cè)應(yīng)用是否依賴于存在漏洞的對(duì)象。這里存在漏洞的對(duì)象一般是web容器、第三方框架、第三方的應(yīng)用服務(wù)器、庫和類。通常對(duì)于Java應(yīng)用，監(jiān)控模塊112會(huì)檢查Java的版本、第三方的庫和服務(wù)器的版本、以及特定的類名等等來確定其是否為存在漏洞的對(duì)象。

若掃描模塊112檢測(cè)到應(yīng)用依賴于存在漏洞的對(duì)象，與掃描模塊112連接的監(jiān)控模塊113從該漏洞的漏洞信息獲取漏洞位置所在的第一對(duì)象，即確定應(yīng)用中需要監(jiān)控的第一對(duì)象。該第一對(duì)象能夠被執(zhí)行以完成相應(yīng)邏輯，并可以包括下列中的至少一種：類、接口、以及其中定義的方法、參數(shù)、返回值和變量。

而后，在應(yīng)用服務(wù)器調(diào)用應(yīng)用處理用戶訪問請(qǐng)求時(shí)，監(jiān)控模塊113檢測(cè)加載應(yīng)用中第一對(duì)象的操作。通常，Java應(yīng)用在Java虛擬機(jī)(JVM)中執(zhí)行，具體來說，Java源代碼經(jīng)由Java編譯器轉(zhuǎn)化為Java字節(jié)碼，類加載器(classloader)將Java字節(jié)碼加載到Java虛擬機(jī)執(zhí)行，其中需要將Java字節(jié)碼加載至內(nèi)存。監(jiān)控模塊113可以檢測(cè)其中的第一對(duì)象是否將被加載至內(nèi)存。

當(dāng)監(jiān)控模塊113檢測(cè)到第一對(duì)象將被加載至內(nèi)存時(shí)，與監(jiān)控模塊113連接的插裝模塊114可以從漏洞信息獲取對(duì)應(yīng)的防護(hù)片段。該防護(hù)片段可以是一段防護(hù)代碼，能夠被執(zhí)行以完成對(duì)應(yīng)用漏洞的修復(fù)。

而后，插裝模塊114將獲取的防護(hù)片段插裝至將要被加載至內(nèi)存的第一對(duì)象中，以生成第二對(duì)象。對(duì)于Java應(yīng)用，該防護(hù)片段為字節(jié)碼片段，在Java源代碼經(jīng)由Java編譯器轉(zhuǎn)化為Java字節(jié)碼之后，插裝模塊114可以利用Java instrumentation技術(shù)將對(duì)應(yīng)的防護(hù)的Java字節(jié)碼片段插裝至應(yīng)用的Java字節(jié)碼之中。

具體地，上述漏洞信息還指示防護(hù)片段在第一對(duì)象中的插裝位置，則插裝模塊114可以將防護(hù)片段插入到漏洞信息指示的相應(yīng)的插裝位置，生成第二對(duì)象。其中，插裝位置可以包括下列位置中的至少一個(gè)：第一對(duì)象初始化的位置；第一對(duì)象中的方法開始執(zhí)行和/或結(jié)束執(zhí)行的位置。

接下來在要執(zhí)行第一對(duì)象時(shí)，與插裝模塊114連接的處理引擎115可以執(zhí)行第二對(duì)象以完成執(zhí)行第一對(duì)象時(shí)的相應(yīng)邏輯。例如，對(duì)于Java應(yīng)用，插裝模塊114在監(jiān)控模塊113檢測(cè)到類加載器要將對(duì)象A.class加載至內(nèi)存時(shí)，在A.class的字節(jié)碼中插入匹配的防護(hù)字節(jié)碼，生成A’.class。而后當(dāng)接收到請(qǐng)求要調(diào)用A.class時(shí)，Java虛擬機(jī)需要找到并執(zhí)行A’.class，由A’.class完成A.class的正常業(yè)務(wù)邏輯，并返回執(zhí)行結(jié)果。這里，A.class就是第一對(duì)象，A’.class為生成的第二對(duì)象。

可以理解地，處理引擎115在執(zhí)行生成的第二對(duì)象時(shí)，防護(hù)片段也會(huì)被一起被執(zhí)行。例如，第二對(duì)象的方法被執(zhí)行時(shí)，會(huì)在執(zhí)行第一對(duì)象的方法邏輯的之前或之后，執(zhí)行防護(hù)片段的方法。

其中，處理引擎115執(zhí)行第二對(duì)象中的防護(hù)片段，以便根據(jù)完成相應(yīng)邏輯的關(guān)鍵參數(shù)(例如輸入?yún)?shù)和/或輸出參數(shù))判斷是否存在利用漏洞的惡意事件，若是，攔截該惡意事件并記錄事件信息。其中事件信息可以包括用戶請(qǐng)求詳情，程序堆棧信息和漏洞描述。攔截動(dòng)作可以是將涉及到的輸入?yún)?shù)過濾或修改、跳過或修改有關(guān)方法的執(zhí)行等等。

例如，Struts框架遠(yuǎn)程代碼執(zhí)行漏洞發(fā)生在Apache Struts 2.3.20版到2.3.28版，通?？梢岳迷撀┒磥磉h(yuǎn)程執(zhí)行代碼進(jìn)行攻擊。具體地，該漏洞可以在Struts的動(dòng)態(tài)方法調(diào)用(Dynamic Method Invocation)被開啟的情況下，利用OGNL表達(dá)式執(zhí)行惡意程序。

因此，其漏洞信息可以指示存在該漏洞的對(duì)象為：Apache Struts 2.3.20版到2.3.28版，漏洞位置所在的第一對(duì)象為：Struts代碼中具體執(zhí)行ONGL表達(dá)式的類和方法，即org.apache.struts2.dispatcher.mapper.ActionMapping類中的setMethod(String method)方法。當(dāng)監(jiān)控模塊114檢測(cè)到該漏洞所在的類和方法被調(diào)用時(shí)，處理引擎115可以通過執(zhí)行插裝的防護(hù)片段，利用正則表達(dá)式檢查輸入?yún)?shù)method是否合法。如果判斷輸入?yún)?shù)method不匹配正則表達(dá)式，則判定是惡意方法調(diào)用、存在利用漏洞的惡意事件，攔截該惡意事件并記錄事件信息。防護(hù)片段的偽代碼可以如下：

確定存在惡意事件并記錄事件信息后，處理引擎115還可以通過通信模塊111將事件信息發(fā)送至安全服務(wù)器120，安全服務(wù)器120接收事件信息后，將其存儲(chǔ)，并根據(jù)事件信息生成報(bào)表供用戶查詢。

綜上，通過檢測(cè)應(yīng)用是否依賴于存在漏洞的對(duì)象，并在存在漏洞的對(duì)象中自動(dòng)插裝防護(hù)片段，來快速修復(fù)漏洞，無需漫長的掃描修復(fù)過程，免去了用戶修改或者升級(jí)應(yīng)用依賴的對(duì)象的困難和面臨的風(fēng)險(xiǎn)。

同時(shí)，整個(gè)方案易于部署管理，只需簡(jiǎn)單配置，無需修改應(yīng)用的代碼，省去了開發(fā)者手動(dòng)添加代碼的麻煩。

圖3示出了根據(jù)本發(fā)明一個(gè)示例性實(shí)施方式的對(duì)應(yīng)用漏洞進(jìn)行修復(fù)的方法200的流程圖。該方法200適于在應(yīng)用服務(wù)器中執(zhí)行，應(yīng)用服務(wù)器與安全服務(wù)器120通過網(wǎng)絡(luò)連接，安全服務(wù)器120存儲(chǔ)有至少一個(gè)漏洞的至少一條漏洞信息，漏洞信息指示存在漏洞的對(duì)象以及該對(duì)象中漏洞位置所在的第一對(duì)象，并包括對(duì)應(yīng)的防護(hù)片段。其中，漏洞及其漏洞信息可以包括下列中的至少一個(gè)：Struts框架的操作類加載器漏洞，發(fā)生在web框架Struts1和Struts2里；Session Cookie中未設(shè)置HttpOnly的漏洞，發(fā)生在web服務(wù)器tomcat6.0.20和WebSphere8.0中；JavaSDK中parseDouble造成的拒絕服務(wù)漏洞，發(fā)生在jre1.5.0_27及之前的版本中；Java反序列化攻擊漏洞，發(fā)生在庫Apache Commons Collections(3.x and 4.x)、Spring Beans/Core(4.x),and Groovy(2.3.x)中；Struts框架遠(yuǎn)程代碼執(zhí)行漏洞，發(fā)生在2.3.20版到2.3.28版。

如圖3所示，該方法200始于步驟S210，在步驟S210中，向安全服務(wù)器120獲取漏洞信息。而后在步驟S220中，根據(jù)漏洞信息檢測(cè)應(yīng)用是否依賴于存在漏洞的對(duì)象。存在漏洞的對(duì)象可以包括下列中的至少一種：存在漏洞的web容器、第三方框架、應(yīng)用服務(wù)器、庫和類。

若檢測(cè)到應(yīng)用依賴于存在漏洞的對(duì)象，則在步驟S230中，從該漏洞的漏洞信息獲取漏洞位置所在的第一對(duì)象，該第一對(duì)象能夠被執(zhí)行以完成相應(yīng)邏輯。其中，第一對(duì)象可以包括下列中的至少一種：類、接口、以及其中定義的方法、參數(shù)、返回值和變量。

接著在步驟S240中，檢測(cè)加載第一對(duì)象的操作。當(dāng)檢測(cè)到第一對(duì)象將被加載至內(nèi)存時(shí)，在步驟S250中，從漏洞信息中獲取與對(duì)應(yīng)的防護(hù)片段。

在步驟S260中，將獲取的防護(hù)片段插裝至第一對(duì)象中，以生成第二對(duì)象。具體地，漏洞信息還指示防護(hù)片段在第一對(duì)象中的插裝位置，因此步驟S260還可以包括：將防護(hù)片段插入到相應(yīng)的插裝位置，生成第二對(duì)象。插裝位置可以包括下列位置中的至少一個(gè)：第一對(duì)象初始化的位置、第一對(duì)象中的方法開始執(zhí)行和/或結(jié)束執(zhí)行的位置。

生成第二對(duì)象之后，在步驟S270中，在要執(zhí)行第一對(duì)象時(shí)，執(zhí)行第二對(duì)象以完成執(zhí)行第一對(duì)象時(shí)的相應(yīng)邏輯，例如，第二對(duì)象的方法被執(zhí)行時(shí)，會(huì)在執(zhí)行第一對(duì)象的方法邏輯的之前或之后，執(zhí)行防護(hù)片段的方法。

其中，執(zhí)行第二對(duì)象中的防護(hù)片段，以便根據(jù)完成相應(yīng)邏輯的關(guān)鍵參數(shù)判斷是否存在利用漏洞的惡意事件，若是，攔截該惡意事件并記錄事件信息。其中，事件信息包括用戶請(qǐng)求詳情，程序堆棧信息和漏洞描述。

最后，根據(jù)本發(fā)明的一個(gè)實(shí)施方式，方法200還可以包括步驟：將事件信息發(fā)送至安全服務(wù)器120，以便存儲(chǔ)并生成報(bào)表供用戶查詢。

以上在結(jié)合圖1～圖2說明應(yīng)用漏洞修復(fù)系統(tǒng)100的原理的具體描述中已經(jīng)對(duì)各步驟中的相應(yīng)處理進(jìn)行了詳細(xì)解釋，這里不再對(duì)重復(fù)內(nèi)容進(jìn)行贅述。

應(yīng)當(dāng)理解，為了精簡(jiǎn)本公開并幫助理解各個(gè)發(fā)明方面中的一個(gè)或多個(gè)，在上面對(duì)本發(fā)明的示例性實(shí)施例的描述中，本發(fā)明的各個(gè)特征有時(shí)被一起分組到單個(gè)實(shí)施例、圖、或者對(duì)其的描述中。然而，并不應(yīng)將該公開的方法解釋成反映如下意圖：即所要求保護(hù)的本發(fā)明要求比在每個(gè)權(quán)利要求中所明確記載的特征更多特征。更確切地說，如下面的權(quán)利要求書所反映的那樣，發(fā)明方面在于少于前面公開的單個(gè)實(shí)施例的所有特征。因此，遵循具體實(shí)施方式的權(quán)利要求書由此明確地并入該具體實(shí)施方式，其中每個(gè)權(quán)利要求本身都作為本發(fā)明的單獨(dú)實(shí)施例。

本領(lǐng)域那些技術(shù)人員應(yīng)當(dāng)理解在本文所公開的示例中的設(shè)備的模塊或單元或組件可以布置在如該實(shí)施例中所描述的設(shè)備中，或者可替換地可以定位在與該示例中的設(shè)備不同的一個(gè)或多個(gè)設(shè)備中。前述示例中的模塊可以組合為一個(gè)模塊或者此外可以分成多個(gè)子模塊。

本領(lǐng)域那些技術(shù)人員可以理解，可以對(duì)實(shí)施例中的設(shè)備中的模塊進(jìn)行自適應(yīng)性地改變并且把它們?cè)O(shè)置在與該實(shí)施例不同的一個(gè)或多個(gè)設(shè)備中?？梢园褜?shí)施例中的模塊或單元或組件組合成一個(gè)模塊或單元或組件，以及此外可以把它們分成多個(gè)子模塊或子單元或子組件。除了這樣的特征和/或過程或者單元中的至少一些是相互排斥之外，可以采用任何組合對(duì)本說明書(包括伴隨的權(quán)利要求、摘要和附圖)中公開的所有特征以及如此公開的任何方法或者設(shè)備的所有過程或單元進(jìn)行組合。除非另外明確陳述，本說明書(包括伴隨的權(quán)利要求、摘要和附圖)中公開的每個(gè)特征可以由提供相同、等同或相似目的的替代特征來代替。

此外，本領(lǐng)域的技術(shù)人員能夠理解，盡管在此所述的一些實(shí)施例包括其它實(shí)施例中所包括的某些特征而不是其它特征，但是不同實(shí)施例的特征的組合意味著處于本發(fā)明的范圍之內(nèi)并且形成不同的實(shí)施例。例如，在下面的權(quán)利要求書中，所要求保護(hù)的實(shí)施例的任意之一都可以以任意的組合方式來使用。

此外，所述實(shí)施例中的一些在此被描述成可以由計(jì)算機(jī)系統(tǒng)的處理器或者由執(zhí)行所述功能的其它裝置實(shí)施的方法或方法元素的組合。因此，具有用于實(shí)施所述方法或方法元素的必要指令的處理器形成用于實(shí)施該方法或方法元素的裝置。此外，裝置實(shí)施例的在此所述的元素是如下裝置的例子：該裝置用于實(shí)施由為了實(shí)施該發(fā)明的目的的元素所執(zhí)行的功能。

如在此所使用的那樣，除非另行規(guī)定，使用序數(shù)詞“第一”、“第二”、“第三”等等來描述普通對(duì)象僅僅表示涉及類似對(duì)象的不同實(shí)例，并且并不意圖暗示這樣被描述的對(duì)象必須具有時(shí)間上、空間上、排序方面或者以任意其它方式的給定順序。

本發(fā)明還包括：A6、如A1-5中任一項(xiàng)所述的裝置，其中，所述事件信息包括用戶請(qǐng)求詳情，程序堆棧信息和漏洞描述。A7、如A6所述的裝置，其中，所述漏洞包括下列中的至少一個(gè)：Struts框架的操作類加載器漏洞、Session Cookie中未設(shè)置HttpOnly的漏洞、JavaSDK中parseDouble造成的拒絕服務(wù)漏洞Java反序列化攻擊漏洞、以及Struts框架遠(yuǎn)程代碼執(zhí)行漏洞。A8、如A1-7中任一項(xiàng)所述的裝置，其中，所述通信模塊還適于將所述事件信息發(fā)送至所述安全服務(wù)器，以便存儲(chǔ)并生成報(bào)表供用戶查詢。

B14、如B13所述的方法，其中，所述插裝位置包括下列位置中的至少一個(gè)：第一對(duì)象初始化的位置、第一對(duì)象中的方法開始執(zhí)行和/或結(jié)束執(zhí)行的位置。B15、如B10-14中任一項(xiàng)所述的方法，其中，所述事件信息包括用戶請(qǐng)求詳情，程序堆棧信息和漏洞描述。B16、如B15所述的方法，其中，所述漏洞包括下列中的至少一個(gè)：Struts框架的操作類加載器漏洞、Session Cookie中未設(shè)置HttpOnly的漏洞、JavaSDK中parseDouble造成的拒絕服務(wù)漏洞Java反序列化攻擊漏洞、以及Struts框架遠(yuǎn)程代碼執(zhí)行漏洞。B17、如B10-16中任一項(xiàng)所述的方法，其中，還包括步驟：將所述事件信息發(fā)送至所述安全服務(wù)器，以便存儲(chǔ)并生成報(bào)表供用戶查詢。

盡管根據(jù)有限數(shù)量的實(shí)施例描述了本發(fā)明，但是受益于上面的描述，本技術(shù)領(lǐng)域內(nèi)的技術(shù)人員明白，在由此描述的本發(fā)明的范圍內(nèi)，可以設(shè)想其它實(shí)施例。此外，應(yīng)當(dāng)注意，本說明書中使用的語言主要是為了可讀性和教導(dǎo)的目的而選擇的，而不是為了解釋或者限定本發(fā)明的主題而選擇的。因此，在不偏離所附權(quán)利要求書的范圍和精神的情況下，對(duì)于本技術(shù)領(lǐng)域的普通技術(shù)人員來說許多修改和變更都是顯而易見的。對(duì)于本發(fā)明的范圍，對(duì)本發(fā)明所做的公開是說明性的，而非限制性的，本發(fā)明的范圍由所附權(quán)利要求書限定。