独家供稿：移动Labs

通过前面十讲的讲述，我们已经将业务安全的基本方面都说了一遍。之后下面的几讲我们就一些具体的实例进行分析，说明一些业务安全的典型问题。我们还是从上一讲说明的业务安全问题分析的几个方面来入手，首先谈一谈业务的入口造成的安全问题。

       我 们一般常用的业务入口包括：用户注册、用户登录、用户取回密码、用户投诉与举报。入口是最容易接触到的环节，也是最常受到攻击的地方。一般来说，业务设计 者比较注重的安全防护在用户注册验证、用户登录验证环节，其中最常见的就是设置强口令、图片验证码等安全机制，并在传输时使用加密方式保证不泄密。但即使 这样，一不留神还是会出现问题。

我们还是先从简单的案例开始讲起，但在业务完全没有防护的情况下实施的攻击（例如大家已经非常了解的暴力破解攻击、普通的局域网窃取明文攻击等）我们就不再说了，我们对一些已经经过安全设计的案例进行分析。下面我们来看wooyun上的这样一个案例，与分析无关的部分我进行了截取，详细情况可以看http://www.wooyun.org/bugs/wooyun-2010-05209。

 —————————————————————————————————

支付宝控件登陆数据：

可以看到用户名是明文，口令密文。据分析口令密文十六进制形式，长度是16的整数倍字节。如果输入密码1234567812345678，得到的密文是32字节，且前后16字节相等。很显然这是个8 byte的分组密码加密算法，符合3des加密算法的推测。既然是加密，肯定要有密钥。但是可以看到登陆前没密钥协商或密钥分配的过程，那么密钥要么在登陆数据中，要么就是固定密钥。经过不同时间不同多次发现口令密文永远不变，那么支付宝安全控件登陆将无法避免重放攻击。

不用去研究复杂的加密算法，不用去寻找解密密钥。只要把password参数的值替换成成功登陆时的口令密文，就能骗过认证服务器正确登陆了。攻击方法使用Burp proxy的intercept功能，收到浏览器登陆请求包后修改相应字段数据，然后再forward给服务器。注意，如果数据长度发送了变化，请相应修改HTTP content-length。

—————————————————————————————————

从 上述问题来看，白帽子首先进行了多次探测，发现了用户登录过程中一直使用的是同一个密文，存在重放攻击的风险。这是一个典型的业务设计问题，问题产生的原 因在于业务的设计者不完全了解安全，以为进行加密之后就不能攻击，但没有考虑到重放攻击的问题。这个问题相对比较简单，危害相对也较小，毕竟需要局域网去 窃取数据包。

我们在这里分析一下修复方案。在网页里面给了3个修复方案，通过给出的方案来看呢，我认为其实不太合理，里面提到的方案都需要进行公钥加密或密钥协商，这对业务来说相对改动比较大。我认为比较简单的方法是密钥仍然不变，由控件保护，参考httpdigest认证的方式，在每次登录的时候，服务器随机生成一个random数据（httpdigest里面是nounce值）和用户输入的口令一起进行加密，即加密（password&random）。这样服务器和控件的工作量都非常小，也保障了每次发出的password加密后的数据完全不同。

       该问题的产生很简单，完全是由业务设计不周造成，很具备代表性；我另外还发现一个很有意思的支付宝认证漏洞http://www.wooyun.org/bugs/wooyun-2010-02757，这个漏洞更严重。但这个漏洞非常容易理解，其出现也非常偶然，应该不具备代表性，因此我就不专门分析了，大家看看就知道了。不过可以说明，业务在任意一个环节都可能存在安全问题，我们不能有任何大意。

好了，今天就先到这里，下期再见。

粟栗