摘要:讓我們先看一個比較普遍的漏洞,拒絕服務(wù)漏洞,目前還有不少平臺在采用較老的版本,所以此類漏洞還時有發(fā)生。拒絕服務(wù)漏洞是在一些遺留系統(tǒng)中仍然存在的老錯誤,在與的及更早及更早及更早的版本中都存在這一漏洞。這個缺陷可以用來進(jìn)行拒絕服務(wù)攻擊。
雙十一的硝煙還未散盡,雙十二就要來了。每逢節(jié)日期間,各大電商網(wǎng)站交易量暴漲,用戶蜂擁而至搶購商品。那么這些電商平臺的安全性如何?
據(jù)不完全統(tǒng)計,烏云平臺自成立以來,已收集到的電商平臺漏洞總數(shù)達(dá) 1169 個,其中 2015 年電商平臺漏洞數(shù)為 414 個,相比于 2014 年,漏洞總數(shù)上漲了68.98%。對于安全工程師們來說,則需要加班加點保障網(wǎng)站的穩(wěn)定性和安全性。數(shù)千億的消費額,讓所有的電商平臺工程師,對安全問題不敢有一絲怠慢。
根據(jù) Gartner 的報告,超過 80% 的攻擊是以應(yīng)用層為目標(biāo)的,而大多數(shù)破壞活動是通過應(yīng)用程序進(jìn)行的。他們發(fā)現(xiàn),軟件提供商對應(yīng)用程序安全防護的投 入普遍不足。Gartner 專家指出周界安全防護費用與應(yīng)用程序安全防護費用之比為 23:1。在一個完美的模型中,開發(fā)人員的開發(fā)生命周期 ( SDLC ) 應(yīng)當(dāng)符合安全防護標(biāo)準(zhǔn),從而開發(fā)出安全的軟件?,F(xiàn)實卻并非如此,迭代開發(fā)和快速部署的流行,讓電商平臺正在經(jīng)受重重考驗。
讓我們先看一個比較普遍的漏洞,拒絕服務(wù)漏洞:[Parse Double](),目前還有不少平臺在采用較老的 Java 版本,所以此類漏洞還時有發(fā)生。
拒絕服務(wù)漏洞是在一些遺留系統(tǒng)中仍然存在的老錯誤,在 Windows 與 Linux 的 JDK1.6_23 及更早 JDK1.5_27 及更早 JRE 1.4.2_29 及更早的版本中都存在這一漏洞。對于使用 Apache Tomcat 服務(wù)器的系統(tǒng),若其 JRE 比較脆弱,未經(jīng)授權(quán)的用戶完全可以耗盡其所有資源。
實現(xiàn)方式——實現(xiàn) java.lang.Double.parseDouble() 及其相關(guān)方法中的漏洞會導(dǎo)致線程在解析[2^(-1022) - 2^(-1075) : 2^(-1022) - 2^(-1076)]范圍內(nèi)的任一數(shù)字時造成線程懸停。這個缺陷可以用來進(jìn)行 DOS(拒絕服務(wù))攻擊。例如:下面的代碼使用了較為脆弱的方法。
Double d = Double.parseDouble(request.getParameter("d"));
攻擊者可以發(fā)送這樣的請求,其參數(shù) d 在上面的范圍中,例如「 0.0222507385850720119e-00306」 ,進(jìn)而導(dǎo)致程序在處理該請求時懸停。
黑客新聞中的評論指出,BigDecimal.doubleValue 方法實際上只是將參數(shù)轉(zhuǎn)化為字符串,然后調(diào)用 Double.parseDouble 方法。因此,非常不幸,上面的機制只有在我放棄一些精度調(diào)用 Math.pow(10, exponent) ,而不使用 scaleByPowerOfTen 時會起作用。上面的版本,很遺憾,不起作用。
盡管這個錯誤已經(jīng)在 JDK 1.6_24 及之后的版本得到修復(fù),安全行業(yè)研究機構(gòu)發(fā)現(xiàn)許多 Java 系統(tǒng)可能還在運行有風(fēng)險的老版本。普遍的建議是升級系統(tǒng)或者單純地標(biāo)準(zhǔn)化清理后的字符串,將其傳入新的 java.math.BigDecimal() 方法,再將結(jié)果轉(zhuǎn)化為基本 double 類型。遺憾的是,BigDecimal 的構(gòu)造函數(shù)也會調(diào)用麻煩的 Double.parseDouble 代碼,因此我們又回到了原點。最后,我們還可以嘗試下面的代碼,雖然不能說它高效,但是它通過了所有 Float 測試,不會像 Double.parseDouble 那樣拒絕服務(wù)。
public static double parseDouble(String value) { String normalString = normalizeDoubleString(value); int offset = normalString.indexOf("E"); ? BigDecimal base; int exponent; if (offset == -1) { base = new BigDecimal(value); exponent = 0; } else { base = new BigDecimal(normalString.substring(0, offset)); exponent = Integer.parseInt(normalString.charAt(offset + 1) == "+" ? normalString.substring(offset + 2) normalString.substring(offset + 1)); } return base.scaleByPowerOfTen(exponent).doubleValue(); }
這種方式雖說有一定效果,算不上聰明和高效。那么是否有更好的方式呢?
一種新型應(yīng)用安全保護技術(shù)受到了較多的關(guān)注—— RASP(實時應(yīng)用安全自我保護)。RASP 將保護程序想疫苗一樣注入到應(yīng)用程序和應(yīng)用程序融為一體,能實時檢測和阻斷安全攻擊,使應(yīng)用程序具備自我保護能力。比如說針對拒絕服務(wù)漏洞 Parse Double 來說,RASP 定制了響應(yīng)的規(guī)則集和防護類,然后采用 java 字節(jié)碼技術(shù),在被保護的類被加載進(jìn)虛擬機之前,根據(jù)規(guī)則對被保護的類進(jìn)行修改,將防護類織入到被保護的類中,從而保證了我們服務(wù)器的安全。
RASP 工作在運行環(huán)境時,像疫苗一樣和應(yīng)用程序融為一體,了解應(yīng)用的上下文,從而可以實時徹底的保護應(yīng)用程序,使應(yīng)用程序免受漏洞所累?,F(xiàn)在是廣告時間啦!目前,國內(nèi)只有一個產(chǎn)品OneASP擁有這個功能。大家可以訪問一下網(wǎng)站和 DEMO ,體驗一下我們強大的功能吧。雙十二就要來了,希望各位電商平臺能夠拒絕向「漏洞」低頭 !
OneRASP(實時應(yīng)用自我保護)是一種基于云的應(yīng)用程序自我保護服務(wù), 可以為軟件產(chǎn)品提供實時保護,使其免受漏洞所累。
文章版權(quán)歸作者所有,未經(jīng)允許請勿轉(zhuǎn)載,若此文章存在違規(guī)行為,您可以聯(lián)系管理員刪除。
轉(zhuǎn)載請注明本文地址:http://www.ezyhdfw.cn/yun/11157.html
摘要:爆出中等嚴(yán)重性安全漏洞拒絕服務(wù)漏洞。本文將進(jìn)行漏洞解讀和情景再現(xiàn),并分享漏洞修復(fù)方案,用戶來看應(yīng)對之策了漏洞美國當(dāng)?shù)貢r間年月日,社區(qū)發(fā)布了拒絕服務(wù)的漏洞,即有寫入權(quán)限的用戶在寫入資源時會導(dǎo)致過度消耗資源,此漏洞被評級為中等嚴(yán)重性。 Kubernetes爆出中等嚴(yán)重性安全漏洞——Kubernetes API Server拒絕服務(wù)漏洞CVE-2019-1002100。 本文將進(jìn)行漏洞解讀和...
摘要:跨站請求偽造定義又稱,攻擊者盜用用戶身份,發(fā)送惡意請求。避免全站通用的,嚴(yán)格設(shè)置的域。并且通過攜帶過程的信息可以使服務(wù)端返回開頭的狀態(tài)碼,從而拒絕合理的請求服務(wù)。 CSRF (cross site request forgery)跨站請求偽造 定義 又稱XSRF,攻擊者盜用用戶身份,發(fā)送惡意請求?!久俺溆脩舭l(fā)起請求(在用戶不知情的情況下),完成一些違背用戶意愿的請求(如惡意發(fā)帖,刪帖,...
摘要:前言上一篇中通過對阿里聚安全漏洞掃描騰訊金剛審計系統(tǒng)百度移動云測試中心以及在收費情況樣本測試后的掃描時間對比和漏洞項專業(yè)對比后,本篇將以各個廠商的掃描能力作為分析維度展開。表示掃描結(jié)果正確,表示掃描結(jié)果錯誤。 前言 上一篇中通過對阿里聚安全[1]、360App 漏洞掃描[2]、騰訊金剛審計系統(tǒng)[3]、百度移動云測試中心[4]以及AppRisk Scanner[5] 在收費情況、樣本測試...
摘要:前言上一篇中通過對阿里聚安全漏洞掃描騰訊金剛審計系統(tǒng)百度移動云測試中心以及在收費情況樣本測試后的掃描時間對比和漏洞項專業(yè)對比后,本篇將以各個廠商的掃描能力作為分析維度展開。表示掃描結(jié)果正確,表示掃描結(jié)果錯誤。 前言 上一篇中通過對阿里聚安全[1]、360App 漏洞掃描[2]、騰訊金剛審計系統(tǒng)[3]、百度移動云測試中心[4]以及AppRisk Scanner[5] 在收費情況、樣本測試...
閱讀 1300·2021-11-25 09:43
閱讀 1395·2021-09-26 09:55
閱讀 2481·2021-09-10 11:20
閱讀 3427·2019-08-30 15:55
閱讀 1524·2019-08-29 13:58
閱讀 1234·2019-08-29 12:36
閱讀 2427·2019-08-29 11:18
閱讀 3489·2019-08-26 11:47