2.9.2　案例分析

1.口令信息加密傳輸測試

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

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

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

2.用戶登錄過程測試

爆破（暴力破解）指使用大量可能有效的潛在答案一一嘗試，最后留下確實有效的答案的攻擊手法。爆破雖然比較“笨”，但卻經常有效；雖然常有奇效，但也確實要和其他方法組合使用才能發揮作用。

圖　2.49

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

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

3.驗證碼策略

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

圖　2.50

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