2.9.2　案例分析

1.口令信息加密传输测试

可能有部分粗心大意的开发人员会这么想：“反正数据包也只是在用户和交易所之间传输的，口令加密有必要吗？”。但事实真的是这样吗？口令加密真的没必要吗？显而易见，口令加密是非常必要的。但可能有的开发人员真的会这么想，所以口令信息不加密即传输成了各大交易所中最常见的问题之一。

口令加密的好处很多，比如可在一定程度上防止爆破，再比如用户登录交易所期间被中间人攻击时，攻击者截获的数据包中若没有明文口令信息，可使攻击者无法轻易获取口令，等等。我们团队在对某交易所进行测试时，发现该交易所的口令信息在传输时已被前端加密。我们团队的安全研究员随即审计网站前端JS代码，寻找登录/重置密码时需要提交的参数，并在找到后，按JS内容要求构造未加密数据包，通过API发送请求，该交易所对非加密数据包也可支持，即使是明文数据包，只要参数正确也可发挥作用。最后通过该漏洞和其他漏洞配合，成功登入其他用户账户。如图2.49所示为构造明文数据包进行请求的过程。

我们建议：各大交易所在传输口令信息时使用加密传输的方式，且最好不要留下加密算法的明显线索（加密用何种算法，密钥是什么等），保障信息安全。

2.用户登录过程测试

爆破（暴力破解）指使用大量可能有效的潜在答案一一尝试，最后留下确实有效的答案的攻击手法。爆破虽然比较“笨”，但却经常有效；虽然常有奇效，但也确实要和其他方法组合使用才能发挥作用。

图　2.49

我们团队对某交易所进行安全测试时，发现该交易所某交易的账号登录处存在问题，虽然限制每个用户的登录试错次数，但并不限制同一IP对不同用户尝试登录的请求数量。我们的研究员随即对该交易所实施了撞库攻击，最终成功破解出部分用户口令，如图2.50所示。

我们建议：各大交易所在登录页面应同时使用图形或更复杂的验证码；对同一IP发出的请求频率和数量进行限制。

3.验证码策略

验证码在某些情况下有着极强的保护安全的作用，但若使用不当或有所疏漏，也会留下安全隐患。有了验证码，看似放心了不少，但其实它有可能只是一件“皇帝的新衣”。我们团队在对某交易所进行安全测试时发现，该交易所在手机登录处需要向用户发送验证码并进行校验，验证码长度为6位，貌似安全性较高，但实则具有递增趋势且递增速度缓慢，爆破验证码时可以轻易确认当前验证码所在范围，如图2.51所示。对于交易所来说，这样的验证码机制就是“皇帝的新衣”；对于攻击者来说，更降低了攻击成本，提高了攻击效率。

图　2.50

我们建议：各大交易所使用验证码来保障自身安全时，应使用随机多位的验证码，有条件的话最好使用字母和数字混杂的高强度验证码，并限制验证码输入错误的次数，采取一定措施。