javaWeb安全漏洞及處理方式
成都創(chuàng)新互聯(lián)主營金鳳網(wǎng)站建設(shè)的網(wǎng)絡(luò)公司,主營網(wǎng)站建設(shè)方案,App定制開發(fā),金鳳h5小程序設(shè)計搭建,金鳳網(wǎng)站營銷推廣歡迎金鳳等地區(qū)企業(yè)咨詢
關(guān)注
轉(zhuǎn)載自:
1、SQL注入攻擊
SQL注入攻擊就是通過把SQL命令插入到Web表單提交或輸入域名或頁面請求的查詢字符串,最終達到欺騙服務(wù)器執(zhí)行惡意的SQL命令。具體來說,它是利用現(xiàn)有應(yīng)用程序,將(惡意)的SQL命令注入到后臺數(shù)據(jù)庫引擎執(zhí)行的能力,它可以通過在Web表單中輸入(惡意)SQL語句得到一個存在安全漏洞的網(wǎng)站上的數(shù)據(jù)庫,而不是按照設(shè)計者意圖去執(zhí)行SQL語句。
隨著B/S框架結(jié)構(gòu)在系統(tǒng)開發(fā)中的廣泛應(yīng)用,惡意攻擊者利用SQL命令在Web表單中輸入合法的字符或查詢字符串來欺騙服務(wù)器執(zhí)行SQL命令。當注入攻擊得逞后,Web程序?qū)⑿孤洞罅坑脩綦[私數(shù)據(jù)和數(shù)據(jù)庫中數(shù)據(jù)結(jié)構(gòu)。攻擊者能夠獲得系統(tǒng)較高的訪問權(quán)限,進行破壞操作。
SQL注入可以分為平臺層注入和代碼層注入。前者由不安全的數(shù)據(jù)庫配置或數(shù)據(jù)庫平臺的漏洞所致;后者主要是由于程序員對輸入未進行細致地過濾,從而執(zhí)行了非法的數(shù)據(jù)查詢?;诖?,SQL注入的產(chǎn)生原因通常表現(xiàn)在以下幾方面:
1)不當?shù)念愋吞幚?
2)不安全的數(shù)據(jù)庫配置;
3)不合理的查詢集處理;
4)不當?shù)腻e誤處理;
5)轉(zhuǎn)義字符處理不合適;
6) 多個提交處理不當。
解決方法:
數(shù)據(jù)庫安全通信包括SQL注入攻擊的防范、安全設(shè)置、異常信息處理三個方面。
1.服務(wù)端Filter對訪問者輸入的字符進行過濾檢驗,但是攻擊者經(jīng)常把危險字符潛藏在用戶輸入的有效字符中完 成過濾檢驗。
2.通過正則表達式對頁面的文本框輸入的數(shù)據(jù)進行限制可以減少過濾檢驗存在的漏洞。
3.使用prepareStatment預編譯sql語句
2、XSS跨站腳本攻擊
跨站腳本(Cross-site scripting,簡稱XSS),是一種迫使Web站點回顯可執(zhí)行代碼的攻擊技術(shù),而這些可執(zhí)行代碼由攻擊者提供、最終為用戶瀏覽器加載。不同于大多數(shù)攻擊(一般只涉及攻擊者和受害者),XSS涉及到三方,即攻擊者、客戶端與網(wǎng)站。XSS的攻擊目標是為了盜取客戶端的cookie或者其他網(wǎng)站用于識別客戶端身份的敏感信息。獲取到合法用戶的信息后,攻擊者甚至可以假冒最終用戶與網(wǎng)站進行交互。
XSS 屬于被動式的攻擊。攻擊者先構(gòu)造一個跨站頁面,利用SCRIPT、IMG、IFRAME等各種方式使得用戶瀏覽這個頁面時,觸發(fā)對被攻擊站點的HTTP 請求。此時,如果被攻擊者如果已經(jīng)在被攻擊站點登錄,就會持有該站點cookie。這樣該站點會認為被攻擊者發(fā)起了一個HTTP請求。而實際上這個請求是在被攻擊者不知情情況下發(fā)起的,由此攻擊者在一定程度上達到了冒充被攻擊者的目的。精心的構(gòu)造這個攻擊請求,可以達到冒充發(fā)文,奪取權(quán)限等多個攻擊目的。在常見的攻擊實例中,這個請求是通過script 來發(fā)起的,因此被稱為Cross Site Script。
XSS漏洞成因是由于動態(tài)網(wǎng)頁的Web應(yīng)用對用戶提交請求參數(shù)未做充分的檢查過濾,允許用戶在提交的數(shù)據(jù)中摻入HTML代碼(最主要的是“”、“”),然后未加編碼地輸出到第三方用戶的瀏覽器,這些攻擊者惡意提交代碼會被受害用戶的瀏覽器解釋執(zhí)行。
分為三種類型:
1)反射型(數(shù)據(jù)流向:瀏覽器 -后端 - 瀏覽器)
反射型XSS腳本攻擊即如我們上面所提到的XSS跨站腳本攻擊方式,該類型只是簡單地將用戶輸入的數(shù)據(jù)直接或未經(jīng)過完善的安全過濾就在瀏覽器中進行輸出,導致輸出的數(shù)據(jù)中存在可被瀏覽器執(zhí)行的代碼數(shù)據(jù)。由于此種類型的跨站代碼存在于URL中,所以黑客通常需要通過誘騙或加密變形等方式,將存在惡意代碼的鏈接發(fā)給用戶,只有用戶點擊以后才能使得攻擊成功實施。
2)存儲型(數(shù)據(jù)流向是:瀏覽器 -后端 - 數(shù)據(jù)庫 - 后端- 瀏覽器)
存儲型XSS腳本攻擊是指Web應(yīng)用程序會將用戶輸入的數(shù)據(jù)信息保存在服務(wù)端的數(shù)據(jù)庫或其他文件形式中,網(wǎng)頁進行數(shù)據(jù)查詢展示時,會從數(shù)據(jù)庫中獲取數(shù)據(jù)內(nèi)容,并將數(shù)據(jù)內(nèi)容在網(wǎng)頁中進行輸出展示,因此存儲型XSS具有較強的穩(wěn)定性。
存儲型XSS腳本攻擊最為常見的場景就是在博客或新聞發(fā)布系統(tǒng)中,黑客將包含有惡意代碼的數(shù)據(jù)信息直接寫入文章或文章評論中,所有瀏覽文章或評論的用戶,都會在他們客戶端瀏覽器環(huán)境中執(zhí)行插入的惡意代碼。
3)基于DOM(數(shù)據(jù)流向是:URL--瀏覽器 )
基于DOM的XSS跨站腳本攻擊是通過修改頁面DOM節(jié)點數(shù)據(jù)信息而形成的XSS跨站腳本攻擊。不同于反射型XSS和存儲型XSS,基于DOM的XSS跨站腳本攻擊往往需要針對具體的javascript DOM代碼進行分析,并根據(jù)實際情況進行XSS跨站腳本攻擊的利用。
解決方法:
1).輸入過濾。對用戶的所有輸入數(shù)據(jù)進行檢測,比如過濾其中的“”、“”、“/”等可能導致腳本注入的特殊字符,或者過濾“script”、“javascript”等腳本關(guān)鍵字,或者對輸入數(shù)據(jù)的長度進行限制等等。同時,我們也要考慮用戶可能繞開ASCII碼,使用十六進制編碼來輸入腳本。因此,對用戶輸入的十六進制編碼,我們也要進行相應(yīng)的過濾。只要能夠嚴格檢測每一處交互點,保證對所有用戶可能的輸入都進行檢測和XSS過濾,就能夠有效地阻止XSS攻擊。
2).輸出編碼。通過前面對XSS攻擊的分析,我們可以看到,之所以會產(chǎn)生XSS攻擊,就是因為Web應(yīng)用程序?qū)⒂脩舻妮斎胫苯忧度氲侥硞€頁面當中,作為該頁面的HTML代碼的一部分。因此,當Web應(yīng)用程序?qū)⒂脩舻妮斎霐?shù)據(jù)輸出到目標頁面中時,只要用HtmlEncoder等工具先對這些數(shù)據(jù)進行編碼,然后再輸出到目標頁面中。這樣,如果用戶輸入一些HTML的腳本,也會被當成普通的文字,而不會成為目標頁面HTML代碼的一部分得到執(zhí)行.
3、CSRF跨站請求偽造漏洞防護
CSRF是CrossSite Request Forgery的縮寫,乍一看和XSS差不多的樣子,但是其原理正好相反,XSS是利用合法用戶獲取其信息,而CSRF是偽造成合法用戶發(fā)起請求。
字面理解意思就是在別的站點偽造了一個請求。專業(yè)術(shù)語來說就是在受害者訪問一個網(wǎng)站時,其 Cookie 還沒有過期的情況下,攻擊者偽造一個鏈接地址發(fā)送受害者并欺騙讓其點擊,從而形成 CSRF 攻擊。
根據(jù)HTTP協(xié)議,在HTTP頭中有一個字段叫Referer,它記錄了該HTTP請求的來源地址。在通常情況下,訪問一個安全受限頁面的請求必須來自于同一個網(wǎng)站。
解決方案:
配置FILTER攔截用戶所有請求(POST/GET),對用戶請求Referer頭URL進行合法性校驗。
4、URL鏈接注入漏洞防護
鏈接注入是修改站點內(nèi)容的行為,其方式為將外部站點的 URL 嵌入其中,或?qū)⒂幸资芄舻恼军c中的腳本 的 URL 嵌入其中。將URL 嵌入易受攻擊的站點中,攻擊者便能夠以它為平臺來啟動對其他站點的攻擊,以及攻擊這個易受攻擊的站點本身。
解決方案:
1,二次驗證,進行重要敏感操作時,要求用戶進行二次驗證。
2,驗證碼,進行重要敏感操作時,加入驗證碼。
3,驗證 HTTP 的 Referer 字段。
4,請求地址中添加 Token 并驗證。
5,HTTP 頭中自定義屬性并驗證。
5、會話COOKIE中缺少HttpOnly防護
會話cookie中缺少HttpOnly屬性會導致攻擊者可以通過程序(JS腳本、Applet等)獲取到用戶的cookie信息,造成用戶cookie信息泄露,增加攻擊者的跨站腳本攻擊威脅。
HttpOnly是微軟對cookie做的擴展,該值指定cookie是否可通過客戶端腳本訪問。Microsoft Internet Explorer 版本 6 Service Pack 1 和更高版本支持cookie屬性HttpOnly。
如果在Cookie中沒有設(shè)置HttpOnly屬性為true,可能導致Cookie被竊取。竊取的Cookie可以包含標識站點用戶的敏感信息。
如果在Cookie中設(shè)置HttpOnly屬性為true,兼容瀏覽器接收到HttpOnly cookie,那么客戶端通過程序(JS腳本、Applet等)將無法讀取到Cookie信息,這將有助于緩解跨站點腳本威脅。
解決方案:
配置filter攔截器,將服務(wù)器端返回請求,向所有會話cookie中添加“HttpOnly”屬性。
示例代碼:
HttpServletResponseresponse=(HttpServletResponse)paramServletResponse;
response.setHeader("SET-COOKIE","JSESSIONID=" + sessionid + "; HttpOnly");
6、點擊劫持漏洞(Clickjacking)防護
點擊劫持是一種視覺上的欺騙手段,攻擊者使用一個透明的、不可見的iframe,覆蓋在一個網(wǎng)頁上,然后誘使用戶在該網(wǎng)頁上進行操作,此時用戶在不知情的情況下點擊了透明的iframe頁面。通過調(diào)整iframe頁面的位置,可以誘使用戶恰好點擊在iframe頁面的一些功能性按鈕上。
解決方案:
配置FILTER攔截器,在服務(wù)器端返回請求中,使用一個HTTP頭“X-Frame-Options”值為SAMEORIGIN-同源策略 ,則frame頁面的地址只能為同源域名下面的頁面,防止點擊劫持漏洞發(fā)生。
示例代碼:
HttpServletResponseresponse=(HttpServletResponse)paramServletResponse;
response.addHeader("x-frame-options","SAMEORIGIN");
7、HTTP host 頭攻擊漏洞
使用HTTP代理工具,可以篡改HTTP報文頭部中HOST字段時,該值可被注入惡意代碼。因為需要控制客戶端的輸入,故該漏洞較難利用。
解決方案:
配置FILTER攔截器,對請求輸入HOST頭信息進行信息安全性校驗,防止HOST頭信息被惡意篡改利用。
示例代碼:
HttpServletRequest request =(HttpServletRequest)servletRequest;
//主機ip和端口 或 域名和端口
String myhosts = request.getHeader("host");
if(!StringUtils.equals(myhosts, "xx.xx.xxx.xxx:xxxx")
!StringUtils.equals(myhosts, "xx.xx.xxx.xxx:xxxx")
!StringUtils.equals(myhosts,"xx.xx.xxx.xxx:xxxx")StringUtils.equals(myhosts,"xx.xx.xxx.xxx")
!StringUtils.equals(myhosts,"xx.xx.xxx.xxx") !StringUtils.equals(myhosts,"xx.xx.xxx.xxx" ){
logger.error("======訪問host非法,已攔截======");
response.sendRedirect(request.getContextPath() + "/login.jsp");
return;
}
8、越權(quán)訪問漏洞防護
越權(quán)訪問(Broken Access Control,簡稱BAC)是Web應(yīng)用程序中一種常見的漏洞,分為垂直越權(quán)訪問和水平越權(quán)訪問。垂直越權(quán)是指不同用戶級別之間的越權(quán),如普通用戶執(zhí)行管理員用戶的權(quán)限。水平越權(quán)是指相同級別用戶之間的越權(quán)操作。
Web應(yīng)用程序如果存在越權(quán)訪問漏洞,可能導致以下危害:
1)導致任意用戶敏感信息泄露;
2)導致任意用戶信息被惡意修改或刪除。
解決方案:
配置FILTER攔截器,對請求所有URL進行攔截,對于需要進行授權(quán)的URL進行權(quán)限校驗,防止用戶越權(quán)訪問系統(tǒng)資源。
9.弱口令漏洞
解決方案:最好使用至少6位的數(shù)字、字母及特殊字符組合作為密碼。數(shù)據(jù)庫不要存儲明文密碼,應(yīng)存儲MD5加密后的密文,由于目前普通的MD5加密已經(jīng)可以被破解,最好可以多重MD5加密,或者多種加密方式疊加組合。
10.JSP頁面拋出的異常可能暴露程序信息。
有經(jīng)驗的入侵者,可以從JSP程序的異常中獲取很多信息,比如程序的部分架構(gòu)、程序的物理路徑、SQL注入爆出來的信息等。
解決方案:自定義一個Exception,將異常信息包裝起來不要拋到頁面上。
11.本地緩存漏洞
合法用戶“注銷”后,在未關(guān)閉瀏覽器的情況下,點擊瀏覽器“后退”按鈕,可從本地頁面緩存中讀取數(shù)據(jù),繞過了服務(wù)端filter過濾。
解決方案:配置filter對存放敏感信息的頁面限制頁面緩存。如:
httpResponse.setHeader("Cache-Control","no-cache");
httpResponse.setHeader("Cache-Control","no-store");
httpResponse.setDateHeader("Expires",0);
httpResponse.setHeader("Pragma","no-cache");
12.文件上傳漏洞。
前臺僅使用JS對文件后綴做了過濾,這只能針對普通的用戶,而惡意攻擊者完全可以修改表單去掉JS校驗。
13.Java WEB容器默認配置漏洞。
如TOMCAT后臺管理漏洞,默認用戶名及密碼登錄后可直接上傳war文件獲取webshell。
解決方案:最好刪除,如需要使用它來管理維護,可更改其默認路徑,口令及密碼。
漏洞名稱: Apache Log4j任意代碼執(zhí)行漏洞
漏洞性質(zhì): 任意代碼執(zhí)行
漏洞描述:
Apache Log4j 是 Apache 的一個開源項目,Apache Log4j2是一個基于Java的日志記錄工具。該工具重寫了Log4j框架,并且引入了大量豐富的特性。我們可以控制日志信息輸送的目的地為控制臺、文件、GUI組件等,通過定義每一條日志信息的級別,能夠更加細致地控制日志的生成過程。該日志框架被大量用于業(yè)務(wù)系統(tǒng)開發(fā),用來記錄日志信息。log4j2是全球使用廣泛的java日志框架,同時該漏洞還影響很多全球使用量的Top序列的通用開源組件,例如 Apache Struts2、Apache Solr、Apache Druid、Apache Flink等。
漏洞危害:
Log4j-2中存在JNDI注入漏洞,當程序?qū)⒂脩糨斎氲臄?shù)據(jù)被日志記錄時,即可觸發(fā)此漏洞,成功利用此漏洞可以在目標服務(wù)器上執(zhí)行任意代碼,可能對用戶造成不可挽回的損失。
危害等級:嚴重
漏洞復現(xiàn):
影響版本:
Apache Log4j 2.x = 2.14.1
臨時修復方案:
1.修改jvm參數(shù) -Dlog4j2.formatMsgNoLookups=true
2.修改配置
log4j2.formatMsgNoLookups=True
3.將系統(tǒng)環(huán)境變量
FORMAT_MESSAGES_PATTERN_DISABLE_LOOKUPS 設(shè)置為 true
修復建議:
1、廠商已發(fā)布升級修復漏洞,用戶請盡快更新至安全版本:log4j-2.15.0-rc1
下載鏈接:
2、升級已知受影響的應(yīng)用及組件,如srping-boot-strater-log4j2/Apache Solr/Apache Flink/Apache Druid
3、手動替換 log4j2 版本為 2.15.1-SNAPSHOT
log4j-core:
log4j-api:
log4j-slf4j18-impl:
4、做好資產(chǎn)自查以及預防工作,以免遭受黑客攻擊
你好朋友,病毒在變異 系統(tǒng)會有漏洞 病毒木馬就會乘虛而入 漏洞就是系統(tǒng)的弊端、弱點。容易被攻擊、被攻擊者掌握你家電腦的主動權(quán)。360安全衛(wèi)士他有智能修復功能如果它提示系統(tǒng)漏洞要修復,那就是應(yīng)該要修復的,有的漏洞不用修復他就會忽所以不必在意!這樣才不會影響系統(tǒng)的運行.希望我的回答對你有幫助。
漏洞描述:
CVE-2013-225. Struts2 是第二代基于Model-View-Controller (MVC)模型的java企業(yè)級web應(yīng)用框架。它是WebWork和Struts社區(qū)合并后的產(chǎn)物
Apache Struts2的action:、redirect:和redirectAction:前綴參數(shù)在實現(xiàn)其功能的過程中使用了Ognl表達式,并將用戶通過URL提交的內(nèi)容拼接入Ognl表達式中,從而造成攻擊者可以通過構(gòu)造惡意URL來執(zhí)行任意Java代碼,進而可執(zhí)行任意命令
redirect:和redirectAction:此兩項前綴為Struts默認開啟功能,目前Struts 2.3.15.1以下版本均存在此漏洞
目前Apache Struts2已經(jīng)在2.3.15.1中修補了這一漏洞。強烈建議Apache Struts2用戶檢查您是否受此問題影響,并盡快升級到最新版本
參考
1.
測試方法:
@Sebug.net dis 本站提供程序(方法)可能帶有攻擊性,僅供安全研究與教學之用,風險自負!
由于Apache Struts2 在最新修補版本2.3.15.1中已經(jīng)禁用了重定向參數(shù),因此只要重定向功能仍然有效,則說明受此漏洞影響:
如果頁面重定向到,則表明當前系統(tǒng)受此漏洞影響。
驗證表達式解析和命令執(zhí)行:
{3*4}
{(new+java.lang.ProcessBuilder(new+java.lang.String[]{'command','goes','here'})).start()}`
Sebug安全建議:
廠商狀態(tài):
廠商已經(jīng)發(fā)布Apache Struts 2.3.15.1以修復此安全漏洞,建議Struts用戶及時升級到最新版本。
廠商安全公告:S2-01. 鏈接:
軟件升級頁面:
目前存在漏洞的公司
烏云上,已經(jīng)發(fā)布了快60個struts的這個漏洞問題,包括騰訊,百度,網(wǎng)易,京東等國內(nèi)各大互聯(lián)網(wǎng)公司。()
解決辦法:
升級到Struts 2.3.15.1(強烈建議)
使用ServletFilter來過濾有問題的參數(shù)(臨時替換方案)
參考資料:
這次struts爆出來的漏洞,一大片的網(wǎng)站受的影響,影響最嚴重的就是電商了.對于struts的漏洞,曾經(jīng)也寫過struts2代碼執(zhí)行漏洞,struts2自從使用OGNL表達式的方式后,經(jīng)常就會報出一些可怕的漏洞出來,建議那些還是struts的童鞋們,學習一些其他的框架吧!比如,spring mvc,簡單,好用,高效!
Spring框架曝安全漏洞,你如何評價這個漏洞?下面就我們來針對這個問題進行一番探討,希望這些內(nèi)容能夠幫到有需要的朋友們。
繼Log4j2以后,聽到Java再度遭受漏洞進攻,這一次,好像狀況也更為嚴重,由于遭受危害的是Java服務(wù)平臺的開源系統(tǒng)全棧應(yīng)用軟件框架和控制反轉(zhuǎn)器皿完成——Spring家族,并且網(wǎng)傳漏洞還不僅一個。一直以來,Spring是程序編寫開發(fā)設(shè)計的首選技術(shù)性之一,先前一位名叫BogdanN.的全棧開發(fā)者乃至點評道:“學習培訓Java、學習Spring框架,你永遠都不容易下崗。”
顯而易見,假如Spring城門失火,Java必然殃及。但是,SpringRCE漏洞在互聯(lián)網(wǎng)上炒了二天,盡管有許多安全圈工作人員陸續(xù)發(fā)朋友圈,但大量的或是表明了僅僅聽到,這也不免令人懷疑,是真有漏洞,或是虛驚一場?3月26日,據(jù)網(wǎng)絡(luò)信息安全網(wǎng)址CyberKendra報導,SpringCloudFunction官方網(wǎng)功能測試曝出了SpringCloudFunctionSPEL(SpringExpressionLanguage)關(guān)系式引入漏洞,網(wǎng)絡(luò)黑客可使用該漏洞引入SPEL表達式來開啟遠程連接命令實行。
最初,科學研究工作人員在剖析SpringCloud函數(shù)公式的main支系時,發(fā)覺有開發(fā)者向在其中加上了SimpleEvaluationContext類。還采用了isViaHeadervariable做為標示,在分析spring.cloud.function.routing-expression以前分辨的值源自HTTPheader。現(xiàn)階段,SpringCloudFunction被很多互聯(lián)網(wǎng)巨頭運用于設(shè)備中,包含AWSLambda、Azure、GoogleCloudFunctions、ApacheOpenWhisk及其很多Serverless服務(wù)提供商。
依據(jù)官方網(wǎng)文本文檔,SpringCloudFunction是根據(jù)SpringBoot的函數(shù)計算框架,它可以:根據(jù)函數(shù)公式推動業(yè)務(wù)邏輯的完成。將業(yè)務(wù)邏輯的開發(fā)設(shè)計生命期與一切特殊的運作時總體目標分離出來,便于應(yīng)用同樣的編碼可以做為Web端點、流處理器數(shù)量或每日任務(wù)運作。適用跨Serverless服務(wù)提供商的統(tǒng)一程序編寫實體模型,具有單獨運作(當?shù)鼗蛟赑aaS中)的工作能力。在Serverless上給予程序流程上開啟SpringBoot作用(全自動配備、依賴注入、指標值)。
簡單點來說,SpringCloudFunction根據(jù)抽象化傳送關(guān)鍵點和基礎(chǔ)設(shè)施建設(shè),為開發(fā)者保存了解的開發(fā)環(huán)境和開發(fā)流程,讓開發(fā)者致力于完成業(yè)務(wù)邏輯,進而提升開發(fā)設(shè)計高效率?,F(xiàn)階段,SpringCloudFunctionSPEL漏洞已被分類為比較嚴重級別,CVSS(通用性安全性漏洞評分標準)得分成9.0(100分10)。
對比前面一種,3月29日夜間,有許多網(wǎng)民曝出的SpringRCE漏洞,讓開發(fā)者圈中人人自危。但是有一些與眾不同的是,這一漏洞現(xiàn)階段并沒像Log4j2事情那般造成的圈里眾多公司大型廠的緊急行動,都不像SpringCloudFunctionSPEL漏洞那般有官方網(wǎng)表明,乃至連海外公布漏洞的源頭也是來源于QQ和中國一部分網(wǎng)絡(luò)信息安全網(wǎng)址。
KB2510531補丁修復了Windows Java腳本和VB腳本引擎中存在的一處秘密報告的安全漏洞,當存在漏洞的用戶訪問一個攻擊者精心構(gòu)造的網(wǎng)站時,可能引發(fā)攻擊者的惡意代碼得到執(zhí)行,安裝惡意程序或竊取用戶隱私。360重新安裝補丁。多次安裝失敗選擇智能忽略
網(wǎng)頁題目:java框架代碼執(zhí)行漏洞 代碼執(zhí)行漏洞和命令執(zhí)行漏洞
當前鏈接:http://jinyejixie.com/article12/dodoidc.html
成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián),為您提供網(wǎng)站內(nèi)鏈、外貿(mào)網(wǎng)站建設(shè)、用戶體驗、App開發(fā)、企業(yè)建站、軟件開發(fā)
聲明:本網(wǎng)站發(fā)布的內(nèi)容(圖片、視頻和文字)以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主,如果涉及侵權(quán)請盡快告知,我們將會在第一時間刪除。文章觀點不代表本網(wǎng)站立場,如需處理請聯(lián)系客服。電話:028-86922220;郵箱:631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載,或轉(zhuǎn)載時需注明來源: 創(chuàng)新互聯(lián)