支付安全的思考

最近公司遭到黑客的兩次攻擊形成不小的損失,恰好沒什麼事就來記錄分析一下怎麼避免或者減少攻擊形成的損失。首先來介紹下公司的業務吧,公司主要是作電話充值卡,加油卡充值等方面的業務,算是華南地區最大的充值中間商,日流水在1億左右。數據庫

第一次被黑能夠說是技術經驗不足,不夠當心致使的。黑客僞造了一條支付請求,把請求中的支付的金額改爲1分錢,購買的充值卡是100元的,當支付1分錢後微信後臺回調我司服務器接口,程序驗證的時候發現客戶端請求的金額和實際支付的金額是一致的,都是1分錢,並無驗證和購買的物品的金額100元是否一致,因而認爲支付成功了。這樣就致使黑客可使用1分錢購買100元的充值卡,給公司形成了6萬多元的損失。此次能夠說是程序開發人員不下心致使的,沒有仔細校驗數據,這種錯誤是徹底能夠避免的。相比上一次,第二次的攻擊就高明瞭許多。首先是時間的選擇上,攻擊是在凌晨開始的,20分鐘後值班的客服發現訂單數據異常,報給了運維,但運維以偶爾充值異常爲由就沒有重視,以後報告給了商務,最後才通知的技術,技術查看數據後才發現問題並讓運維關閉了該支付接口。此次使用的是溢出攻擊,很難防範。假如黑客帳戶裏有10元錢,而後他會把100元的充值卡加入購物車,而後請求購買,服務器收到請求後進行判斷(10-100 <0)返回購買失敗,而後再增長充值卡到購物車,購買,服務器判斷(10-200 < 0),返回失敗,.....,通過不停的購買,購物車裏商品的金額溢出了,變成了一個負數,而後服務器在判斷時拿用戶的金額減去一個負數結果就大於0了,因而服務器判斷這次支付成功。這樣致使黑客不須要支付任何金額就能夠購買100元的充值卡,在持續9個小時的攻擊中給公司形成了87萬餘元的損失。安全

通過這兩次的攻擊我在想一個問題,咱們公司作了近10年的充值業務,從未發生過如此嚴重的事故,爲何一到微信支付上或者說是互聯網上就出現如此重大的問題,我想主要是如下幾個方面的緣由:服務器

1.以前和銀行的充值接口使用範圍很是小。若是隻有咱們一家公司使用的話去專門來找漏洞是不划算的,不具備廣泛適用性。而微信有十幾億用戶,上面的商戶也不少,開發出來的工具能夠屢次使用,更能吸引黑客的注意力;微信

2.銀行接口的開發文檔少。除非內部的開發人員其餘人很難拿到開發說明文檔,而微信的文檔很是齊全,只要在微信上註冊一個開發者帳號就能夠拿到詳細的接口說明;運維

3.銀行的接口的數據驗證很是複雜。銀行客戶端發來的數據和回調有很複雜的驗證過程,只要按照它的要求進行數據驗證就能夠保證不會出現欺騙的問題;svn

4.麻痹心理。由於已經作了不少年的充值,不少人覺得微信上的支付跟之前銀行的同樣,不會出現什麼問題,沒有重視;工具

5.攻擊銀行的後果很嚴重,參考許霆案微信支付

那麼應該預防這種攻擊呢?我想能夠有如下幾種方法:htm

1.支付成功回調的數據進行詳細的驗證。首先固然是簽名驗證,保證數據不是僞造的。其次要把請求購買的數據和支付成功後回調的數據進行詳細的驗證。若是數據不一致,要有合理的解釋。好比物品打折時就會形成購買物品的金額和支付的金額不一致,支付金額會少一些,要把支付金額和數據庫裏物品的金額進行對比。這樣的話,第一次那種攻擊就不會出現了。接口

2.先扣錢再發貨。這是我在作一款網遊裏物品購買時學到的。當時有人反饋買遊戲中的某種裝備能夠在錢不夠時買到,咱們通過複查代碼發現確實可能出現。由於那段程序是先檢查等級之類是否符合購買條件,符合的話,就把商品給玩家,而後再去扣遊戲幣,這樣即便遊戲幣扣除失敗了你的商品已經發給用戶了,從svn的提交記錄來看這段代碼已經存在一個月了。這就給咱們一個啓示,凡是買東西,先扣錢,再發商品。若是商品發了,錢沒扣,用戶是不會說話的,但若是商品沒發錢扣了,用戶必定會第一時間反饋問題。辦法雖然齷蹉了點但絕對有效。

3.建立限額程序。當黑客已經成功的找到了漏洞並進行盜竊時怎樣來儘量的減少損失是當務之急。在第一次攻擊後咱們就作了一個限制交易總量的程序(LDQ),依據是某個渠道的交易額是基本穩定在一個範圍的,不會出現大幅度的變化。若是一個渠道天天的交易總量在50-100萬,那麼就能夠配置150萬做爲報警點,總量達到200萬時直接拒絕交易。處理的流程是當支付請求到來時,會先經過MsgSrv【一個消息的轉發服務】向LDQ詢問是否能夠交易,若是能夠繼續交易,若是返回失敗就取消這筆訂單。固然若是確實是正常的交易額增長,能夠手動解除限制或者調高限額。

4.限制單筆交易量。對單筆的購買物品數量和交易額進行限制,這樣能夠避免溢出。固然程序中最好使用unsigned類型定義,若是是C/C++的話。最大限度的控制出現錯誤的可能。

5.創建數據分析機制。要有一個程序,不停的掃描交易過的或者未交易的訂單,發現問題及時預警。固然可使用從數據庫減輕主庫的壓力。

6.創建合理的反饋機制。不少時候出現問題,技術是最後一個知道問題的。這就很奇怪,由於其餘人即便知道有這件事也不知道是否是bug。好比咱們此次被黑客攻擊,客服發現異常的訂單,反饋給運維,運維找商務,商務才找到技術,已經9個小時過去了。若是能提前把問題反映給技術是能夠減小不少損失的。

其實說了這麼多最重要的仍是人,只要開發人員有足夠的經驗而且細心,創建合適的監控是徹底能夠作到安全的。

相關文章
相關標籤/搜索