本次報告核心觀點
金融行業漏洞細分狀況分析
金融數據泄露原因分析
金融行業漏洞入侵防御建議
報告正文
2015年9月至11月三個月的時間里，安華金和在烏云漏洞平臺上匯總金融行業已被客戶確認的安全漏洞共206個。其中高危漏洞195個，中危漏洞9個，低危漏洞2個。而這206個漏洞中，直接與數據泄露相關的漏洞110個，占漏洞總量的的53%。
金融行業漏洞細分狀況分析
近幾年來隨著行業政策和市場需求的推動，金融行業已經開始嘗試服務互聯網化，普通業務以及更深層次的業務也會逐漸互聯網化，逐漸促進整個金融行業向互聯網 全面遷移。由于金融業多金的本質，各類不法分子一直對這個行業虎視眈眈；一些內部從業人員，也會因為利益的驅使，放下道德底線，從內部竊取數據，導致安全 堡壘從內部被攻破，內外安全問題集中，使得金融業的安全更加危機四伏。金融行業多年沉淀的邊界安全防御機制應面對互聯網帶來的新問題往往顯得力不從心。
安華金和本次將金融行業安全漏洞進行了細分，以銀行、保險、互聯網金融、金融機構（包括證券、基金、期貨、支付和與金融相關的其他機構）四類進行漏洞劃 分。近三個月時間在烏云已經確認的金融行業206個漏洞中，其中銀行42個，保險和互聯網金融各47個，其余來自證券、基金、期貨、支付等金融機構。平均 每月各細分領域曝出的漏洞在10個到20個之間。
2015年9至11月 金融細分行業漏洞分布
金融機構由于包含業務種類繁多，漏洞數量最高、新興互聯網金融，由于對業務的追趕速度和要求遠高于安全需求，雖然業務發展不長，但暴露的安全數量和威脅卻名列前茅。截至2015年11月底，全國范圍內近100家互聯網金融平臺被爆出存在漏洞。
金融數據泄露原因分析
安華金和通過對大量金融行業安全漏洞進行統計分析，發現SQL注入依然是金融業最大威脅。命令執行（框架漏洞）緊隨其后占據了13%的比例。而其中越權類漏洞數量占比明顯高于其他行業。
2015年9至11月 金融行業安全漏洞類型
按照各行業深入探查不難發現：
1.銀行行業中民營銀行安全漏洞數量明顯高于國有銀行。
2.金融業漏洞威脅大，高危漏洞占到總漏洞數的94.56%
3.銀行的APP業務成為隱含漏洞的重災區
4.應用系統權限繞過漏洞五花八門
5.雖然有WAF，但SQl注入依然強勁。
整個金融行業中漏洞種類最全的就是互聯網金融。下面我們著重介紹一下互聯網金融業中的漏洞。
互聯網金融安全漏洞類型
互聯網金融業的漏洞數量雖然不是最多，但種類最全，分布也較為平衡。因為簡單易用，用戶對互聯網金融的接受度普遍比較高。從各種寶到名目繁雜的P2P，互 聯網金融是金融業界的新寵兒。但由于該行業缺乏嚴格的政策管理和代碼審計，業務發展的速度又遠超安全可提供的支撐能力，前臺代碼質量較低，導致出現大量設 計邏輯錯誤、SQL注入、跨站腳本攻擊；從業人員安全意識低，管理不到位，導致出現大量弱口令、框架漏洞、配置錯誤、敏感信息泄露；軟件更新緩慢，導致框 架錯誤。
其中最為嚴重的是系統設計邏輯安全威脅。這些設計錯誤多體現在失敗的權限約束上，形成一系列越權漏洞和SQL注入。越權本質并不復雜，例如平行越權查詢、 平行越權修改、垂直越權操作、批量注冊、人以用戶密碼修改、密碼暴力破解、平行越權下載、身份偽造漏洞、退出功能失效、任意郵箱注冊漏洞、郵箱激活功能漏 洞、刷積分漏洞、邀請碼暴力破解、一號多戶問題等等。
其中越權類查詢在設計錯誤中占到了29%左右。舉個簡單的例子比如A用戶的訂單是111。B用戶的訂單號是112。A原本不能查詢B的訂單，但A用戶可以 通過修改訂單號來越權查詢B的訂單，這就是一個平行越權漏洞。這類問題主要就是程序代碼自身邏輯錯誤導致。這和很多互聯網企業過度注重擴展速度，不關注自 身安全的行為很相似，需要加強代碼審計來規避這種風險。
例如烏云上爆出的 wuyun-2015-147026漏洞是一個標準的因為設計權限導致可充值任意用戶密碼的漏洞。按照流程在網站上注冊一個用戶，選擇忘記密碼。去郵箱打開鏈接。重新輸入密碼和確認密碼。點擊發送，劫持客戶端的網絡包。
在包中把當前用戶名替換成目標用戶名再發送給服務器，達到修改目標用戶密碼的目的。至此入侵者獲得一組被人的賬號，為入侵者可進一步實施入侵奠定基礎。
面對SQL注入雖然有WAF的輔助，但WAF難免有關鍵字過濾不到的時候。于是在金融業界出現了大量的SQL注入漏洞。由于WAF采用的是正則匹配的方式，于是出現了以下3種常見繞過WAF的手段：
（1）編碼繞過
在大小寫繞過的基礎上開始出現編碼繞過，主要出現了三種：URL編碼、十六進制編碼、Unicode編碼。在瀏覽器中輸入URL會進行一次URL編碼，黑 客會通過多次編碼來進行WAF繞過，例如：Id.php?id=1%2520union/**/select ，數據庫得到的Id.php?id=1 union/**/select。如果只解碼一次得到的是Id.php?id=1%20union/**/select，很有可能繞過WAF入侵數據庫。 針對這一問題可以采用多次循環解碼來應對。其中Unicode編碼種類很多，如果只是基于黑名單過濾，無法處理全部情況，其中UTF-32曾經實現過對 GOOGLE的繞過。
（2）注釋繞過
不但可以采用編碼改寫關鍵字，還可以采用注釋改寫關鍵字，避免正則匹配。例如z.com/index.php?page_id=-15 %55nION/**/%53ElecT 1,2,3,4 'union%a0select pass from users# 。就是用符號編碼代替一部分字母和判定的空格來逃避正則匹配。（selectxxx不會被攔截，因為可能是函數名等。select 空格xxx則一定會被攔截，去掉空格成為繞過的關鍵）。同樣還有針對MYSQL版本的/*!5000union*/系列。
（3）等價替換
等價替換是個比較大的分類，主要可以分為等價函數、等價符號、特殊符號、比較符號等4類。
等價函數，就是同功能函數替換。WAF禁止了一些函數，但對另外一些函數沒有禁止例如 Substring()可以用mid()，substr()這些函數來替換。還將可以采用生僻函數迂回完成原函數的功能，進行WAF關鍵字繞過。and or 這種關鍵字在PHP中可以用|| 和&&代替。于是語句id=1 or 1=1就可以寫成id=1 || 1=來進行繞過。同樣！= 、>、<等都可以代替等號進行繞過。
除去繞過關鍵字和關鍵符號外，最關鍵的是繞過空格。想各種方式避免空格出現。
例如 原句 id=1 or 1=1
可以寫成 id=1+or+1=1
id=1%0bor%0b1=1
id=1--s%0aor--s%0a1=1
id=1/*!or*/1=1
id=1()or(1=1) 等多種形式進行嘗試繞過
金融行業漏洞入侵防御建議
金融行業除去人為因素造成的漏洞外，最主要的兩大類漏洞分別是SQL注入和程序邏輯錯誤。
1.解決人為因素
人為因素會造成弱口令、錯誤配置等。人為因素只能從人的角度進行規范。通過加強安全團隊建設、人員安全意識培訓等方式應該可以解決人為因素造成的問題。
2.解決SQL注入
SQL注入是金融行業數據安全面臨的最大威脅。只依賴WAF不足以完全保障程序免收SQL注入的困擾。這是由于WAF擅長解析過濾http協議，不能對 SQL進行解析過濾。針對這個缺陷，可以在WEB應用和數據庫之間加入數據庫防火墻進行SQL部分的解析和過濾。數據庫防火墻對從WEB應用發向數據庫的 SQL語句進行語法解析，可以理解SQL語句的真實含義，并做以下四點判斷：
1、語句是否含有明顯的SQL注入特征；
2、語句訪問的對象是否屬于該用戶訪問權限；
3、語句的關鍵謂詞是否被禁用；
4、限制語句的返回行數，把危險控制在最低限。
加入數據庫防火墻后，數據庫防火墻會在WEB應用和數據庫之間獲取WEB應用發送給數據庫的SQL語句。通過拿到的SQL語句，按照不同數據庫進行SQL 協議解析，通過協議解析把應用發送的SQL語句還原成標準模式（去掉各種加入的符號，轉譯碼等），防止黑客利用上述繞過WAF的手法繞過數據庫防火墻進行 SQL注入。
首先還原后的SQL語句和黑名單中的禁止語句結構進行匹配，如果認為是威脅語句，則禁止該語句發送到數據庫端，并通過發送短信、郵件等方式及時通知管理員 進行處理；語句結構判斷沒有問題后防火墻接下來會對語句中的操作對象和謂詞進行判斷，如果對象或謂詞有控制，則依舊禁止該語句發送到數據庫端；最后即便規 則全部符合，SQL語句被發送到數據庫端，數據庫防火墻還可以通過行數控制來限制數據庫每次的返回行數把威脅減到最小。
3.解決程序邏輯錯誤
程序邏輯錯誤主要指每個用戶權限的劃分時存在邏輯問題。這需要對業務系統中邏輯錯誤進行代碼修改，并加強關鍵部分的邏輯防守。特別需要注意加強防守的功能 點有購物車、支付功能、提現功能、用戶數據查詢、訂單數據查詢、API接口、密碼設置/重置等。同時要注重重要業務系統的運維管理、遵循安全開發最佳實 踐、對密碼本身進行可靠的存儲（數據庫中只存儲加鹽的HASH而不是密碼本身）、使用加密的傳輸協議。
安全其實就是這樣一種形態，平時不出狀況看不到安全的效果，一旦爆發數據泄露事件，無論對于企業還是用戶本身，甚至國家信息安全，其損失不可估量。業務在發展，安全領域攻與防的對抗將長期持續。
下載完整版：《金融行業安全漏洞分析報告》
京公網安備 11010502049343號