没什么好办法,因为任何能下发到客户端的信任凭证,在攻击者拿到客户端源码后也都能拿到。 即便是构造私有协议、加密,在有客户端源码的情况下都是无力的。 如果是依靠客户端版本或其他需要客户端配合产生的信任凭证,那攻击者能下一次源码就能下第二次,从这个角度来说,攻击者就是一个合法的客户端,你没有办法区分它。毕竟是个公网客户端又不是加个访问白名单就能搞定的。 HTTP 的请求头又能随便构造。 这个问题是个成本问题,即你只能在一个 session 频繁访问接口的时候判断它是一个非法调用,至于这个频繁要怎么定义就只能你自己根据正常用户的操作频率来定义了。 所以说这就跟反爬一样,能做的就只有 "判断是不是正常用户的操作" 就行了。 说起来对于小程序的情况,估计 IP 黑名单也不是很好使,因为手机 IP 是很容易变得,万一误封(比如公共 wifi)就不好了。 以上仅限于我目前掌握的知识而言,也许有大佬会有不错的解决办法。
接口要绝对不被访问基本是不可能,尤其是已经可以完全清楚你正常的访问方式时。 需要保护的接口,一般都是有会话状态,即需要“登录”获得token。这样,前端安全问题就变成是token的获得、传输和保存,范围就缩小了
没什么好办法,因为任何能下发到客户端的信任凭证,在攻击者拿到客户端源码后也都能拿到。
即便是构造私有协议、加密,在有客户端源码的情况下都是无力的。
如果是依靠客户端版本或其他需要客户端配合产生的信任凭证,那攻击者能下一次源码就能下第二次,从这个角度来说,攻击者就是一个合法的客户端,你没有办法区分它。毕竟是个公网客户端又不是加个访问白名单就能搞定的。
HTTP 的请求头又能随便构造。
这个问题是个成本问题,即你只能在一个
session
频繁访问接口的时候判断它是一个非法调用,至于这个频繁要怎么定义就只能你自己根据正常用户的操作频率来定义了。所以说这就跟反爬一样,能做的就只有 "判断是不是正常用户的操作" 就行了。
说起来对于小程序的情况,估计 IP 黑名单也不是很好使,因为手机 IP 是很容易变得,万一误封(比如公共 wifi)就不好了。
以上仅限于我目前掌握的知识而言,也许有大佬会有不错的解决办法。