查看: 2531|回复: 25

手机客户端开发中的“恶意代理”攻击分析

[复制链接]
发表于 2013-4-5 10:13:21 | 显示全部楼层 |阅读模式

设计HTTP安全的时候,恶意代理是需要考虑到的很重要的一环,尤其在这个“Wifi横行”的年代。一个酒店、商厦中不怀好意的免费Wifi节点,可能就会让用户在使用客户端的过程中,泄漏密码、资金等重要信息。

本文从常见恶意代理的几种攻击方式出发,谈一谈如何在安全设计上避免被恶意代理攻击。

一、报文纂改

这个是攻击力比较小的方式,只要稍有一些安全意识,就容易防范。典型的攻击方式是通过恶意代理截取到一段明文请求,分析请求格式,然后对其中的一些参数进行修改,再向模拟用户向服务器请求。通过这种方式,可以很容易地破坏用户在服务器上的私有数据。比如,用户本意是发送一个删除某条信息的命令,恶意代理把用户发送的命令修改为清除所有信息。

对这种报文纂改的攻击,我们可以通过对请求报文进行摘要即可防范。

二、重放攻击

这个主要是针对服务器的攻击。服务器中总有那么一些API是性能消耗比较大的,或是为了安全,或是业务比较复杂。恶意代理很可能会截取到用户的一个请求之后,向服务器不停地发送该请求,进行“拒绝服务”攻击,如果服务器对请求无法签别,就会影响对正常用户的服务。对于这种重放攻击,我们可以通过在请求中添加随机数验证来设置请求时效性的方式来解决。有几种具体的手段可以借鉴:

1、服务器与客户端在第一次请求时进行一次时间同步,客户请求时随机数取请求的当前时间,服务器根据客户端的时间是否与服务器的时间相差太多来判断是否重放攻击。这种方式很容易实现,但由于客户端与服务器的网络交互存在时间差,时效性会稍差。

2、每次请求服务器在响应时带回下一次请求的随机数,服务器把随机数和正常请求数据一起进行摘要。服务器对每个请求进行验证,如果随机数不正常,则属于重放攻击,判定该请求无效。但这种方式对付比较简单的恶意代理还可以,更强大的恶意代理可以拦截到这个随机数。这种方式最大的问题是无法进行并发请求的验证。

3、客户端和服务器利用共享密钥来为每次请求生成随机数。比如安全硬件等,服务器还可以为每个客户端生成一个对应密钥,客户端在发送请求时利用密钥生成随机数,并在请求中包含自己的AppKey。服务器接收到请求时,根据该客户端的AppKey查询到该客户端的密钥,再利用密钥生成对应的随机数,如果该随机数与客户端发送过来的相同,则请求正常,否则,可判断该请求为重放攻击。这种方式的缺点是一旦客户端的AppSecret被破解,则安全荡然无存。

三、密码破解

这种攻击主要以获取用户的密码等身份认证信息为主。可能有以下几种方式:

1、对HTTPS连接,通过恶意代理对安全证书做替换。如果设计上太多依赖HTTPS安全性,利用HTTP发送的信息不加密的话,很容易被恶意代理截获并分析出用户的原始密码。

2、对于简单的密码摘要信息认证方式,恶意代理可以在拦截到摘要后利用词典进行暴力破解。对于请求中有随机数的摘要,恶意代理可以模拟服务器向客户端响应一个随机数,然后对拦截到的客户端请求进行暴力破解。

恶意代理在无线互联网上的破坏性要远大于传统互联网,而安全问题从来也不是一蹴而就的,我们需要在设计时尽量在安全、便捷、性能之间做更慎重的权衡,从多方面一起下手来保护我们的用户。


发表于 2013-4-5 17:23:44 | 显示全部楼层
提示: 作者被禁止或删除 内容自动屏蔽
发表于 2013-4-6 13:43:14 | 显示全部楼层
长时间没来看了 ~~  
发表于 2013-4-7 13:40:02 | 显示全部楼层
没人理我。。。。  
发表于 2013-4-8 04:49:40 | 显示全部楼层
正好你开咯这样的帖  
发表于 2013-4-10 01:35:11 | 显示全部楼层
一定要回贴,因为我是文明人哦  
发表于 2013-4-10 20:41:23 | 显示全部楼层
发贴看看自己积分  
发表于 2013-4-11 10:16:22 | 显示全部楼层
不错不错,我喜欢看  
发表于 2013-4-11 12:43:07 | 显示全部楼层
谢谢楼主  。。。。。。
发表于 2013-4-12 02:05:14 | 显示全部楼层
不错不错,我喜欢看  
高级模式
B Color Image Link Quote Code Smilies

本版积分规则