程序安全设计与Android后台接口安全设计

一个大型系统在设计过程中考虑的安全问题包括三个方面,第一传输安全,第二存储安全,第三权限控制。刚开始我想传输安全就是将敏感字段进行加密传输,后来发现还是太年轻,如果要在传输过程中实现数据安全第一必须做的是接口设计的更加安全,那么接口怎么才算安全,首先我们说说接口设计中面临的安全有以下几种情况:
第一:别人获取到你的请求接口,然后用脚本一直恶意请求你的服务器。
第二:别人篡改接口参数访问服务器骗取用户数据
第三:别人获取到你的请求接口,从response中得到了用户数据。
针对上面情况我给出下面的解决方案每个请求接口中必须包含签名(计算方法见下面)、时间戳和服务端分配给app的consumer_key,和现实生活中一样,只有签上你的名字,签上时间这个文件你才承认了,签名具有不可否认性和认证(防止攻击者伪装成真正的发送者),所以时间戳也参与了签名,另外后台可以设置如果当前请求的时间戳与服务端时间戳相差半小时之内并且签名合法则属于合法请求否则即使签名一致我认为你的请求不对,让客户端重新请求,(在开发过程中把这个代码注释掉方便客户端调试,上线之后释放)。如果别人知道了你的签名算法,服务端可以进行白名单和黑名单的限制,这是防止别人恶意请求的接口处理方式。
传输过程中敏感信息我们不能用明文,那么加密算法如何选择呢,md5摘要不属于加密,因为不可逆,所以此处不考虑,常见的加密算法有三种第一:一次性密码,第二:非对称加密, 第三:对称加密。一次性密码是最安全的,程序里面是重来不用的,因为这个密码用过之后就不用了,一次性密码密钥的传递也是人工传递(特工),用过之后废弃,非对称加密由于效率和性能等的问题一般不怎么用只有支付宝的加密方式RSA加密,其它程序中很少见到非对称加密,大部分的全是对称加密,对称加密算法的特点是算法公开、计算量小、加密速度快、加密效率高。我认为对称加密还有一个好处就在于加解密的高速度和使用长密钥的难破解性。58同城的加密方式也是对称加密,现附上一个58接口链接:http://app.58.com/api/detail/cat/26728112367433?appId=3&format=json&localname=cd&platform=android&version=9.2.5 我们很明显看出他的敏感字段全是经过处理的。对称加密最流行用的最多的就属于AES了,服务端和客务端共用一个密钥,当然如果密钥泄漏的话用户数据还是会泄漏的,所以这就涉及到了存储安全的问题,我在下一个标题会讲。这样接口中的数据就不会出现泄漏。

存储安全

首先我为们要明白为什么存储东西也要考虑安全问题呢,就是怕别人看见你的字段,所以我们要做到不让别人看你的代码,Android端上线的app要对代码进行混淆,还要给应用程序加壳让大部分人根本无法反编译我们的app,其次我们的密码或者密钥不存储在java层和so层,so文件中对密钥进行加解密操作,将密钥加密后的密钥命名为其他普通文件,存放在assets目录下或者其他目录下,接着在so文件里面添加无关代码,这样可以可以增加静态分析难度。更好的避免被攻击。
另外网上经常报出有几个G的资料被泄漏了,为什么会出现这种情况了,我感觉一个原因就是数据库中关键字段不是采用的密文存储,有的人可能会说如果数据库里面存储的是密文的话,服务端压力会变大,,使系统不堪重负。事实并非如此。如果在数据库客户端进行数据加/脱密运算,对数据库服务器的负载及系统运行几乎没有影响。另外对字段加密防止数据库管理员和开发人员泄漏数据,即使数据库被盗也是秘文。当然这个算法要好好设计

签名计算方法

1.将所有参数(签名除外)按照参数名的字母顺序排序,并用 & 连接(eg. consumer_key=7284397484&timestamp=1374908054)得到字符串A

  1. url + 字符串A+ consumer_secret得到字符串B, 对字符串B用UTF-8 Encode之后计算HEX值字符串(用HEX Encode),得到字符串C,
  2. 对 字符串C 计算SHA1哈希,得到签名.
「点点赞赏,手留余香」

    还没有人赞赏,快来当第一个赞赏的人吧!
0 条回复 A 作者 M 管理员
    所有的伟大,都源于一个勇敢的开始!
欢迎您,新朋友,感谢参与互动!欢迎您 {{author}},您在本站有{{commentsCount}}条评论