api接口的安全性（api接口安全性测试）

本篇文章给大家谈谈api接口的安全性，以及api接口安全性测试对应的知识点，希望对各位有所帮助，不要忘了收藏本站喔。 今天给各位分享api接口的安全性的知识，其中也会对api接口安全性测试进行解释，如果能碰巧解决你现在面临的问题，别忘了关注本站，现在开始吧！

本文目录一览：

• 1、如何保证API接口安全？
• 2、08.如何保证API接口的安全性问题01
• 3、开放平台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 方式进行传输，可以起到很好的安全保护作用！

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接口，类似 http://mypay.com/refund/order_id=123mch_id=123 ，这个请求api接口的安全性我以商户mch_id=123的身份给订单号为order_id=123退款，如果服务器不辩别请求发起者的身份直接做相应的操作，那是及其危险的。

一般的，在PC端，我们是通过加密的cookie来做会员的辨识和维持会话的api接口的安全性；但是cookie是属于浏览器的本地存储功能。APP端不能用，所以我们得通过token参数来辨识会员；而这个token该如何处理呢api接口的安全性？
延伸开来，接口的安全性主要围绕Token、Timestamp和Sign三个机制展开设计，保证接口的数据不会被篡改和重复调用。

一般来说，在前端对数据做加密或者前面，是不现实的。前后端使用HTTP协议进行交互的时候，由于HTTP报文为明文，所以通常情况下对于比较敏感的信息可以通过在前端加密，然后在后端解密实现"混淆"的效果，避免在传输过程中敏感信息的泄露（如，密码，证件信息等）。不过前端加密只能保证传输过程中信息是‘混淆’过的，对于高手来说，打个debugger，照样可以获取到数据，并不安全，所谓的前端加密只是稍微增加api接口的安全性了攻击者的成本，并不能保证真正的安全。即使api接口的安全性你说在前端做了RSA公钥加密，也很有可能被高手获取到公钥，并使用该公钥加密数据后发给服务端，所以务必认为前端的数据是不可靠的，服务端要加以辩别。敏感信息建议上https。

所以一般建议上https，敏感信息md5混淆，前端不传输金额字段，而是传递商品id，后端取商品id对应的金额，将金额等参数加签名发送到支付系统。金额可以是明文的。

token授权机制 ：用户使用用户名密码登录后，后台给客户端返回一个token（通常是UUID），并将Token-UserId键值对存储在redis中，以后客户端每次请求带上token，服务端获取到对应的UserId进行操作。如果Token不存在，说明请求无效。
弊端 ：token可以被抓包获取，无法预防MITM中间人攻击

用户每次请求都带上当前时间的时间戳timestamp，服务器收到请求后对比时间差，超过一定时长（如5分钟），则认为请求失效。时间戳超时机制是防御DOS攻击的有效手段。

将token，timestamp等其他参数以字典序排序，再加上一个客户端私密的唯一id（这种一般做在服务端，前端无法安全保存这个id）或使用私钥签名，将前面的字符串做MD5等加密，作为sign参数传递给服务端。

地球上最重要的加密算法：非对称加密的RSA算法。公钥加密的数据，可以用私钥解密；私钥签名（加密）的数据，可以用公钥验签。

RSA原理是对极大整数做因数分解，以下摘自维基百科。

暂时比较忙没时间，将于7月29日晚更新。
来更新啦。
微信支付安全规范，可以查看官方文档 https://pay.weixin.qq.com/wiki/doc/api/jsapi.php?chapter=4_3
第1点中，其签名算法最重要的一步，是在最后拼接了商户私密的API密钥，然后通过md5生成签名，这时即使金额是明文也是安全的，如果有人获取并修改了金额，但是签名字段他是无法伪造的，因为他无法知道商户的API密钥。当然，除了微信支付的拼接API生成签名的方法，我们也可以通过java自带的security包进行私钥签名。其中nonce随机字符串，微信支付应该做了校验，可以防止重放攻击，保证一次请求有效，如果nonce在微信支付那边已经存在，说明该请求已执行过，拒绝执行该请求。

阮一峰老师的博客-RSA算法原理： http://www.ruanyifeng.com/blog/2013/07/rsa_algorithm_part_two.html
维基百科： https://zh.wikipedia.org/wiki/RSA%E5%8A%A0%E5%AF%86%E6%BC%94%E7%AE%97%E6%B3%95

关于api接口的安全性和api接口安全性测试的介绍到此就结束了，不知道你从中找到你需要的信息了吗 ？如果你还想了解更多这方面的信息，记得收藏关注本站。 api接口的安全性的介绍就聊到这里吧，感谢你花时间阅读本站内容，更多关于api接口安全性测试、api接口的安全性的信息别忘了在本站进行查找喔。

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