APP 开发常见网络安全策略
开发者保证产品数据和业务安全是基本责任之一。我工作以来从事开发以娱乐、社交、内容产业的APP产品为主,这里总结一下自己用到或者了解的移动应用常见网络安全策略。
篡改数据
客户端通常会保存uid,访问接口时传入uid告诉服务器是谁访问。那么引出了最初级的安全问题,如果我们仅仅只信任uid那一旦修改这个参数值就可以篡改别的用户数据了。
使用token,在用户登录成功服务端返回uid和token,客户端访问服务器时提供这两个参数,uid区别唯一性,token验证合法性。这样即使修改了uid,对应的token不一致也无法成功。
使用https,https传输过程中数据是加密的,使用https可以防止用户在网络传输中途截取和修改。
https分单向和双向验证,简单说明这两个概念:单向验证即客户端确认服务端是真的,双向验证即在此基础上服务端验证客户端是真的。一些客户端开发者可能还做过忽略证书的https请求,其实就是忽略单向验证直接相信服务端是真的。
窃取数据
比如密码的重要性不言而喻,下面谈谈如何保证密码或重要数据不被泄露。
可还原加密。适用于如用户隐私、财产信息等需要还原的数据。对称加密,加解密使用的是同一个秘钥,推荐AES,除此外还有DES、DES3等。不对称加密,加解密使用不同秘钥,如RSA。
不可还原加密,也叫数据摘要。适用于如用户密码这样不需要还原的数据。如MD5、SHA1等。
用户密码管理 tips
1.在数据库只保存密码摘要
2.多次摘要,比如进行3次MD5,或者MD5后再进行一次SHA1摘要等方式混合摘要
3.加点salt(盐),有的攻击者收集常用的密码,然后对他们执行MD5或者 SHA1,使用大量数据做成庞大的数据字典,对泄露的数据库中的密码逐行对比,如果你的原始密码很不幸的被包含在这个数据字典中,那么就能把你的原始密码匹配出来。salt 是任意字母或数字的组合的随机字符串,每个用户注册时生成不同的salt,保存方式如md5(密码明文+salt)。使用https,在上面已经提过。这里再提一点就是https同时使用到了对称加密、非对称加密、信息摘要3个手段。有兴趣可以上网搜索https的基本原理。
模拟数据
如果攻击者知道你的接口参数,有可能模拟这些数据修改提交或者批量提交。例如攻击者中途拿到密码密文虽然他不知道这些是什么鬼,但是拿到这个参数直接丢给服务器依然是合法的,再例如一些批量刷抢购活动,或者有好事者没事对一个接口不断重复提交数据。防止这些行为其实问题就是如何对参数进行合法性、时效性设置问题。
图片、短信验证码。
参数签名机制。首先服务端和客户端各自保存一个key,客户端请求服务器时将所需参数按一定顺序排列+key组合字符串后摘要作为摘要参数一起提交到服务端,服务端将除摘要参数之外的参数按相同顺序排列+key组合字符串摘要,匹配摘要值,如果一致则是合法请求。拿获取我的资料接口举例:
1.服务端和客户端持有相同key=abcdefguid、token两个参数,我们需要增加一个timestamp参数,值为当前时间戳。假设uid=1,token=higklmn。
2.请求服务端时,按参数名字典序排序+key结果timestamp=1234567890&token=higklmn&uid=1&abcdefguid,对这串字符串进行sha1之后得到ee6ef06d0770306f8868f20d7678e14a031bd23e,作为一个新的参数sign.最终提交的参数有timestamp、token、uid、sign这四个。
3.服务端拿到参数后去掉除sign外的参数按照同样的方式排序组合摘要,得到的值和sign的值匹配,一致为合法。做了签名之后参数将无法修改,时效性就好判断了,服务端处理完业务后有需要的可以将sign值保存,下次有相同的sign视为已经处理过的请求,不再处理。还可以判断timestamp值,若与当前时间相差太久也视为过期请求。
结束语:移动应用网络安全的防范介绍了大部分,其实还有很多需要我们去注意去解决的问题。和做架构一样,项目的安全性不是靠设计出来而是一步一步随着项目壮大而完善的。如果你的产品还没有遇到攻击或者还没有做安全措施,这篇文章应该会对你有帮助。
作者 newO
关键字:产品经理, uid
版权声明
本文来自互联网用户投稿,文章观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如若转载,请注明出处。如若内容有涉嫌抄袭侵权/违法违规/事实不符,请点击 举报 进行投诉反馈!