前后端的接口验证问题

问题

通常我们在h5前端调用后台接口时,一般是ajax,那么接口的安全成了一个问题。

这里可以肯定的说,前端调用的接口一定要验证!

然后剖析了微信网页版、京东网页版这些,也都是通过接口的形势绑定数据,所以在进行前端开发时,除了直接后台模板绑定,比如dotnet的MVC,java的springMVC这些。

前端和后端采用接口访问时的调用验证机制(基于JWT的前后端验证)

JWT主要实现的Token机制,为每一个需要调用的接口生成验证的Token,然后后端进行验证合法性。

JWT是一个标准,那么实现这个标准的语言就非常多,比如C,C++,Java等,具体的参考官方提供的文档即可。

官网:https://jwt.io/

生成原理:比如我们请求一个接口时,会使用JWT生成的Token,一同传递到后端进行验证合法性,对于生成Token可以是页面载入的时候写到Cookie,或者写到页面的固定位置。

可能遇到的问题和解决方案:

1、如果基于Java Web系统,前后端没有做分离时,基本页面输出使用了Java Web的模板引擎的,可以为输出的页面带上生成Token字符串,然后这些Ajax请求全部带上这个Token。

1.1、可能会出现这个Token暴露在页面,然后用工具提取到,然后进行请求;对于这个问题可以这样做,Token本身有过期机制,比如2个小时过期,这样一般能杜绝绝对部分的请求。

1.2、再加强一下,比如请求的接口上做一个验证,比如获取请求时判断上一个请求的头上Referer值,看下是否为当前域名下的。

1.2、比如生成Token时,带上请求的参数进行生成再输出,这样也就一个Token只能做一个参数的请求,也能杜绝掉一大部分的伪造请求。

1.3、对于生成Token,可以是单独的接口,但这样有点危险,可能会让人提取去用,但是如果判断只能当前域名下使用可能会有效。

1.4、也可以这样生成这个Token,比如我们要访问的B页面,那么先请求A页面再跳转到B页面,此时就会带上Token在Cookie上,然后再请求。不过同样也会被提取的风险。

1.5、学微信的做法,微信的前端JS做了Token的验证,比如页面上写好AppID,然后Token是服务端生成好放入到页面的,并且与域名进行绑定,如果域名变了,就无法使用这个Token请求。那么我们还是回到Referer的判断上进行判断,是否是本域名发出的请求。

2、如果是别的系统进行调用时,比如前后端分离的方案,需要使用到Ajax进行请求第三方接口的。

2.1、没办法,这个Token只能有后端生成好给你,然后你再使用它进行请求,并且第三方接口上也会判断Referer的来源域名。

2.2、还是使用上面的A和B页面进行跳转,然后获取Token,当然这个A页面可以是第三方去做,然后针对域名写Cookie。

3、综上,基本上是生成Token要过期时间,要判断请求的来源域名。、

4、针对Ajax是没有绝对安全的,只能做到比较安全;最明显的例子就是微信Web端,网上同样针对微信的Web API进行抓包分析,然后实现了请求的。既然加了Token机制只是为了再复杂多一步,使刷包的人做多一步难的操作。

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章