金融證券類手機(jī)應(yīng)用安全性評(píng)測報(bào)告-資料下載頁
2025-04-14 04:56本頁面
【正文】 鑫財(cái)通HTTPB招商智遠(yuǎn)理財(cái)HTTP自有協(xié)議長江e號(hào)TCP手機(jī)證券極速版TCP盈盈理財(cái)HTTPSA大智慧TCP表6 登錄安全分析結(jié)果不校驗(yàn)服務(wù)端證（A）：如果客戶端在登錄過程中不對服務(wù)端的身份（證書）進(jìn)行校驗(yàn)，就有可能“信任”偽裝身份的“冒牌服務(wù)端”，連接到假冒的服務(wù)端上。連接假冒的服務(wù)端不僅可能造成用戶名、密碼等信息被竊取，甚至還有可能造成直接的財(cái)產(chǎn)損失。重放攻擊（B）：如果攻擊者能夠截獲傳送登錄信息的數(shù)據(jù)包，并且在不解密該數(shù)據(jù)包的情況下，直接使用該數(shù)據(jù)包來成功登錄服務(wù)器，則稱這種攻擊為登錄過程中的重放攻擊。造成重放攻擊的主要原因是登錄加密機(jī)制不完善。在完善的登錄加密體系中，即使是相同的賬號(hào)和密碼，在不同的客戶端上進(jìn)行登錄，其加密數(shù)據(jù)包也應(yīng)該是有所不同，并且還會(huì)隨時(shí)間的不同而不斷變化。傳輸密碼加密簡單（C）：用戶在使用手機(jī)APP登錄時(shí)，賬號(hào)與密碼等數(shù)據(jù)雖然是經(jīng)過加密后傳輸給服務(wù)器的，但由于加密算法過去簡單，很容易被攻擊者破解。微博登陸不校驗(yàn)服務(wù)端證書（D）：某些手機(jī)應(yīng)用與微博實(shí)行聯(lián)合登錄機(jī)制，但當(dāng)用戶使用微博賬號(hào)登陸該應(yīng)用時(shí)，客戶端未并對微博服務(wù)器的身份（證書）進(jìn)行校驗(yàn)。這就導(dǎo)致這個(gè)手機(jī)應(yīng)用很有可能會(huì)連接到假冒的微博服務(wù)器上，從而致使信息泄露。在表6的協(xié)議一欄中，我們可以看到，絕大多數(shù)金融證券類應(yīng)用在登錄過程都會(huì)選擇使用HTTP或HTTPS協(xié)議進(jìn)行登錄信息的傳輸。但也有部分應(yīng)用在登陸時(shí)會(huì)選擇只使用傳輸層的TCP協(xié)議進(jìn)行傳輸，而沒使用應(yīng)用層的HTTP或HTTPS協(xié)議。一般而言，使用HTTPS進(jìn)行信息加密傳輸?shù)陌踩宰罡?。但從上表可見，在本次測評(píng)中被檢測的20款金融證券類應(yīng)用中，不論是使用HTTP的應(yīng)用，還是使用HTTPS的應(yīng)用，幾乎都或多或少的被檢測出了一定的登錄安全性問題。只有招商智遠(yuǎn)理財(cái)這款使用了HTTP協(xié)議+自有協(xié)議實(shí)現(xiàn)加密的應(yīng)用，暫時(shí)沒有被檢測出登錄安全性問題。還需要特別說明的是，在上表中，所有使用TCP協(xié)議的應(yīng)用都沒有被檢測出登錄安全性問題，但這并不表示這些應(yīng)用就比使用了HTTP或HTTPS協(xié)議的應(yīng)用在登錄方面更安全。這主要是因?yàn)椋耗壳笆袌錾辖^大多數(shù)的手機(jī)應(yīng)用都是采用HTTP或HTTPS協(xié)議來傳輸?shù)卿浶畔⒌?，而僅僅使用TCP協(xié)議來傳輸?shù)卿浶畔⒌膽?yīng)用非常少見（但在本次檢測的20款金融證券類手機(jī)應(yīng)用中，竟然占到了9款）。所以，本次測試所采用的主要分析方法和分析工具都是針對HTTP和HTTPS協(xié)議進(jìn)行的，而對哪些只使用了TCP協(xié)議進(jìn)行登錄信息傳輸?shù)膽?yīng)用的檢測手段和分析方法則相對有限。所以，我們不能僅憑表6就斷定說只用TCP協(xié)議傳輸比使用HTTP或HTTPS協(xié)議傳輸更安全。就一般性而言，目前業(yè)界比較公認(rèn)的安全傳輸協(xié)議體系還是HTTPS協(xié)議。只是本次測試的20款應(yīng)用中，所有使用了HTTPS協(xié)議的應(yīng)用，都沒有能夠?qū)崿F(xiàn)完整和完善的登錄安全機(jī)制。關(guān)于安卓客戶端登陸相關(guān)更多詳細(xì)的漏洞原理，請參見360互聯(lián)網(wǎng)安全中心2014年7月發(fā)布的《手機(jī)銀行客戶端安全性測評(píng)報(bào)告》。 第五章 安全建議對于金融客戶端軟件的開發(fā)者，我們提出如下一些安全建議：1） 盡量不要將WebView組件設(shè)置為可導(dǎo)出。若確有導(dǎo)出需求，也要對調(diào)用者進(jìn)行身份驗(yàn)證，以免遭到黑客的惡意攻擊。2） 開發(fā)者在注冊廣播receiver時(shí)，不僅要限制發(fā)送方必須要有相應(yīng)的權(quán)限，還要將該權(quán)限的protectLevel屬性定義為signatureOrSystem，即只有相同數(shù)字簽名的應(yīng)用程序才能申請?jiān)摍?quán)限。3） 若無必要需求，不要將大量組件接口數(shù)據(jù)暴露在外，否則會(huì)存在潛在的高危風(fēng)險(xiǎn)。4） 開發(fā)者盡量不要將用戶名和密碼這種敏感類信息保存在本地，若必須要保存到本地，也建議使用復(fù)雜的加密算法，且盡量不要將接口設(shè)置為可導(dǎo)出的接口。5） 開發(fā)者要保持良好開發(fā)習(xí)慣，切勿輕易將文件賦予成全局可讀/寫權(quán)限，否則可能造成信息泄露、軟件功能不正常，甚至引發(fā)高危漏洞。6） 針對登錄過程中的加密機(jī)制，我們建議采用體系比較完善的HTTPS機(jī)制。HTTPS除了能對登錄過程中的數(shù)據(jù)進(jìn)行加密，以保證傳輸數(shù)據(jù)的安全性和完整性之外，——基于這種機(jī)制，可以確認(rèn)通信雙方身份。使用HTTPS自身的機(jī)制進(jìn)行服務(wù)端身份校驗(yàn)也是可行的。7） 為了防御登錄過程中的重放攻擊，開發(fā)者除了可以使用時(shí)間戳，也可以使用挑戰(zhàn)響應(yīng)機(jī)制。這一機(jī)制簡單來說就是，每次登陸時(shí)，服務(wù)器給客戶端發(fā)一個(gè)隨機(jī)數(shù)，客戶端用事先雙方協(xié)商好的算法算出一個(gè)響應(yīng)數(shù)，連同登陸憑證一起發(fā)送給服務(wù)器。無論是時(shí)間戳還是挑戰(zhàn)響應(yīng)機(jī)制都會(huì)使每次登陸發(fā)送的數(shù)據(jù)包是不一樣的，從而預(yù)防了重放攻擊這一問題。 附錄 參考鏈接（一） 關(guān)于addJavascriptInterface漏洞的細(xì)節(jié)：（二） 關(guān)于FakeID漏洞的詳情（三）其他WebView相關(guān)的漏洞可以參考360安全研究員宋申雷的幻燈片《細(xì)數(shù)WebView的那些神洞》（四） 關(guān)于同源繞過攻擊相關(guān)信息18
畢業(yè)設(shè)計(jì)相關(guān)推薦
鄂ICP備17016276號(hào)-1