app接口安全性设计浅析

之前面试的时候被问到这个，app接口安全性，这个因不同的场景，要考虑的情况也不一样。下面把自己的见闻和思考写一下吧。

（1）签名与加密
这个一般接口中会有的，典型的有MD5和AES。
一个接口形式是：
http://test.com/api/test.html?userId=9&timestamp=14324344&randomString=532sgdfg&sgin=GGERH5363463

sign=MD5(userId+timestamp+randomString)
timestamp 一般用来给服务器验证请求时间区间，5-30分钟不等。
randomString 作为签名的参数作用不大。
这个由于都是明文的，一般都能猜到这么签名。所以，会加一个盐，
sign=MD5(userId+timestamp+randomString+salt1)
salt1为客户端与服务端保留，是个常量。一般不在接口中传递。

有人说，将app放进模拟器或者反编译，就能获得salt1。

所以，光是一个常量是不够的，还要一个动态量。这个动态量就是token，一般在每次用户登录后，会获得一个刷新的token，UUID生成的。

http://test.com/api/test.html?userId=9&timestamp=14324344&randomString=532sgdfg&token=dfhfjgdfsgsdg&sgin=GGERH5363463

sign=MD5(userId+timestamp+randomString+salt1+token)
token的有效期一般为12小时或24小时。
这样，客户端的请求，服务端先验证token，再验证sign。

以上的处理，效果如下：

1. 较长时间段前的请求链接无效；
2. 不良用户把篡改的请求链接在浏览器中操作无效；
3. 每隔一段时间，有一个登录的验证。

但以上也看出，token验证的难度并不大，毕竟token的有效时间有十几个小时。

因此，本人设计添加了一个动态量，叫token2。
这个token2的有效期更短，一般在几十秒，假定30秒-45秒。也可以更短。
它由token1和salt1生成，不在客户端保留，每次接口请求都要从服务器拿。获取token2中也会用到AES加密。
然后把token2也放到sign签名中（接口中不传）：
sign=MD5(userId+timestamp+randomString+salt1+token+token2)

服务端原来验证token改为验证token2了，这样，如果不是极端情况，保证了2点：

1. 客户端的请求都是由APP端发出的；
2. 每次请求的有效期只有30-45秒。
   设置30-45秒是考虑到wap端的用户请求，点击，浏览的平均时间会稍微比app端慢一些。如果在一个网页，用户迟疑了一下再点击，发现链接失效，需要重新退回上个页面，不是太好，所以设定几十秒。

还有RSA也能签名。
当然，除了MD5，还有AES加密。AES也有加salt加密。由于是对称型，AES可以多次加密。可是只要salt知道，也能容易猜到，本人一般配合MD5使用。

（2）https
这个是要证书的，要钱的。本人还没做过。

（3）第三方授权。
大公司用的多，获取腾讯，新浪用户信息用这种方式。其中关键，是一个code和token，也是动态的，安全性，比以上介绍的要强一些。