前后端分离,如何防止接口被其他人调用或恶意重发

前后端分离,如何防止接口被其他人调用或恶意重发?

首先,http协议的无状态特性决定了是无法彻底避免第三方调用你的后台服务。我们可以通过crsf、接口调用频率、用户行为分析(来源等)等各个方面来增加第三方调用的难度,也可以通过添加一个中间层比如node.js来实现;
1. 非法访问通常使用认证来解决,方法很多session,token,oauth第三方框架等等。

(1)常规的方法:用户登陆后生成token,返回客户端,然后服务器使用AOP拦截controller方法,校验token的有效性,每次token是一样的;
(2)用户登陆后生成临时token,存到服务器,并返回客户端,客户端下次请求时把此token传到服务器,验证token是否有效,有效就登陆成功,并生成新的token返回给客户端,让客户端在下一次请求的时候再传回进行判断,如此重复。 这种方法有性能问题,但也有一个漏洞,如果用户在一次请求后,还未进行下一次请求就已被黑客拦截到登录信息并进行假冒登录,他一样可以登录成功并使用户强制下线,但这种方法已大大减少被假冒登录的机会。

(3)两层token:一般第一次用账号密码登录服务器会返回两个token,时效长短不一样,短的时效过了之后,发送时效长的token重新获取一个短时效,如果都过期,那么就需要重新登录了。当然更复杂你还可以做三层token,按照业务分不同token。

2. 对于合法的认证访问,通常需要进行IP访问频率和次数的限制,各种API框架都有支持,比如Django restframework的throttling。
  通常我们可以通过使用过滤器和缓存如redis来判断访问次数及频率。在filter层加一个过滤器,拦截所有的请求,解析出请求的用户,然后通过缓存,获取到该用户当前已访问次数。而缓存,要求最好能够自动超时回收,也就是说比如你想设定三分钟内限制访问次数,那么你记录的缓存有效期就三分钟就好了,过了三分钟缓存自动失效,计数器也就重新从0开始了。类似于发短信的接口,每分钟只能发一次;
3. 最外层的限制可能需要在nginx上配置rate limit。

参考自:http://blog.csdn.net/codercwm/article/details/58607420

http://blog.csdn.net/mylovepan/article/details/38894941

  1. 1. 加密,时间戳,每个包要有包序号,每次同向加1,收到重复序号认为是攻击,可以抵御重放攻击。此外借助于HTTPS/TLS其自身机制,保证了消息完整性,并且可以抵御重放攻击。由于加密,对方也无法看到明文内容。
  2. 2

    2. 客户端生成一串随机数R1,发给服务器,服务器判断此R1是否重复,之后根据算法(R1+R2)生成密钥。最好是结合验签机制。

  3. 3

    3. https 会被中间人攻击,Fiddler 能用替换证书的方式截获并还原明文。非对称加密(例如RSA)是个好办法,不过你得防止别人直接反编译你的代码分析出你的明文拼接方式。

原文地址:https://www.cnblogs.com/ExMan/p/10069487.html

时间: 2024-10-11 00:27:30

前后端分离,如何防止接口被其他人调用或恶意重发的相关文章

前后端分离后台api接口框架探索

前言 很久没写文章了,今天有时间,把自己一直以来想说的,写出来,算是一种总结吧!  这篇文章主要说前后端分离模式下(也包括app开发),自己对后台框架和与前端交互的一些理解和看法.     前后端分离,一般传递json数据,对于出参,现在通用的做法是,包装一个响应类,里面包含code,msg,data三个属性,code代表状态码,msg是状态码对应的消息,data是返回的数据. 如  {"code":"10008","message":"

前后端分离之【接口文档管理及数据模拟工具docdoc与dochelper】

前后端分离的常见开发方式是: 后端:接收http请求->根据请求url及params处理对应业务逻辑->将处理结果序列化为json返回 前端:发起http请求并传递相关参数->获取返回结果处理相关逻辑 分离的主要目的是让前后端可以并行的进行工作,彼此之间只需要依赖一份接口文档 接口文档可能会使用一些文本工具进行记录,例如word,excel等 其中记录的内容可能为请求路径,请求类型,请求参数,响应参数,请求示例,响应示例,变更记录等 不过以上方式还存在那么一点不完美,那就是前端需要等待后

微信自定义分享 laraverl 框架,前后端分离 报错 签名失效 63002

<?phpclass JSSDK {private $appId;private $appSecret;private $url;//如果是前后端分离,是接口请求,必须自定义当前页面地址 送过来 否则签名错误20190905public function __construct($appId, $appSecret,$url) {$this->appId = $appId;$this->appSecret = $appSecret;$this->url = $url;} publi

django 前后端分离,后端接口实现

博客篇我们使用的是前后端不分离的方式进行实现,前后端不分离实现方式,主要用于小型的项目,且一个人就可以搞定所有,但是中大型的应用还是用的前后端分离的方式进行的 前后端分离方式后台主要给前端提供接口,前端JS调用后台的接口,根据接口定义的传参进行传参,得到返回值,然后展现在页面上,或者对数据进行了操作,把操作后的数据传给后端,后端进行数据的更新等 下面的例子我们主要从基本的增删改查进行设计后台接口部分 一.准备工作 1.modles.py文件中,创建student表,用于进行增删改查 class

从壹开始前后端分离 [ Vue2.0+.NET Core2.1] 二十一║Vue实战:开发环境搭建【详细版】

系列教程一目录:.netcore+vue 前后端分离 系列教程二目录:DDD领域驱动设计 系列教程三目录:Nuxt.js TiBug系统 系列教程四目录:VueAdmin 后台管理系统 系列教程五目录:IdentityServer4 授权服务器 本文梯子 缘起 零.今天要完成左下角红色的部分 A.Vue 常见的IDE —— 我是开发工具,干活的都是我 1.VsCode 2.Webstorm 3.Atom B.安装Nodejs环境 —— 我是运行环境,没我不行 C.安装 npm / cnpm ——

前后端分离之JWT用户认证

在前后端分离开发时为什么需要用户认证呢?原因是由于HTTP协定是不储存状态的(stateless),这意味着当我们透过帐号密码验证一个使用者时,当下一个request请求时它就把刚刚的资料忘了.于是我们的程序就不知道谁是谁,就要再验证一次.所以为了保证系统安全,我们就需要验证用户否处于登录状态. 传统方式 前后端分离通过Restful API进行数据交互时,如何验证用户的登录信息及权限.在原来的项目中,使用的是最传统也是最简单的方式,前端登录,后端根据用户信息生成一个token,并保存这个 to

利用grunt-contrib-connect和grunt-connect-proxy搭建前后端分离的开发环境

前后端分离这个词一点都不新鲜,完全的前后端分离在岗位协作方面,前端不写任何后台,后台不写任何页面,双方通过接口传递数据完成软件的各个功能实现.此种情况下,前后端的项目都独立开发和独立部署,在开发期间有2个问题不可避免:第一是前端调用后台接口时的跨域问题(因为前后端分开部署):第二是前端脱离后台服务后无法独立运行.本文总结最近一个项目的工作经验,介绍利用grunt-contrib-connect和grunt-connect-proxy搭建前后端分离的开发环境的实践过程,希望能对你有所帮助. 注:

[转]从MVC到前后端分离

从MVC到前后端分离 来源:csdn 发布时间:2015-10-26 阅读次数:1680 1. 理解MVC MVC是一种经典的设计模式,全名为Model-View-Controller,即模型-视图-控制器. 其中,模型是用于封装数据的载体,例如,在Java中一般通过一个简单的POJO(Plain Ordinary Java Object)来表示,其本质是一个普通的Java Bean,包含一系列的成员变量及其getter/setter方法.对于视图而言,它更加偏重于展现,也就是说,视图决定了界面

前后端分离

Swagger - 前后端分离后的契约 前后端分离 按照现在的趋势,前后端分离几乎已经是业界对开发和部署方式所达成的一种共识.所谓的前后端分离,并不是传统行业中的按部门划分,一部分人只做前端(HTML/CSS/JavaScript等等),另一部分人只做后端(或者叫服务端),因为这种方式是不工作的:比如很多团队采取了后端的模板技术(JSP, FreeMarker, ERB等等),前端的开发和调试需要一个后台Web容器的支持,从而无法将前后端开发和部署做到真正的分离. 通常,前后端分别有着自己的开发