API安全设计

方案一 (客户端token方式)
客户端生成token传给服务端校验,一致就通过用户验证。 通过时间戳+用户唯一标识+MD5加密=token(算法自定义),并且把时间戳传给后台,后台通 过后台系统的时间戳和客户端传过去的时间戳可以规定当前用户在1分钟内这次接口可以正常使用,也就是 说,当黑客从路由获取到连接后,只有1分钟的时间可以使用这次接口(时间后台可以自定义),这样很大程度 上确保了接口的安全性,同时,这种方式也可以有效的解决用户登入过期,也就是使用session的方式的不足,但是有个问题,如果客户端和服务端系统时间不一致,就不能这样用了,所以这个时间戳如何获取,也是一个关键点,可能通过接口从后台接口获取,也可以使用其他方式,有好的建议可以一起探讨

方案二 (服务端token方式-session)
这种方式用得是最多的,但是有个前提,用户登入接口一定要安全,也就是各种加密处理登入,后台返回sessionId作为token,客户端携带token命牌请求接口,后台从session中拿到sessionId和参数中的sessionId去验证一致性通过用户验证,这样其他人就算拿到这个链接通过其他客户端去调接口是不会成功的,因为每个客户端的session是不一样的,那么这种方式的缺点就是sessin过期的问题,客户端用户调接口时有可能登入已经过期了,解决的办法就是接口规范了,也就是后台要返回用户登入是否过期的字段,客户端通过这个字段判断是否跳转到登入页面。这种处理方式也是和网站的处理方式差不多一致的
以上两种方式是用户需要登入APP的用户数据安全问题解决办法
另外,对于接口参数加密处理是一般性的安全问题,以免太多数据信息暴露给外界,防止别人篡改参数拿去调接口,所以参数加密再配合上述两种方式去做接口安全,是很有意义的。

在app开放接口api的设计中,避免不了的就是安全性问题,因为大多数接口涉及到用户的个人信息以及一些敏感的数据,所以对这些接口需要进行身份的认证,那么这就需要用户提供一些信息,比如用户名密码等,但是为了安全起见让用户暴露的明文密码次数越少越好,我们一般在web项目中,大多数采用保存的session中,然后在存一份到cookie中,来保持用户的回话有效性。但是在app提供的开放接口中,后端服务器在用户登录后如何去验证和维护用户的登陆有效性呢,以下是参考项目中设计的解决方案,其原理和大多数开放接口安全验证一样,如淘宝的开放接口token验证,微信开发平台token验证都是同理。

签名设计

对于敏感的api接口,需使用https协议

https是在http超文本传输协议加入SSL层,它在网络间通信是加密的,所以需要加密证书。
https协议需要ca证书,一般需要交费。

签名的设计

原理:用户登录后向服务器提供用户认证信息(如账户和密码),服务器认证完后给客户端返回一个Token令牌,用户再次获取信息时,带上此令牌,如果令牌正取,则返回数据。对于获取Token信息后,访问用户相关接口,客户端请求的url需要带上如下参数:

时间戳:timestamp
Token令牌:token

然后将所有用户请求的参数按照字母排序(包括timestamp,token),然后更具MD5加密(可以加点盐),全部大写,生成sign签名,这就是所说的url签名算法。然后登陆后每次调用用户信息时,带上sign,timestamp,token参数。
例如:原请求https://www.andy.cn/api/user/update/info.shtml?city=北京 (post和get都一样,对所有参数排序加密)
加上时间戳和token
https://www.andy.cn/api/user/update/info.shtml?city=北京&timestamp=12445323134&token=wefkfjdskfjewfjkjfdfnc
然后更具url参数生成sign
最终的请求如
https://www.andy.cn/api/user/update/info.shtml?city=北京&timestamp=12445323134&token=wefkfjdskfjewfjkjfdfnc&sign=FDK2434JKJFD334FDF2

其最终的原理是减小明文的暴露次数;保证数据安全的访问。
具体实现如下:

  1. api请求客户端想服务器端一次发送用用户认证信息(用户名和密码),服务器端请求到改请求后,验证用户信息是否正确。
    如果正确:则返回一个唯一不重复的字符串(一般为UUID),然后在Redis(任意缓存服务器)中维护Token----Uid的用户信息关系,以便其他api对token的校验。
    如果错误:则返回错误码。

2.服务器设计一个url请求拦截规则
(1)判断是否包含timestamp,token,sign参数,如果不含有返回错误码。
(2)判断服务器接到请求的时间和参数中的时间戳是否相差很长一段时间(时间自定义如半个小时),如果超过则说明该 url已经过期(如果url被盗,他改变了时间戳,但是会导致sign签名不相等)。
(3)判断token是否有效,根据请求过来的token,查询redis缓存中的uid,如果获取不到这说明该token已过期。
(4)根据用户请求的url参数,服务器端按照同样的规则生成sign签名,对比签名看是否相等,相等则放行。(自然url签名 也无法100%保证其安全,也可以通过公钥AES对数据和url加密,但这样如果无法确保公钥丢失,所以签名只是很大程 度上保证安全)。
(5)此url拦截只需对获取身份认证的url放行(如登陆url),剩余所有的url都需拦截。

3.Token和Uid关系维护
对于用户登录我们需要创建token--uid的关系,用户退出时需要需删除token--uid的关系。

最后编辑于
©著作权归作者所有,转载或内容合作请联系作者
  • 序言:七十年代末,一起剥皮案震惊了整个滨河市,随后出现的几起案子,更是在滨河造成了极大的恐慌,老刑警刘岩,带你破解...
    沈念sama阅读 203,271评论 5 476
  • 序言:滨河连续发生了三起死亡事件,死亡现场离奇诡异,居然都是意外死亡,警方通过查阅死者的电脑和手机,发现死者居然都...
    沈念sama阅读 85,275评论 2 380
  • 文/潘晓璐 我一进店门,熙熙楼的掌柜王于贵愁眉苦脸地迎上来,“玉大人,你说我怎么就摊上这事。” “怎么了?”我有些...
    开封第一讲书人阅读 150,151评论 0 336
  • 文/不坏的土叔 我叫张陵,是天一观的道长。 经常有香客问我,道长,这世上最难降的妖魔是什么? 我笑而不...
    开封第一讲书人阅读 54,550评论 1 273
  • 正文 为了忘掉前任,我火速办了婚礼,结果婚礼上,老公的妹妹穿的比我还像新娘。我一直安慰自己,他们只是感情好,可当我...
    茶点故事阅读 63,553评论 5 365
  • 文/花漫 我一把揭开白布。 她就那样静静地躺着,像睡着了一般。 火红的嫁衣衬着肌肤如雪。 梳的纹丝不乱的头发上,一...
    开封第一讲书人阅读 48,559评论 1 281
  • 那天,我揣着相机与录音,去河边找鬼。 笑死,一个胖子当着我的面吹牛,可吹牛的内容都是我干的。 我是一名探鬼主播,决...
    沈念sama阅读 37,924评论 3 395
  • 文/苍兰香墨 我猛地睁开眼,长吁一口气:“原来是场噩梦啊……” “哼!你这毒妇竟也来了?” 一声冷哼从身侧响起,我...
    开封第一讲书人阅读 36,580评论 0 257
  • 序言:老挝万荣一对情侣失踪,失踪者是张志新(化名)和其女友刘颖,没想到半个月后,有当地人在树林里发现了一具尸体,经...
    沈念sama阅读 40,826评论 1 297
  • 正文 独居荒郊野岭守林人离奇死亡,尸身上长有42处带血的脓包…… 初始之章·张勋 以下内容为张勋视角 年9月15日...
    茶点故事阅读 35,578评论 2 320
  • 正文 我和宋清朗相恋三年,在试婚纱的时候发现自己被绿了。 大学时的朋友给我发了我未婚夫和他白月光在一起吃饭的照片。...
    茶点故事阅读 37,661评论 1 329
  • 序言:一个原本活蹦乱跳的男人离奇死亡,死状恐怖,灵堂内的尸体忽然破棺而出,到底是诈尸还是另有隐情,我是刑警宁泽,带...
    沈念sama阅读 33,363评论 4 318
  • 正文 年R本政府宣布,位于F岛的核电站,受9级特大地震影响,放射性物质发生泄漏。R本人自食恶果不足惜,却给世界环境...
    茶点故事阅读 38,940评论 3 307
  • 文/蒙蒙 一、第九天 我趴在偏房一处隐蔽的房顶上张望。 院中可真热闹,春花似锦、人声如沸。这庄子的主人今日做“春日...
    开封第一讲书人阅读 29,926评论 0 19
  • 文/苍兰香墨 我抬头看了看天上的太阳。三九已至,却和暖如春,着一层夹袄步出监牢的瞬间,已是汗流浃背。 一阵脚步声响...
    开封第一讲书人阅读 31,156评论 1 259
  • 我被黑心中介骗来泰国打工, 没想到刚下飞机就差点儿被人妖公主榨干…… 1. 我叫王不留,地道东北人。 一个月前我还...
    沈念sama阅读 42,872评论 2 349
  • 正文 我出身青楼,却偏偏与公主长得像,于是被迫代替她去往敌国和亲。 传闻我的和亲对象是个残疾皇子,可洞房花烛夜当晚...
    茶点故事阅读 42,391评论 2 342

推荐阅读更多精彩内容