交易所安全系列 -- 談用戶認證

摘要：零時科技安全團隊對某交易所進行安全測試時，發現該交易所的某交易所在賬號登錄處存在問題，雖然限制每個用戶的登錄試錯次數，但並不限制同一IP對不同用戶嘗試登錄的請求數量。零時科技安全團隊在對某交易所進行安全測試時發現，該交易所在手機登錄處需要向用戶發送驗證碼並進行校驗。

假作真時真亦假，但憑僞造之證，信手指鹿爲馬，登堂入室。罔顧用戶之安危，豈非人爲刀俎，我爲魚肉乎？

一、用戶認證概述

用戶認證安全方面的安全問題也許單單從技術層面上講，並不是一種非常複雜的問題，因爲解決起來並不怎麼困難；但如果從交易所的實際交易業務層面來看，用戶認證方面如果存在安全隱患，那將是非常可怕的。簡單試想一下，如果一個黑客可以通過任意賬號的用戶認證，那這位攻擊者會對那些賬戶裏的餘額做什麼呢……

這只是用戶認證安全問題的一個小例子，當然同類的問題還有很多，雖然不盡相同，但其破壞性影響是同樣可怕的。零時科技安全團隊已經對此類問題做了一些整理，詳情可見以下的測試列表，建議各大交易所以此列表自查，規避不必要的安全風險。

二、測試列表

用戶認證

用戶註冊過程測試
用戶登錄過程測試
找回密碼過程測試
設備解綁過程測試
驗證碼策略測試
帳戶權限變化測試
帳戶枚舉測試
弱密碼策略測試
口令信息加密傳輸測試
默認口令測試
帳戶鎖定機制測試
認證繞過測試
瀏覽器緩存測試
權限提升測試
授權繞過測試

三、案例分析

口令信息加密傳輸測試

“反正數據包也只是在用戶和交易所之間傳輸的，口令要加密幹什麼”，可能有部分粗心大意的開發人員會這麼想，但事實真的是這樣嗎？口令加密真的沒有用嗎？顯而易見，事實當然不是這樣的。但可能有的開發人員真的會這麼想，所以口令信息不加密即傳輸成爲了各大交易所中最常見的問題之一。

口令加密的好處很多，比如可在一定程度上防止爆破；比如用戶登錄交易所期間被中間人攻擊時，攻擊者截獲的數據包中若沒有明文口令信息，即可使攻擊者無法輕易獲取口令等等。零時科技安全團隊在對某交易所進行測試時，發現該交易所的口令信息在傳輸時已被前端加密。零時科技團隊安全研究員隨即審計網站前端js代碼，尋找登錄/重置密碼時需要提交的參數，並在找到後，按js內容要求構造未加密數據包向api請求，所幸該某交易所對非加密數據包也敞開懷抱，即使是明文數據包，只要參數正確也可發揮作用。最後通過該漏洞和其他漏洞配合，成功登進其他用戶賬戶。

零時科技安全團隊建議，各大交易所在傳輸口令信息時，能夠使用加密傳輸的方式，且最好不要留下加密算法的明顯線索（加密用何種算法，密鑰是什麼等），保障信息安全。

用戶登錄過程測試

爆破，即暴力破解，意指使用大量可能有效的潛在答案一一嘗試，最後留下確實有效答案的攻擊手法。爆破雖然笨重但卻經常有效；雖然常有奇效，但也確實要和某些其他問題合作才能發揮功能。

零時科技安全團隊對某交易所進行安全測試時，發現該交易所的某交易所在賬號登錄處存在問題，雖然限制每個用戶的登錄試錯次數，但並不限制同一IP對不同用戶嘗試登錄的請求數量。零時科技安全研究員隨即對該交易所實施了撞庫攻擊，最終成功破解出部分用戶口令。

零時科技安全團隊建議，各大交易所在登錄頁面應同時使用圖形或更復雜的驗證碼；對同一IP發出的請求頻率和數量進行限制。

驗證碼策略

驗證碼在某些情況下有着極強的安全作用，但如若使用不當或有所疏漏，也會留下安全隱患。看似有驗證碼放心了不少，其實有可能只是一件“皇帝的新衣”。零時科技安全團隊在對某交易所進行安全測試時發現，該交易所在手機登錄處需要向用戶發送驗證碼並進行校驗。該交易所驗證碼長度6位，貌似安全性較高，但實則可發現具有遞增趨勢且遞增速度緩慢，爆破驗證碼時可以輕易確認當前驗證碼所在範圍。對於交易所來說，這樣的驗證碼機制就是“皇帝的新衣”；對於攻擊者來說，更降低了攻擊成本，提高了攻擊效率。

零時科技安全團隊建議各大交易所使用驗證碼保障自身安全時，應使用隨機多位的驗證碼，有條件的話最好使用字母和數字混雜的高強度驗證碼，並限制驗證碼輸入錯誤的次數，採取一定措施。