本篇文章给大家谈谈接口api安全管理,以及api接口安全措施对应的知识点,希望对各位有所帮助,不要忘了收藏本站喔。
今天给各位分享接口api安全管理的知识,其中也会对api接口安全措施进行解释,如果能碰巧解决你现在面临的问题,别忘了关注本站,现在开始吧!
本文目录一览:
如何保证API接口安全?
在实际的业务开发过程中,我们常常会碰到需要与第三方互联网公司进行技术对接,例如支付宝支付对接、微信支付对接、高德地图查询对接等等服务,如果你是一个创业型互联网,大部分可能都是对接别的公司api接口。
当你的公司体量上来了时候,这个时候可能有一些公司开始找你进行技术对接了,转变成由你来提供api接口,那这个时候,我们应该如何设计并保证API接口安全呢?
最常用的方案,主要有两种:
其中 token 方案,是一种在web端使用最广的接口鉴权方案,我记得在之前写过一篇《手把手教你,使用JWT实现单点登录》的文章,里面介绍的比较详细,有兴趣的朋友可以看一下,没了解的也没关系,我们在此简单的介绍一下 token 方案。
从上图,我们可以很清晰的看到,token 方案的实现主要有以下几个步骤:
在实际使用过程中,当用户登录成功之后,生成的token存放在redis中时是有时效的,一般设置为2个小时,过了2个小时之后会自动失效,这个时候我们就需要重新登录,然后再次获取有效token。
token方案,是目前业务类型的项目当中使用最广的方案,而且实用性非常高,可以很有效的防止黑客们进行抓包、爬取数据。
但是 token 方案也有一些缺点!最明显的就是与第三方公司进行接口对接的时候,当你的接口请求量非常大,这个时候 token 突然失效了,会有大量的接口请求失败。
这个我深有体会,我记得在很早的时候,跟一家中、大型互联网公司进行联调的时候,他们提供给我的接口对接方案就是token方案,当时我司的流量高峰期时候,请求他们的接口大量报错,原因就是因为token失效了,当token失效时,我们会调用他们刷新token接口,刷新完成之后,在token失效与重新刷新token这个时间间隔期间,就会出现大量的请求失败的日志,因此在实际API对接过程中,我不推荐大家采用 token方案。
接口签名,顾名思义,就是通过一些签名规则对参数进行签名,然后把签名的信息放入请求头部,服务端收到客户端请求之后,同样的只需要按照已定的规则生产对应的签名串与客户端的签名信息进行对比,如果一致,就进入业务处理流程;如果不通过,就提示签名验证失败。
在接口签名方案中,主要有四个核心参数:
其中签名的生成规则,分两个步骤:
参数2加密结果,就是我们要的最终签名串。
接口签名方案,尤其是在接口请求量很大的情况下,依然很稳定。
换句话说,你可以将接口签名看作成对token方案的一种补充。
但是如果想把接口签名方案,推广到前后端对接,答案是:不适合。
因为签名计算非常复杂,其次,就是容易泄漏appsecret!
说了这么多,下面我们就一起来用程序实践一下吧!
就像上文所说,token方案重点在于,当用户登录成功之后,我们只需要生成好对应的token,然后将其返回给前端,在下次请求业务接口的时候,需要把token带上。
具体的实践,也可以分两种:
下面,我们介绍的是第二种实现方式。
首先,编写一个jwt 工具。
接着,我们在登录的时候,生成一个token,然后返回给客户端。
最后,编写一个统一拦截器,用于验证客户端传入的token是否有效。
在生成token的时候,我们可以将一些基本的用户信息,例如用户ID、用户姓名,存入token中,这样当token鉴权通过之后,我们只需要通过解析里面的信息,即可获取对应的用户ID,可以省下去数据库查询一些基本信息的操作。
同时,使用的过程中,尽量不要存放敏感信息,因为很容易被黑客解析!
同样的思路,站在服务端验证的角度,我们可以先编写一个签名拦截器,验证客户端传入的参数是否合法,只要有一项不合法,就提示错误。
具体代码实践如下:
签名工具类 SignUtil :
签名计算,可以换成 hamc 方式进行计算,思路大致一样。
上面介绍的token和接口签名方案,对外都可以对提供的接口起到保护作用,防止别人篡改请求,或者模拟请求。
但是缺少对数据自身的安全保护,即请求的参数和返回的数据都是有可能被别人拦截获取的,而这些数据又是明文的,所以只要被拦截,就能获得相应的业务数据。
对于这种情况,推荐大家对请求参数和返回参数进行加密处理,例如RSA、AES等加密工具。
同时,在生产环境,采用 https 方式进行传输,可以起到很好的安全保护作用!
如何确保API接口安全呢?
目前大量互联网公司和传统软件公司都在项目上大量采用前后端分离,这也是体现 社会 化分工更加明晰,Web端、App端和小程序 都涉及调用后端接口,传输的时候如何防止被抓包、偷窥、伪造、超时、重放。
token授权认证:防止未授权用户获取数据、时间戳:防止超时重放、签名:防止数据篡改
HTTPS:防止数据明文传输
如果时间差大于一定时间(比如:1分钟),则认为该请求失效,防止超时重放
比如queryString、header、body,将它们按顺序拼接成一个字符串,然后使用秘钥签名,防止数据被篡改。如果传输不敏感信息,仅仅为了防篡改,可以使用签名;
每次HTTP请求,都需要加上timestamp参数,然后把timestamp和其他参数一起进行数字签名。因为一次正常的HTTP请求,从发出到达服务器一般都不会超过60s,所以服务器收到HTTP请求之后,首先判断时间戳参数与当前时间相比较,是否超过了60s,如果超过了则认为是非法的请求。
每次请求生成一个唯一流水号,存放到缓存中,如果下次再使用相同的流水号请求就拒绝,防重放
HTTP协议是以明文方式发送内容,因此不适合传输一些敏感信息
HTTPS在HTTP的基础上加入了SSL协议,SSL依靠证书来验证服务器的身份,并为客户端和服务器之间的通信加密
APP比较特殊,攻击者可以反编译源码,所以不可以在APP中存放秘钥,曾经见过有公司APP使用OAuth的Client Credential授权方式,将ClientID和ClientSecret存放在APP端,app启动时获取Token,肯定不安全应该使用APP使用者的用户名密码登录获取Token,配合使用签名、时间戳、流水号、HTTPS
API接口常见的安全问题
1.接口被恶意调用
(1)我们可以使用timestamp,传递时间戳的方法来解决。在服务层对接口传递过来的时间戳和当前时间作比较,比如设定这条请求有效期为60s。
(2)对timestamp进行必要的加密处理,防止攻击者对timestamp进行模拟攻击。
2.接口数据被篡改
(1)使用sign签名机制,把上传的接口参数的数据进行加密,生成一个sign签名。服务器端用相同的算法对签名进行验证,保证数据一致性。
(2)加密算法比如:sign = md5(md5(a=1120)+md5(b=1144)),a,b为具体上传的出数据。
3.接口敏感数据被窃取
对上传这些敏感数据进行加密处理,比如密码等数据。加密算法尽量复杂点,后端处理可以加盐处理(salt),来进一步提高加密的级别。
最后我们还可以直接使用https协议,来增强api的安全性。
08.如何保证API接口的安全性问题01
1.互联网Api接口到底如何保证安全性问题?
2.代码落地实战防御XSS、CSRF攻击
3.代码落地如何防御接口数据被黑客抓包篡改?
4.接口数据加密对称还是非对称加密好
XSS攻击通常指的是通过利用 网页 开发时留下的漏洞,通过巧妙的方法注入恶意指令代码到网页,使用户加载并执行攻击者恶意制造的网页程序。这些恶意网页程序通常是JavaScript,但实际上也可以包括 Java 、 VBScript 、 ActiveX 、 Flash 或者甚至是普通的HTML。攻击成功后,攻击者可能得到包括但不限于更高的权限(如执行一些操作)、私密网页内容、会话和cookie等各种内容。 [1]
脚本攻击:利用JavaScript 注入 到后台数据库中,在通过展示数据加载该脚本 该脚本中(
1.使用js获取cookie信息(jwt)
2.将该jwt数据 上传黑客服务器(ajax)
)
获取jwt---用户会话信息 让后模拟请求形式使用该jwt登录。
xss攻击典型网站:论坛、评论区
getUserInfo?userName=
getUserInfo?userName=
前端传递 js 脚本到服务器端
后端接口将该脚本存放数据库中
前端html
将用户前端所提交的参数进行过滤。
html 大于 小于号 <
该方式的缺陷:每个参数都需要像这样写 代码非常冗余
接口接受参数 ?传递参数形式---
传递参数都是json数据形式
spring mvc 接受 json数据提供 api回调
1.可以使用第三方抓包工具,对请求前后实现代理,可以修改参数请求内容和参数响应内容,抓包工具http调试工具
2.Fiddler4下载地址:https://pc.qq.com/detail/10/detail_3330.html
使用Fiddler4篡改请求之前:
使用MD5可以直接验证签名参数 MD5 属于单向加密,只能够暴力破解。
MD5应用场景 在nacos分布式配置中心中,使用MD5 比对文件内容是否发生改变
HasherPro比对文件内容是否发生改变。
MD5在线暴力破解地址:https://www.cmd5.com/
String userName= "123456" ;
System. out .println( DigestUtils. md5Hex (userName));
黑客如何破解?自己需要根据参数内容 生成签名
如果只是改了参数内容---没有用的 所以我们需要该签名
{"password":"123456","phoneNumber":"phoneNumber","channel":"安卓","equipment":""}
{sign=325ab041d4889825a46d1e1e802ab5de, timestamp=1652537015771}
关于接口api安全管理和api接口安全措施的介绍到此就结束了,不知道你从中找到你需要的信息了吗 ?如果你还想了解更多这方面的信息,记得收藏关注本站。
接口api安全管理的介绍就聊到这里吧,感谢你花时间阅读本站内容,更多关于api接口安全措施、接口api安全管理的信息别忘了在本站进行查找喔。
版权声明:本文内容由网络用户投稿,版权归原作者所有,本站不拥有其著作权,亦不承担相应法律责任。如果您发现本站中有涉嫌抄袭或描述失实的内容,请联系我们jiasou666@gmail.com 处理,核实后本网站将在24小时内删除侵权内容。
暂时没有评论,来抢沙发吧~