一家互聯網金融公司的安全保護實踐

前言

咱們是一家普通的 P2P 網貸平臺，隨着用戶量和交易量的上漲，十幾我的的研發團隊面臨了很大的挑戰。雙十一開始，平臺受到了很多黑客的攻擊，保證安全的重任也落到了咱們研發團隊的身上。
看到過一個數字，在2014年，超過160家 P2P 平臺因爲黑客攻擊形成系統癱瘓、數據被惡意篡改、資金被洗劫一空。爲了讓平臺更好的抵禦外部侵襲，咱們作了不少努力，下面就分享下咱們在安全保護方面的一些實踐。

成熟的企業主要經過如下幾個方面的工做來保障安全：

• 制定代碼規範和安全代碼規範，培訓相關開發人員熟悉代碼規範，在源頭保障代碼質量

• 制定統一開發模板，確保每一個人編寫 code 格式一致

• 進行嚴格的功能設計，技術設計，架構設計和代碼的評審，確保設計和代碼質量

• 在代碼提交時用相似 checkstyle 等工具對代碼規範進行檢查，確保代碼規範。

• 使用代碼靜態、動態分析工具進行掃描，好比 Java 使用 Findbugs，PWD 等工具。

• 最後就是購買商業掃描工具進行漏洞檢測。好比 Qualys 是特別好的漏洞掃描工具

不過感受作了這麼多，其實仍是不能確保平臺的安全。第1、項目中一般會使用大量的第三方軟件，包括開源的和商業軟件，這些軟件漏洞不是本身能掌控的。其次、全部的檢查都是有侷限性和時效性的，只能確保修復這些軟件掃描出來的漏洞，沒法保障運行時新出現的漏洞，而一般這些新的攻擊也會常常遇到。
 
並且在咱們這種創業公司，這些安全方式很難實踐。做爲 P2P 的平臺，尤爲是在創業階段，要求產品的迭代週期很是的快，實現功能和保障質量是第一優先級。人才招聘也是很是難的一件事情，尤爲是找到能書寫安全代碼的程序員幾乎是不可能的事情。如何保障產品安全，讓咱們一直很是頭疼。沒有足夠的資源和時間，來按照大公司的安全實踐來保障產品的安全。可是安全又是互聯網金融產品相當重要的事情，一旦受到攻擊，進而致使信息泄密或者數據庫破壞，後果不堪設想。

因而咱們嘗試瞭如下兩種方法：

第一種是經過流程和靜態、動態掃描工具來確保代碼符合安全規範。由於面對功能和上線的壓力，再加上程序員的實操能力，都使咱們的嘗試沒辦法較好的實施。經過代碼質量來保障安全，就是0和1的遊戲，減小漏洞是惟一的選擇。沒有漏洞被發現就是1，發現一個漏洞並被利用就是0。

第二種是經過掃描和滲透工具，感受應該是一種方便快捷的方式。它從使用者的角度來攻擊系統，這樣的攻擊是很是實時和有針對性的。

咱們使用了幾種在線的掃描工具：

1.阿里的掃描工具： http://sts.aliyun.com/ ，通過掃描是安全的。

2.百度雲測 http://ce.baidu.com/ ，掃描結果一樣是安全的。

3.這樣的結果讓咱們很是疑慮，沒有通過安全流程考驗的代碼竟然沒有任何安全問題，我有點懷疑這些掃描工具的效果了。因而下載了Nessus家庭版安裝到本地，對咱們的服務平臺進行掃描，結果也並不理想，沒有發現特別有意義的漏洞。

4.還有一種解決方案就是購買Web應用程序防火牆（WAF）。但一般 WAF 很是昂貴，比較好的 WAF 通常在幾十萬上下。這對通常的創業企業是一筆很大的開支。咱們暫時還下不了這個決心去購買。

使用這些掃描器後沒有發現嚴重的問題，並無讓咱們安心。

憑經驗感受，沒有通過嚴格安全流程的代碼是不可能沒有漏洞的。因而咱們就想經過相似 SQL 注入的工具，經過單項滲透測試來檢查是否有漏洞。在百度上搜索「sql注入」的關鍵字，發現了一種實時應用防禦的方式 RASP。之前也曾經關注過國外這方面的資訊，沒有想到，國內公司如今也有了相似產品 OneRASP，因而趕忙 down 下來試試。

團隊通過頭腦風暴，決定把 Nessus 和 OneRASP 結合起來。Nessus 做爲攻擊方，將 OneRASP 放入到應用程序中，做爲防護方（只啓動監控模式），這樣應該可以找到平臺的一些漏洞。說幹就幹，安裝過程仍是挺簡單的。
首先須要註冊一個帳號，而後下載一個探針，將探針解壓到tomcat目錄下。配置catalina.bat：set CATALINA_OPTS="-javaagent:C:\Users\one\Downloads\agent_a3483efc-a4ed-4a86-bde1-910012383309\OneAppDefender\lib\RaspAgent.jar %CATALINA_OPTS%"。最後重啓tomcat就 ok 了。

好了，萬事俱備。看看效果怎麼樣。啓動 Nessus 對加了探針的程序再次進行掃描，毫無疑問，獲得的掃描結果沒有什麼變化。不過咱們最關心的仍是 OneRASP 抓到什麼內容，因而登陸官網進入後臺頁面。內心還真有點小激動，頁面雖然很是簡單，可是抓到了很多漏洞，沒有讓咱們的努力白費。

全部漏洞一目瞭然，最有價值的就是能夠將漏洞定位到應用程序的代碼行。好比SQL注入發生在哪一行代碼裏面，是哪一個 SQL 語句形成的，一目瞭然。

跨站攻擊發生在那個 JSP 頁面也很是清楚。

有了這些信息，程序員就能夠很是方便的知道，去哪行代碼裏面修改這個漏洞。而後咱們下載了幾個比較好的掃描工具，好比 Qualys，ZAP，AppScan 等，分別對咱們的程序（綁定 OneRASP 探針）進行掃描，兩天時間全部漏洞所有修復完畢。

經過這種組合掃描/修復的方式，對咱們產品的安全性信心提升了不少，同時對 RASP 這種方式也充滿了興趣。掃描工具畢竟是隻能針對固定的攻擊手段，在實際的環境裏攻擊手段是多種多樣的。不少攻擊是有針對性的攻擊，不是掃描工具可以覆蓋的。

既然在監控模式下能檢查出這麼多的問題，能不能把它放在咱們的生產環境呢？任何東西放入生產環節都是有風險的，可能影響咱們系統的性能以及穩定性。爲了不這種風險，咱們對注入 OneRASP 安全探針的系統進行爲其兩天的高併發性能和壓力測試，結果和官方性能報告出入不大。對內存、CPU 和響應時間的影響在 5% 左右，沒有發生系統崩潰和內存泄露問題。系統啓動時間增長了 4% 左右，這種性能消耗徹底能夠接受。如下是性能數據：
內存影響：

CPU 影響（咱們這個程序對CPU使用比較高）：

咱們將 OneRASP 應用到線上環境，爲了不誤殺，啓用了監控模式運行了大概一個禮拜。結果然是讓咱們大吃一驚，一個禮拜的時間發現了很多攻擊行爲，幸虧問題都不算太嚴重。在確認沒有誤殺的狀況，咱們開啓了保護模式。到如今爲止基本沒有致使性能和系統問題，防禦效果也挺不錯。下圖是初期監控模式下，半個小時的攻擊狀況：

通過這麼多的嘗試，發現將 OneRASP 的產品和掃描工具結合起來，應用在開發和測試階段，是一種有效的滲透檢測手段。目前咱們在持續使用，很容易上手，不須要專業的安全管理人員，並且不須要購買額外的服務器和修改任何應用程序代碼。

重點是，目前還免費開放使用，這對咱們這種創業公司來講，是很是讚的。OneRASP 在很是短的時間裏，能夠將代碼安全等級提高一個檔次。不過惟一的代價，就是額外消耗一些系統資源。不足的地方就是，如今支持的保護規則偏少，只有 XSS、SQL 注入、已知漏洞掃描工具檢測等6 種。並且頁面設計交互性不強，沒有自定義規則等。不過對於大多數創業公司來說，第一階段的應用防禦應該夠用了。

【編者按】本文通過做者贊成，已經受權 OneAPM 官方技術博客進行轉載和發佈。