开发者保证产品数据和业务安全是基本责任之一。我工作以来从事开发以娱乐、社交、内容产业的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=abcdefg，该接口有uid、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值，若与当前时间相差太久也视为过期请求。

结束语：移动应用网络安全的防范介绍了大部分，其实还有很多需要我们去注意去解决的问题。和做架构一样，项目的安全性不是靠设计出来而是一步一步随着项目壮大而完善的。如果你的产品还没有遇到攻击或者还没有做安全措施，这篇文章应该会对你有帮助。