关于前端 token 安全问题

[BruceXHe]

前端：VUE

后台：.NET CORE REST API

现在我们后台的接口，需要 TOKEN，TOKEN 通过 clientId,clientKey 获取的（非用户输入用户名和密码），
目前只有把 clientId,clientKey 配置在 VUE 代码里用于获取 TOKEN，但是这样就不安全了。

请问大家有什么办法？

[baiyi]

@BruceXHe #35 web 也可以混淆，再加上防重放等手段，但这些都是防止其他应用通过自动化手段直接获取你的数据给他们使用，防不了敏感数据的暴露，完全可以人工获取。
可以整理一下业务逻辑，是不是真的是敏感数据，还是说可接受暴露的数据

[libook]

只要不经过服务端的认证，理论上不可能达到接口保护的目的。更何况即便加上了认证，滥用者也可以注册一个账号，然后用经过验证的环境来滥用接口。

只要前端不经过认证能访问商品的接口，那么商品接口就能被自动化调用，进而被滥用。

一种折中的方法是上反爬虫（如 CAPTCHA ）方案，就像你在很多网站看到的所谓“安全检测”的页面，其实是对你的整体情况进行分析来判断你是不是机器人或攻击者。
另外 WAF 也可能有些防御作用。

[dingjs]

CSRF

[paulee]

建议在问题里面追加一下背景，另外前端没法解决这个问题(反爬)，可以沉了

[darrenfang]

可以用 oauth2 的 implicit 模式来获取 token，在登录页面验证 recaptcha 或者加上图形验证码。

[Hyseen]

关键字：CSRF

[YoRolling]

要不 了解一下字体反爬？ 接口返回’a‘， 通过字体渲染出来的是 ’b‘。

[whitehack]

你这种需求, 不管 web 端还是 app 端 都可以用 wss 来通信. 通信内容也自己做加密, 这方面的方法就太多了.

[rioshikelong121]

使用 clientId, key 像是基于客户端的验证，这种一般肯定不会放在前端的呀。无法避免风险。

[opengps]

clientId，clientKey 是怎么个用法？我理解的 token 是登录成功分配一个授权 token，登录不成功用的 token 后端标记为匿名属性，有限访问接口
如果你想 clientId，clientKey 来保证授权，那么对方应该有个自己的简易后端来存储 clientId，clientKey，从自己的后端发起请求拿到有效 token，然后让 token 暴露到前端使用

[angryfish]

可以最大限度做到破解的。clientid 由 app 加密生成。算法保密。

[imnpc]

clientId,clientKey 我这里是颁发给 APP 使用 但是除了这个 还需要用户名 + 密码 才能去拿到 token 的

[dustinth]

就是反爬, 现在这种方案解决不了任何问题. 一定要有个"鉴权"发 Token 的步骤. 这个鉴权是广义的鉴权, 比如鉴定你是一个人类(常见的 Google 那种"我不是机器人"的按钮). 然而真有心爬, 人工加模拟人工都是可以爬到的, 就是个成本的问题.

[KuroNekoFan]

@wjhjd163 jwt 又不是只能用来鉴权

[renmu123]

@BruceXHe 你这个是一个反爬的需求了，我提两个点，可以将关键数据转换为图片，比如说价格，还可以使用字体替换等方法。第二种还是请求借口的时候返回一个 token，让后端验证，这个 token 的计算方法要很复杂，用 js 做各种乱七八糟的的转换，尽量提高爬虫解析 js 的难度。如果成本过高，很少会有人闲得爬你们数据。还有就是服务端做 ip 黑名单之类的东西了。。当然以上说的这些客户端反爬手段，技术好的爬虫都能解决，只能提高他们的解决成本

[chinvo]

接口防滥用不是这么玩的

所有前端手段都不能防止滥用

应该在后端做限制

包括 qps 、配额、异常流量识别

[LifStge]

@BruceXHe 完全防护做不到 既然你提到了 app 加固 无非就是增加下破解的复杂度 首先再 app 不被爆破的前提下 动态获取 token 是可以的 但是固定 id 跟 key 存在客户端 然后获取 token 其实吧 这种截包 很容易发现的 这块无非就是增加下算法的复杂度 增加获取 token 的复杂度 (增肌截包分析难度, 必须走破解客户端的路子)
比如举个例子 token 的获取流程 客户端发起 -> 然后服务器与客户端协商验证算法(这块可以做多组动态的验证) -> 然后客户端再通过协商后的算法发起 token 请求(接口都可以用是加密动态的)-> 剩下的用 token 走流程就是了
然后再比如 为了避免截获 token 然后再保存发起请求 就可以在 token 的动态配置上做做文章 比如不同的分组啥的 不同的 token 等等了 无非就是增加下流程的复杂度 增加截包分析难度
再比如某些接口的请求 服务端对异常请求 校验下 埋点雷 然后做拉黑啥的 (增加下破解调试复杂度)
如果加固的 app 被破了 那就无所谓了 反正是防不住了......
最终目的就是增加破解成本了 复杂度上去了 那么 就相对安全了 毕竟不是什么大利益的项目 不值得破下去

[suzic]

用过这种类似的方式加密接口，前端给后端发的 token 是通过 key 和后端约定好的加密过的字符串，后端拿来对比。一般没什么问题，反爬还是不够的

[LifStge]

@LifStge 其实吧 既然都限定 app 了 就不要暴露那么多接口了 直接前面说的 动态 token 的方式 剩下的改动就是 不要直接 去请求网络接口 而是所有流量都走一条 https 的 TCP 链接就行了 token 啥的 用于建立连接 协议 就走 rpc 就行了
然后服务端做做异常流量清洗 ip 拉黑啥的 就够了 比较稳了

[LifStge]

@LifStge 好吧 想多了 增加复杂度了 不需要 rpc 单走 https 就行了