解决API接口开发安全性的四种方案(Api安全)

网友投稿 2267 2022-09-02

解决API接口开发安全性的四种方案(Api安全)

解决API接口开发安全性的四种方案(Api安全)

如今各种API接口层出不穷,一个API的好与不好有很多方面可以考量,其中“安全性”是一个API接口最基本也是最重要的一个特点。尤其是对于充值缴费类的API接口来说,如话费充值API接口、流量充值API接口、游戏Q币充值、水电煤缴费接口等,安全与否直接影响到个人或企业的财产,所以做好API接口的安全性问题尤为重要,本篇文章我们就来聊聊关于API接口的安全性。

所谓接口,服务器端直接根据user_id来做相应的会员操作,这是非常危险的接口处理,等于把当前的会员系统给完全暴露出来,只要对方改一下user_id就可操作所有会员对应的接口。

一般在PC端,我们是通过加密的cookie来做会员的辨识和维持会话的;但是cookie是属于浏览器的本地存储功能。APP端不能用,所以我们得通过token参数来辨识会员;而这个token该如何处理呢?

在做接口加密前,我们先来看以下几个方案:

方案一:

与APP端开发人员约定特定的md5组合算法,然后两端比对一下,如果相同就allow,不相同就deny;但是,这也是不安全的,如果APP程序被反编译,这些约定的算法就会暴露,特别是在安卓APP中,有了算法,完全就可以模拟接口请求通过验证。

方案二:

会员登录的时候请求登录接口,然后服务器端返回给客户端一个token,该token生成的规则是 网站公钥 + 当前uid + 当前时间戳 + 一段随机数双重加密,根据需求决定是把该token放进cache等一段时间自动失效,还是放进数据库(如果要放进数据库的话,单独拎出一张表来,顺便记录用户的登录,登出时间),在用户登出登录的时候改变一下,确保该token只能在用户人为登出登录之间有用。

为保安全,应保证让用户在一段时间内自动退出;此方案配合Linux和数据库的权限管理可以防外又防内。

方案三

通过对称加密算法,该加密算法对uid+网站公钥进行时效加密,在一定时效内可用。在会员登录成功时,服务器端对该ID加密后返回给客户端,客户端每次请求接口的时候带上该参数,服务器端通过解密认证。

但是这样做,也是不安全的。因为,防外不防内,听说这次的携程宕机就是因为内部离职人员的恶意操作。内部不怀好意的人员如果知道相应的算法规则后,就算没有数据库权限,也可以通过接口来操作相关会员。

方案四:

数据库会员表的password是带上了随机密窜并经过双重加密的md5值;在用户登录的时候,我返回会员相应的uid和password,password虽然是明文的,别人知道也不能登录,毕竟是经过加密的,然后每次请求接口的时候,通过主键uid可以很快的找到当前uid对应的token,然后再来比对。

但是这样想法是too yang too simple的,抓包的人虽然不能通过密文密码来登录该会员,然而一旦知道了这个token,除非用户更改密码,否则也可以一直通过这个token来操作该会员的相关接口。

除了以上这些,数据格式最好使用jsON格式数据,因为JSON有较好的跨平台性。在生成JSON的时候,要注意json的两种格式:对象(字典)与 数组;mobile端开发语言中没有类似PHP中的foreach不能遍历对象,只能遍历数组,他们对对象的操作一般都是通过键名去取键值。不管是成功,还是失败。接口必须提供明确的数据状态信息,并且不能返回NULL,如果返回NULL的话,在IOS端会崩掉。

当然,我们了解到的有关 API 接口安全性问题的解决方案不止这些,一些开源项目以及博主介绍的落地方案都是值得大家学习和探索的,在实际的实践中只有多多思考总结,这样才能让开发出来的API变得更加强大。

版权声明:本文内容由网络用户投稿,版权归原作者所有,本站不拥有其著作权,亦不承担相应法律责任。如果您发现本站中有涉嫌抄袭或描述失实的内容,请联系我们jiasou666@gmail.com 处理,核实后本网站将在24小时内删除侵权内容。

上一篇:Vue学习之--------列表渲染、v-for中key的原理、列表过滤的实现(2022/7/13)
下一篇:多条件筛选,你用什么实现?(如何筛选多个条件)
相关文章

 发表评论

暂时没有评论,来抢沙发吧~