app和后端的通讯过程中,api请求有可能被别人截取或不小心泄露。那么,怎么保证api请求的安全呢?在这篇文章中,介绍一种常见的保证api请求安全的做法--url签名。
1. url签名详解
在前一篇文章<15.app后端怎么设计用户登录方案>中,服务器中验证用户名和密码都正确后,生成一个随机的不重复的token字符串(例如"daf32da456hfdh"),在redis或memcache中维护一个映视表,建立token字符串和用户信息的对应关系表,例如,把token字符串"daf32da456hfdh"和用户id"5"对应起来,服务器把token字符串返回给app用作身份验证。
这个身份验证是依赖于token字符串。如果用户泄露了自己的url, 那很大程度上token也被别人泄漏了。
怎么防止token被泄露?不让token在网络上传输就行。
注意,这个url签名的方法是和前面<15.app后端怎么设计用户登录方案>紧密联系在一起的,没看过前面一篇文章请先看。
(1) 服务器中验证用户名和密码都正确后,把token字符串和用户id都返回给客户端,例如token字符串"daf32da456hfdh"和用户id"5"。
(2)假设api请求为"test.com/user/info", 通过token字符串"daf32da456hfdh"生成md5签名后: md5("test.com/user/info&token=daf32da456hfdh”)= C99DC0C22437AC275C08CE4A9708B25A
于是,api请求加上签名和用户标识后就是 "test.com/user/info?userId=5&sign= C99DC0C22437AC275C08CE4A9708B25A"
(3)服务器接收到这个url后,用(2)的算法生成签名和sign参数对比,如果发现相等的话,就表示这个url是有有效,那就继续执行这个api调用。
用上面的这个方法,就能避免token在api调用时泄露。
上面的方法还有一个问题,因为这个api请求"test.com/user/info?userId=5&sign= C99DC0C22437AC275C08CE4A9708B25A"上没有过期时间,假设别人拿到这个api的请求,就能反复调用了。
改进方法是在传递的参数中增加时间戳,当发现这个时间戳离现在的时间已经很久了,就判断这个url已经失效了。
但用时间戳怎么保证app的时间和服务器的时间同步?在app每次启动时和服务器同步时间,然后在app内建一个时钟,时间戳在这个app的内部时钟获取,防止用户修改了手机的时间导致时间不一致。
于是有了下面的改进方法:
(1)假设api请求为"test.com/user/info", 用token字符串"daf32da456hfdh"和时间戳生成md5签名后: md5("test.com/user/info?userId=5&token=daf32da456hfdh×tamp=1425860757”)= C116161A6F430343B6CECF08562F1371
于是,api请求加上签名和用户标识后就是 "test.com/user/info?userId=5×tamp=1425860757&sign= C116161A6F430343B6CECF08562F1371"
(2)服务器接收到这个api请求,如果发现收到这个url请求的时间和time=1425860757相隔很久,就判断出这个url是被别人截取来反复调用了。如果时间合法,那就用(1)的算法再判断sign是否一致
2. url签名的不足之处
url签名有两个缺点:
1.当用户第一次登录后token是明文返回,有被截取的风险
2. url签名只能保护token值却没法保护其他敏感数据,例如,当用户更新自己的个人信息时,所有的信息在传输过程中应该是被加密的
怎么解决这两个问题?使用下篇介绍的对称加密的算法就可以了。
---------------------------------------------------------------------------------------------------------------------------
打开链接 app后端系列文章总目录 总目录 ,能查看本人发表过的所有原创“app后端”文章。
【作者】曾健生
【QQ】190678908
【app后端qq群】254659220
【微信公众号】 appbackend
【新浪微博】 @newjueqi
【博客】http://blog.csdn.net/newjueqi