关于前端 token 安全问题

[BruceXHe]

前端：VUE

后台：.NET CORE REST API

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

请问大家有什么办法？

[wangyzj]

你把你的逻辑放在后端
前端用 jwt

[wjhjd163]

@KuroNekoFan 那在楼主这个环境中，jwt 应该充当什么角色呢？

[zachlhb]

如果是 web 项目的话可以考虑用 ip 白名单

[manzhiyong]

自制随机字体，页面上显示和爬虫抓回去的源码不一样，这样就可以做到反爬了

[warcraft1236]

我就说一种情况你们就防不了，UI 自动化，管你是 web 还是 app，我用自动化测试的方式抓你的数据还不是效率问题？

[shynome]

在客户端再做一次混淆编码，在 .so 文件里实现
这是常用的反破解的手段

[shynome]

同一段内容可以根据时间采用不同的加密方式，这样在不清楚加密方式的情况下想使用接口几乎是不可能的

[xi_lin]

针对原文问题，客户端一般用 PKCE 模式来规避前端保存 screct 的问题

[isnullstring]

限制同一 TOKEN 短时间内请求次数啊
至于 Token 怎么生成，上面的老哥也说了，clientId,clientKey 固定在代码，基础的防御都做不了

[KuroNekoFan]

@wjhjd163 jwt 的意义不只在于 payload 里面混淆的 data，secret 和 signature 的设计可以在一定程度上确保`这个 token 是可以被信任的`

[KuroNekoFan]

@wjhjd163 当然我又看了一下楼主的描述，考虑最糟糕的设计，clientId,clientKey 相当于 secret，那，怎么搞都不行

[BruceXHe]

@ALL
谢谢各位大佬，涨见识了！！

[winglight2016]

神奇的设计，涉及安全身份的内容为啥是写死在前端的？ token 一般不都是用户输入用户名密码才能获取的吗？如果没这个登录需求，那么 koken 还有什么用？

需要反爬的话，不能按照登录验证这种思路来设计。

[vone]

同 .NET Core，现在做 .NET 的同行好像越来越少了。

我可以从做爬虫的角度，给你几个改进方向：
1 、取消 clientId , clientKey 获取 token 的逻辑，因为没有 clientId 、clientKey 会让分析接口的人更怀疑人生；
2 、对获取 token 相关接口改为参数改为密文（ RSA+其他的魔改操作），加密函数一定要混淆，且不能完全使用某种公开算法；
3 、对请求参数增加时间戳和签名；
4 、下发 token 时检测浏览器常见全局变量和之前预留的监测点数据（尽量防止 selenium/puppeteer 这种无头浏览器和程序的模拟请求），这一点可以参考淘宝或者其他大厂的反爬策略。
5 、未登录下发的 token 使用增加频率限制，高频使用时墙掉对应 IP 。
6 、随机抽取访问频率偏高但未达到 5 的 token 让其登录或输入验证码。如果对应 IP 未登录或输入验证码，而是转而获取新 Token，就可以墙掉对应 IP 。

4 、5 、6 需要在服务端进行校验，检测内容和接口可以偶尔进行升级。

[BruceXHe]

@vone 嗯嗯，谢谢，后端服务端的骚操作那是必须的。

[exonuclease]

这不是为了安全是为了反爬虫？无解除非你强制用户登录才能看

[Torpedo]

@BruceXHe 比较场景的就是通过客户端发请求。客户端用一个 token 和参数的排列，算出 md5 给服务端。

核心是客户端混淆这个哈希算法（算法随意，md5 都行）和 token 。

[wednesdayco]

既然是 APP 内嵌 所有需要加密都请求都走 APP 协议,让 app 去反扒呗

[unclemcz]

根据时间戳加密，加密算法写入.so ，时间戳和加密后字符串一起传到后端，判断时间戳和服务器时间，比如控制延迟为 1s ；同样的加密算法计算加密字符串，和传入的加密字符串比较，这样基本可以防止爬虫。

[ChanKc]

一般这种设计的后端就是不允许 Web 直接调用的