网站API接口被篡改（网站api接口被篡改如何处理）

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

本文目录一览：

• 1、如何确保API接口安全呢？
• 2、08.如何保证API接口的安全性问题01
• 3、API接口安全设计方案（已实现）
• 4、你开放的API接口真的安全吗
• 5、开放平台API接口安全性设计——微信支付为例

如何确保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

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接口安全两个方面考虑，数据加密https已经加密了，就不再次加密了；主要从api安全方面考虑。

在代码层面，对接口进行安全设计
一、使用token进行用户身份认证
二、使用sign防止传入参数被篡改
三、用时间戳防止暴力请求

用户身份认证的流程图如下：

具体说明如下：

1、 用户登录时，客户端请求接口，传入用户名和密文的密码
2、 后台服务对用户身份进行验证。若验证失败，则返回错误结果；若验证通过，则生成一个随机不重复的token，并将其存储在redis中，设置一个过期时间。
其中，redis的key为token，value为验证通过后获得的用户信息
3、 用户身份校验通过后，后台服务将生成的token返回客户端。
客户端请求后续其他接口时，需要带上这个token。后台服务会统一拦截接口请求，进行token有效性校验，并从中获取用户信息，供后续业务逻辑使用

为了防止中间人攻击（客户端发来的请求被第三方拦截篡改），引入参数的签名机制。
具体步骤如下：

1、客户端和服务端约定一个加密算法（或MD5摘要也可）， 客户端发起请求时，将所有的非空参数按升序拼在一起，通过加密算法形成一个sign，将其放在请求头中传递给后端服务。
2、后端服务统一拦截接口请求，用接收到的非可空参数根据约定好的规则进行加密，和传入的sign值进行比较。若一致则予以放行，不一致则拒绝请求。

由于中间人不知道加密方法，也就不能伪造一个有效的sign。从而防止了中间人对请求参数的篡改。

sign机制可以防止参数被篡改，但无法防dos攻击（第三方使用正确的参数，不停请求服务器，使之无法正常提供服务）。因此，还需要引入时间戳机制。
具体的操作为：客户端在形成sign值时，除了使用所有参数和token外，再加一个发起请求时的时间戳。即

sign值来源 = 所有非空参数升序排序+token+timestamp

而后端则需要根据当前时间和sign值的时间戳进行比较，差值超过一段时间则不予放行。
若要求不高，则客户端和服务端可以仅仅使用精确到秒或分钟的时间戳，据此形成sign值来校验有效性。这样可以使一秒或一分钟内的请求是有效的。
若要求较高，则还需要约定一个解密算法，使后端服务可以从sign值中解析出发起请求的时间戳。
总结后的流程图如下：

这里还是隐藏下了。

规则：sha1(keyvalkeyval+token+timestamp+id)

例如：sha1（address33bussinessType22city111companyNamest232ringtokentimestampid）

这里新增一个id值，与token对应，传输过程中不使用，只用于加密，保证数据即使被截获，因为请求中没有id的传输，更加安全。

token身份认证；

timestamp方式防止dos攻击，防止重放，简单说就是一次接口调用，只能用一定时间，比如比对时间，60s内该次调用有效，60秒后失效；

sign签名，通过参数+token+timestamp+id固定位加密，保证参数不会被修改，调用有效；

你开放的API接口真的安全吗

你开放的接口真的就很安全吗，看看有没有做到如下几点

1.请求身份验证

2.请求参数校验

3.请求是否唯一

4.请求次数限制

请求身份验证
基于 AccessKey：为接口调用放分配AccessKey和SecretKey（不参与传输，只用于本地接口加密，不能泄露）

基于token身份验证：
1.用户登录提供认证信息（如：账号密码）服务器验证成功后将用户信息保存到token内并设置有效期，再返回token给调用方
2.调用方保存token，并在有效期内重新换取token，保证token是有效的
3.服务器验证token有效性，无效则拦截请求返回错误信息，反之则从token内获取用户信息进行后续操作

请求参数校验
1.校验参数合理性（如：参数类型，参数长度，参数值校验）
2.防止XSS，SQL注入（解决方案：过滤敏感字符或直接返回错误信息）
3.校验参数可靠性是否被篡改（可以将参数以特定格式排列+秘钥组成字符串，在进行MD5或SHA签名）

请求是否唯一
前面第3点解决了请求参数被篡改的隐患，但是还存在着重复使用请求参数伪造二次请求的隐患

timestamp+nonce方案

nonce指唯一的随机字符串 ，用来标识每个被签名的请求。通过为每个请求提供一个唯一的标识符，服务器能够防止请求被多次使用（记录所有用过的nonce以阻止它们被二次使用）。

然而，对服务器来说永久存储所有接收到的nonce的代价是非常大的。可以使用timestamp来优化nonce的存储 。

假设允许客户端和服务端最多能存在15分钟的时间差，同时追踪记录在服务端的nonce集合。当有新的请求进入时，首先检查携带的timestamp是否在15分钟内，如超出时间范围，则拒绝，然后查询携带的nonce，如存在已有集合，则拒绝。否则，记录该nonce，并删除集合内时间戳大于15分钟的nonce（可以使用redis的expire，新增nonce的同时设置它的超时失效时间为15分钟）。

请求次数限制

某些资源我们需要限制用户的请求次数，同时也为了防止非人为操作可能导致系统的崩溃
实现思路如下：
假如我们允许用户每秒钟最多10次请求，超过10次则返回“手速太快了，慢点把。。”
这里我们使用redis辅助我们实现：

以用户IP为key，请求次数为value，有效时间为1秒
用户在每秒的第一次访问的时候，此时我们的redis是没有key为用户ip的数据的（因为失效了，或者第一次请求）所以我们要初始化当前请求用户的ip为keyvalue为0到redis数据库

当用户在1s内再次发起请求我们就将此ip的请求次数+1，并判断请求次数是否已近=10
=10则返回给用户手速太快了!请稍后重试..否则继续执行后续操作

具体实现代码如下：

如有疑问可在下方留言，我会尽快答复，或者关注公众号 程序员MuziDong 随时了解新的动态

开放平台API接口安全性设计——微信支付为例

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

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

一般来说，在前端对数据做加密或者前面，是不现实的。前后端使用HTTP协议进行交互的时候，由于HTTP报文为明文，所以通常情况下对于比较敏感的信息可以通过在前端加密，然后在后端解密实现"混淆"的效果，避免在传输过程中敏感信息的泄露（如，密码，证件信息等）。不过前端加密只能保证传输过程中信息是‘混淆’过的，对于高手来说，打个debugger，照样可以获取到数据，并不安全，所谓的前端加密只是稍微增加了攻击者的成本，并不能保证真正的安全。即使你说在前端做了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小时内删除侵权内容。