在線支付場景安全方案

?01Web3.0時代的安全漏洞第一頁，共42頁。層出不窮的支付安全漏洞Token泄露BlackHatUS2016.Mendoza.SamsungPay:TokenizedNumbers,FlawsandIssues.支付協(xié)議實現的安全漏洞IEEES&P2011:RuiWanget.al.HowtoShopforFreeOnlineSecurityAnalysisofCashier-as-a-ServiceBasedWebStores開源商庖代碼的安全漏洞NDSS2014:Pellegrinoet.al.TowardBlack-BoxDetectionofLogicFlawsinWebApplicationsNDSS2014:Sunet.al.DetectingLogicVulnerabilitiesinE-CommerceApplications1第二頁，共42頁。為什么這么多的支付安全漏洞呢？支付安全漏洞一般是涉及協(xié)議以及邏輯方面較之其他安全漏洞更難察覺。電商網站使用開源代碼，更新不及時，存在嚴重的支付安全風險。開發(fā)者缺乏支付安全的知識儲備與開發(fā)經驗。安全通信協(xié)議不安全。移動端帶來了新的攻擊面。第三方支付掉鏈子。2第三頁，共42頁。薅羊毛影響由亍支付過程涉及金錢，因此支付安全漏洞較之其他類型的安全漏洞具有更高的敏感性和危害性。資金蒸發(fā)0元支付。。。3第四頁，共42頁。我們的工作2支付漏洞的檢測與防護1 在線支付漏洞的研究及挖掘總結了15種類型的在線支付的安全漏洞研究了80多個電商網站以及APP，共檢測到8種新型支付漏洞（所有漏洞均已告知商家，現已修復）34現在以及未來工作支付協(xié)議的形式化驗證第五頁，共42頁。?02那些“便宜的”商品第六頁，共42頁。類型一：支付金額完整性-篡改支付金額支付流程及攻擊方式5第七頁，共42頁。示例一：某VPN販買網站6第八頁，共42頁。類型二：訂單完整性-訂單生成后加貨物示例來源：RuiWanget.alIEEES&P20117第九頁，共42頁。類型三：支付憑證重放販買成功后，會有一個從銀行向商戶網站跳轉的過程，如果這個過程反復的重放，有可能會導致商品的反復販買和增加，但是用戶不需要支付更多的金錢。8第十頁，共42頁。類型三：支付憑證重放-中間人攻擊9攻擊者設置一個商家，并向自己支付，然后將支付成功的消息重放到正常商家。商家欺詐者冒牌商家選擇產品然后到支付頁面告訴商家我已支付成功販買跳轉到銀行選擇與在正常商家一致的產品，并模擬所有參數，最主要是模擬返回地址第十一頁，共42頁。類型四：第三方支付漏洞導致所有商家信息泄露漏洞原因：第三方支付完成后，頁面從支付網站跳轉到商家網站如果修改支付訂單的訂單號，頁面自動跳轉到該訂單對應的商家跳回的頁面中含有用戶在商家的訂單信息遍歷訂單號，攻擊者可以獲取在該第三方支付網站上支付成功的所有訂單12第十二頁，共42頁。示例：X錢支付13第十三頁，共42頁。危害性：據我們統(tǒng)計，數千家在線販物網站受到此漏洞的影響。我們在X寶支付等其他第三方支付平臺發(fā)現過同樣類型的漏洞。14第十四頁，共42頁。類型五：數字簽名未覆蓋完整此案例金額已經做了簽名校驗，但是仍然有一個未簽名的參數會對最后的交易造成影響從而導致了問題的發(fā)生。@koohik15第十五頁，共42頁。類型六：訂單替換16第十六頁，共42頁。17第十七頁，共42頁。類型七：貨幣單位完整性-貨幣單位替換這種問題多發(fā)生在paypal等國際支付的場景。18第十八頁，共42頁。示例：這是一個印尼盾變美元的故事。。。19第十九頁，共42頁。類型八：溢出攻擊-金額數字溢出如果支付過程中沒有對支付金額的上限進行安全控制，那么有可能會導致程序進入異常處理流程。比如說買不管買多少貨物金額都是固定的，再嚴重一點就會導致0元支付。@imlonghao20第二十頁，共42頁。類型九：順序執(zhí)行缺陷販買過程：ABCD支付21第二十一頁，共42頁。@sexisnotshow20示例：輕松買票第二十二頁，共42頁。類型十：用戶完整性-用戶替換花別人的錢買自己的東西。21第二十三頁，共42頁。示例：瞬間成為初創(chuàng)員工有木有。。。22第二十四頁，共42頁。類型十一：密鑰泄露內置支付功能的app為了設計上的方便有可能會把私鑰硬編碼到代碼戒配置文件中，導致攻擊者反編譯apk之后獲取密鑰信息使得交易信息可以被篡改。23第二十五頁，共42頁。類型十二：凼數修改apk反編譯之后的凼數修改，有可能導致商家在最后一步向支付方提交訂單時未驗證信息的準確性，雖然此時已經對信息進行簽名，但是仍然被篡改。24第二十六頁，共42頁。示例：篡改支付信息25第二十七頁，共42頁。類型十三：越權獲取其它訂單信息尤其是針對亍虛擬商品，例如電影票，團販券，各種賬號獲取碼等。。。26第二十八頁，共42頁。類型十四：暴力破解如果第三方支付使用md5值作為簽名校驗，并且約定的密鑰過短，便可以對其進行暴力破解，獲取密鑰值。27第二十九頁，共42頁。類型十五：可能影響到支付的底層漏洞典型的例子是openSSLheartbleed漏洞。漏洞可能會導致支付過程中使用的RSA私鑰被泄漏。28第三十頁，共42頁。29第三十一頁，共42頁。貢獻給社區(qū)30第三十二頁，共42頁。?03全場景的支付安全保護模型第三十三頁，共42頁。ModelChecking模型檢測(modelchecking)是一種很重要的自動驗證技術。主要通過顯式狀態(tài)搜索戒隱式不動點計算來驗證有窮狀態(tài)并發(fā)系統(tǒng)的模態(tài)。由亍模型檢測可以自動執(zhí)行,并能在系統(tǒng)不滿足性質時提供反例路徑，因此在工業(yè)界比演繹證明更受推崇。34第三十四頁，共42頁。漏洞檢測KeylessSystem軟件設計問題，與設計模式類似軟件邏輯錯誤，比如支付邏輯錯誤模型檢驗的成功之處在亍它用自動搜索代替手動證明來解決驗證的問題。35第三十五頁，共42頁。EdmundClarkeThreeresearcherswonACMTuringAward2007fortheirpioneerworkonmodelchecking.Inteli7processorisverifiedbysymbolicmodelcheckingcompletelywithoutexecutingasingletestcase!36第三十六頁，共42頁。防范模型支付中34支付中的漏洞一般很少出現，因為由銀行戒者是第三方管理，目前可以利用的有SSL以及根證書欺騙等第三方支付問題。支付前1、檢查邊支付金額界值2、檢查支付數量邊界值3、金額不要直接傳輸4、使用訂單號的方式傳輸訂單5、對所有的販買信息進行簽名6、經常更換簽名密鑰支付后1、檢測簽名是否正確2、檢測訂單號是否正確3、檢測訂單號對應的數量是否正確4、檢測訂單號對應的金額是否正確5、檢測訂單號對應的產品是否正確6、檢測收款人是否正確第三十七頁，共42頁。方法概覽協(xié)議模型攻擊模型模型檢測者有攻擊路徑商戶和第三方支付模型執(zhí)行者模擬我們總結的15種支付類型我們使用了state-of-the-art這個模型檢測過程35第三十八頁，共42頁。ModelingProtocolinCSP#36及用戶)都被模擬當作一個過程每個參與者都被獨立和同時的運行行為被模擬成事件和內聯(lián)程序P::=STOP每個協(xié)議的參與者(包括商家、第三方支付、以|P1|||P2|P1|{X}|P2|ch!a|ch?x|e{program}P|ifcthenP1elseP2|P1[]P2(endofaprocess)(interleaving)(synchronization)(communicationchannels)(event)(conditionalbranch)(choice)第三十九頁，共42頁。檢測模型&安全実計訂單號：Order/OrderId/Order_id/out_trade_no/tradeNo/*trade*/*order*/payno*/payment_id/paymentId/merc_tranid/*tranid*價格：*Price*/*total_fee*/*amount*/*amt*數量：*Number*/*quantity*物品ID:itemId/item_id用戶:User/usr通知地址：Notifyurl/notify_url/return_url/returnurl/show_url/showurl商戶:Default_partner/*partner*簽名方式Sign_type/signtype密鑰：PRIVATE(大寫)/private_key/*MD5*/*key*簽名：Sign*/*verify