这是一个创建于 1648 天前的主题，其中的信息可能已经有所发展或是发生改变。
前端代码毫无安全性可言，打开浏览器开发者工具，什么底裤都能看到。即使是压缩混淆过的前端线上代码，也可以通过逆向后审计，找出可利用的业务逻辑漏洞，这导致 http/https/websocket 应用的安全性几乎完全依赖于后端。
新版本安卓的 apk 打包发版时可以开启防抓包，大大提高了安卓应用被逆向破解的难度。
大家认为未的浏览器会加入 [生产环境代码不可见] 这个新特性吗？线上环境光明正大地让前端代码裸奔，除了能方便复现线上 bug，我想不到有什么好处
新版本安卓的 apk 打包发版时可以开启防抓包，大大提高了安卓应用被逆向破解的难度。
大家认为未的浏览器会加入 [生产环境代码不可见] 这个新特性吗？线上环境光明正大地让前端代码裸奔，除了能方便复现线上 bug，我想不到有什么好处
 | 1 815979670 2021-06-06 16:09:54 +08:00 我觉得不可能 前端目前的机制就是明文的脚本代码 浏览器 就算屏蔽了开发者工具 也会有其他工具、插件来提供这个功能的 |
 | 2 VDimos 2021-06-06 16:14:17 +08:00 via Android  1 防君子防不了小人，真想逆向你，二进制分发也能行。无非就是增加了难度而已。浏览器加上生产环境代码不可见，还不如期待全用 web assembly 开发，历史包袱太重了，不可行 |
 | 3 Rheinmetal 2021-06-06 16:15:28 +08:00 @815979670 wasm 没有 dom api 吧 不过可以像 react server components 那样喂 virtual dom 类似物过来 js 只有 vdom2dom |
 | 4 shyling 2021-06-06 16:19:39 +08:00 > 新版本安卓的 apk 打包发版时可以开启防抓包，大大提高了安卓应用被逆向破解的难度。 和前端混淆有本质区别吗。 另外个人理解前端主要还是在于展示，ui 有什么值得逆向的，想抄看着样子就能抄了吧。 |
 | 5 dingwen07 2021-06-06 16:20:39 +08:00 3 Firefox 这种开源浏览器怎么办？ |
 | 6 echo1937 2021-06-06 16:31:35 +08:00 一般来说，涉及安全的方面肯定是要做双端验证，如果前端代码涉及部分业务逻辑，一般也是经过后端适当抽象以后的调用，我不太清楚 WebAssembly 在防逆向方面有没有什么比较大的优势。 |
 | 7 ZeoKarl 2021-06-06 16:34:28 +08:00 via iPhone 他要是想搞你，你就是用 01 写他也会一个字符一个字符的看，无非就是加大一点阅读的难度 |
 | 8 Jirajine 2021-06-06 16:40:22 +08:00 5 恰恰相反，浏览器只会不断加入一些新特性来让前端代码更透明。 |
 | 9 janxin 2021-06-06 16:42:22 +08:00 via iPhone 13 感觉你操作反了…开放透明才是前端未来 |
 | 10 godblessumilk OP @shyling 最主要是能抓包出所有 http 请求的请求路径鸭 |
 | 11 ysc3839 2021-06-06 16:44:40 +08:00 via Android 我认为不会。 类似各个操作系统也没有加入什么防止逆向的技术，都是第三方自己为不同系统研发相关技术。 我认为 Web 也类似，也会是第三方推出防止逆向的技术出来。 |
 | 14 3dwelcome 2021-06-06 17:21:10 +08:00 后端安全性实在太过无敌，相比之下，前端就显得没那么必要。 比如你几乎无法通过穷举，来破解一个网站用户名的登录密码。 任何技术推进，还是要有需求才行，没强需求啊。 |
 | 15 crazytec 2021-06-06 17:21:29 +08:00 via Android 建议设计代码 DRM 系统（ |
 | 16 wellsc 2021-06-06 17:30:02 +08:00 via iPhone 明文有逆向的概念吗 |
| 17 godblessumilk OP @wellsc 现在很多前端代码上线前会用 webpack 的代码丑化插件来压缩混淆的（话说我头像的涩图是被举报了么） |
 | 18 morize 2021-06-06 17:45:16 +08:00 还是要后端挡啊哈哈。不就是怕接口被看到嘛，看到就看到咯。抓包一下，再 Mitm 一下啥都能知道了，脚本 boy 就出动了。关键是一般人无缘无故谁有这耐心去分析啊？ |
| 19 wellsc 2021-06-06 17:47:13 +08:00 via iPhone @godblessumilk 混淆和逆向不是一回事 |
 | 20 charlie21 2021-06-06 17:47:58 +08:00 如果是客户端渲染 网络传输量 and 客户端负载，这两个都是最好不要增加的。那么肯定就是压缩之后的明文传输 如果是服务端渲染 ...... |
 | 21 codehz 2021-06-06 17:50:11 +08:00 via Android （其实已经有了，只是使用成本比较高） DRM 技术就是干这个的。。。 |
 | 22 BeautifulSoap 2021-06-06 18:06:26 +08:00 WebAssembly 不就行么，虽说它不是拿来防止逆向的，但你用其他语言编译出来的 wsm 文件的确没有一定的技术和相当的耐心不好逆向。而且有了 wsm 的话，加壳之类的操作也可以上了，让逆向程度从原本的谁都可以试试，提升到类似二进制可执行程序逆向的的难度 |
 | 23 raaaaaar 2021-06-06 18:12:34 +08:00 via Android 开源万岁！自由万岁！ |
 | 24 546L5LiK6ZOt 2021-06-06 18:35:19 +08:00 via Android 4 要保证代码安全性，感觉只能用远程桌面的思路，浏览器只接收图形渲染信息 |
 | 26 love 2021-06-06 19:11:24 +08:00 apk 防抓包是什么意思？可以防查看网络请求？这也可以实现？ |
 | 28 KINGOD 2021-06-06 20:26:33 +08:00 >新版本安卓的 apk 打包发版时可以开启防抓包 请问这个指的是什么？是说 Android P 里的 “只允许 HTTPS 协议，不允许 HTTP” 吗？还是其他的什么额外配置？ |
 | 30 Maskeney 2021-06-06 20:34:22 +08:00 敏感内容加密 固定证书防抓包 喜闻乐见又一个把 https 当防客户端加密用的 |
 | 32 learningman 2021-06-06 20:49:47 +08:00 via Android @Rheinmetal Wasm 可以传入函数给程序用，所以拥有所有 API. |
| 33 learningman 2021-06-06 20:51:40 +08:00 via Android @love 不能，他说的是证书装订，可以杜绝 MITM 。 可是人家抓不了你的包，直接 hook 应用还是能拿到信息啊。。。感觉用处不大。 |
 | 34 iceheart 2021-06-06 20:52:46 +08:00 via Android 2 browser 端代码必须得暴露在阳光下，不然的话如何能得到用户的信任，有程序干坏事了，咋定位是谁干的？ 想隐藏代码就去搞 c/s 的好了 |
 | 35 cz5424 2021-06-06 20:56:47 +08:00 via iPhone 同楼上，远程桌面，估计只有这一条路 |
 | 36 yitingbai 2021-06-06 21:52:59 +08:00 1 永远不可能的, 就拿你的例子安卓 apk 来说, 我自己 clone 安卓源码, 自己编译系统, 再运行你的加密 apk, 你能防得住? 所以这就是无意义的事情, 还不如让前端代码更透明, 开发更方便 |
 | 37 geekvcn 2021-06-06 22:27:36 +08:00 1 Adobe，微软 ，苹果算不算大厂，算不算牛逼，他们的软件和系统都被破解，所以现在都搞订阅制和云端化了，让部分功能依赖云端 |
 | 38 CrazyRundong 2021-06-06 22:34:26 +08:00 via iPhone @dingwen07 #5 浏览器开源反而是最不用担心的问题，现代加密算法的安全性来自于密钥而不隐藏算法本身。openssl 不也是开源的嘛 |
 | 39 abc612008 2021-06-06 22:37:33 +08:00 "这导致 http/https/websocket 应用的安全性几乎完全依赖于后端"这不是常识吗？你安全机制都部署在前端？ 永远假设前端是不可信的。Security through obscurity 不可取 |
 | 40 Atom931989614 2021-06-06 22:50:14 +08:00 web 端页面都要凉了吧 |
 | 41 namelosw 2021-06-06 23:00:07 +08:00 我理解这个问题无解的。 1. 浏览器加了没用，一个 curl 就解决了 2. 表面弄得再复杂也是掩耳盗铃，可以抓包 3. 包加密也没用，怎么客户端也得存个 key，客户端搞个 GDB 之类的插进去拿出来还是能把包解开 |
 | 42 Lemeng 2021-06-06 23:03:20 +08:00 这个真可以吗。 |
 | 43 huruwo 2021-06-06 23:16:36 +08:00 开启防抓包 这个也没多大用处 |
 | 44 johnsona 2021-06-06 23:39:47 +08:00 via iPhone 其实有价值 毕竟不少后端会把工作丢给前端 验个参都马虎 |
 | 45 BrettD 2021-06-07 01:22:18 +08:00 这不是掩耳盗铃吗，Chromium 、Firefox 浏览器都是开源的，就算有人添加了隐蔽前端代码的功能，也可以有人修改代码把这个功能删除掉 |
 | 46 Corua 2021-06-07 01:41:29 +08:00 via Android 实际上已经有这种 js 虚拟机技术来把原始代码转成自定义的汇编码来运行了，主要还是增加了逆向的难度（ |
 | 47 Rocketer 2021-06-07 01:55:08 +08:00 via iPhone 你要是想防抄袭，那还可以理解。 你要是为了安全，那你的方向有问题。前段逻辑是用来方便用户的，而不是限制用户的。比如某个东西需要一定的权限、步骤、道具等才能看见，你藏着不让他看是为了给用户一个正确的体验，如果用户非要看，那就看吧，他自己高兴就好。 |
| 48 ysc3839 2021-06-07 06:28:48 +08:00 @geekvcn #37 如果论反破解的话这些厂商不算牛逼的，你看看微软和苹果的操作系统中各类可执行文件都没像有的厂商那样搞加壳、混淆，自然容易被破解。 |
 | 49 uqf0663 2021-06-07 07:56:39 +08:00 新版本安卓的 apk 打包发版时可以开启防抓包？你大概不知道我都是通过路由器抓包的吧？ |
 | 50 murmur 2021-06-07 07:58:29 +08:00 前端其实没什么抄袭的必要，就我国这个内卷和加班，只要后端能做出来，别人认为有前景，分分钟抄一个跟你一样的出来 |
 | 51 LiuJiang 2021-06-07 08:59:34 +08:00 我觉得有可能，而且这事只能是浏览器厂商来做，对于一些 CSS 特效来说，非常有用。 |
 | 52 huang119412 2021-06-07 09:01:05 +08:00 安卓防抓包是个好设计？ ios 抓包随随便便，也么听说有什么问题。只是让开发人员难受了而已 |
 | 53 datoujiejie221 2021-06-07 09:03:07 +08:00 iOS appstore 的包也是对代码加密的啊，但是照样可以通过砸壳的方式分析，只要代码跑在客户端，就有被分析的可能。 只要接口可以被公网访问，就有安全风险，所以最主要的还是需要后端去做安全方面的防护。 |
 | 54 Mutoo 2021-06-07 09:13:09 +08:00 最近看了一下 WebUSB API，这东西配合加密狗可能才是 LZ 想要的吧。 |
 | 55 Blanke 2021-06-07 09:32:10 +08:00 安卓防抓包是个好设计？ 纸老虎 |
 | 56 zxcslove 2021-06-07 09:34:13 +08:00 2 开历史的倒车不得 house |
 | 57 0576coder 2021-06-07 10:02:03 +08:00 数据图表可以用 svg 之类的展示。这样就算别人爬你，那也大大增加它的难度 |
| 58 0576coder 2021-06-07 10:02:36 +08:00 还有一种办法 就是他们不下载 app 不给他们用，h5 只做部分展示- - 现在大厂不都这么搞 |
 | 59 wangyzj 2021-06-07 10:20:09 +08:00 真正的安全最起码都要后端验证，前端再怎么安全验证也只是防君子 |
 | 60 zengxs 2021-06-07 10:23:27 +08:00 安全性本来就是完全依赖于后端 |
 | 61 cyrbuzz 2021-06-07 10:24:38 +08:00 1 @Jirajine @love 个人认为增加攻击成本是一件有意义的事情。 之前大火的仿网抑云，它用的 AES+RSA 加密，公钥就放在前端代码里，但是混淆之后确实很难读懂，需要花很多时间，Star 最多的 NodeJS 版本的仓库时不时都会有要求增加 XXXAPI 的需求，加密算法有了，这就是打开浏览器打断点看请求的事情，还是有很多人不会，有了这个仓库，就变得人人都会加密网抑云的 API 了。 安卓这个防抓包对我这种半吊子来说还是有用的= =，hook APK 我是不会，不防抓包可能五分钟就把底裤给扒干净，就是兴趣来了顺手的事，防抓包可能就要花一天两天，这时候很大概率就放弃了，除非干翻它有大于这个成本的价值。 PS...为啥你俩的回复没有提醒= =，我被降权了嘛... |
 | 62 TypeError 2021-06-07 11:15:44 +08:00 WASM 编译成二进制混淆加壳？ |
 | 63 ragnaroks 2021-06-07 11:57:53 +08:00 aspnet core + blazor(SSR) 客户端只做 UI 渲染和事件监听，坏处是流量消耗相比传统 SSG 多，而且 CDN 效果较低 |
| 64 ragnaroks 2021-06-07 11:59:30 +08:00 我做了一个 steam 市场饰品控监站，使用了这种模式，群里就 300 多人使用，一个月打底 3T 出网 |
| 65 geekvcn 2021-06-07 11:59:31 +08:00 via iPhone 2 @ysc3839 恰恰相反，这些厂商反破解反盗版随心所欲，他们不把这任务交给码农，而是交给法务部。 现在网站被爬的最好处理方式就是稍微设置点门槛告诉爬的人我不想让你爬，你爬我就报警处理。家里防盗你门再好再坚固只要利益足够大小偷就会上门，所以社区治安才是防盗的关键而不是门。当然也不能全指望社区治安，有时候一个保险柜就很重要，后端就是保险柜，虽然也能打开，但是比开门难多了 |
 | 66 okakuyang 2021-06-07 13:55:22 +08:00 已经加入了，wasm 就是。 |
| 69 ragnaroks 2021-06-07 15:52:22 +08:00 @shyling 用的 L5630 的单机，16 线程 32G 内存 50M 带宽，CPU 的话基本可以忽略，忙时最多吃 4 线程，内存用的较多，忙时超过 8G 了(为防止被封 steamKey，数据都缓存到内存里面了) |
 | 70 coolxll 2021-06-07 16:02:18 +08:00 via Android 没必要 只会影响开发效率 |
 | 71 HankLu 2021-06-07 16:31:52 +08:00 via Android 你的代码被别人看到，别人的代码也一样被你看到，公平的 |
 | 72 Leon6868 2021-06-07 18:25:39 +08:00 个人认为前端本来就不是为了“安全”设计的，而是为了展示内容。 企图通过“加密客户端代码”来加强安全性是没意义的，何况前端是把源码发送到客户端上编译运行。 毕竟离开服务器的代码就不是你的了，如果你想提高 API 的破解难度，不如直接使用 CEF，或者编写对应平台的应用程序（但都能被破解）。 |
 | 73 i0error 2021-06-07 19:56:18 +08:00 1 项目总得兼容几年以内的旧版本浏览器吧，别人用旧版本浏览器不就能像现在这样看到代码了。 |
 | 74 keventseng 2021-06-07 21:31:46 +08:00 只能防君子防不了小人。意义不大。 |
 | 75 zyEros 2021-06-08 01:27:10 +08:00 via Android sablejs 自己写一个 JS 虚拟机运行自定义字节码 https://github.com/sablejs/sablejs |
 | 76 zycode277 2021-06-08 11:23:54 +08:00 不行的, 就算你认为的安卓不可抓包, 其实也很容易破解 |
 | 77 karloku 2021-06-08 20:16:12 +08:00 运行在用户机上的代码就不能指望 100%不被逆向, 所以对来自用户机的数据永远都要防范... |
 | 78 kaneg 2021-06-08 22:03:24 +08:00 1 前端加密就是掩耳盗铃。除非用户的行为是完全受控的，否则数据总会从最弱的一环泄露的。当年马奇诺防线号称坚不可摧，可人家就不跟你硬扛，直接绕过去。 |
 | 79 rwecho 2021-06-09 12:31:01 +08:00 wasm 能增加逆向难度 |
 | 80 Coioidea 2021-06-09 16:03:52 +08:00 前端加密有什么出于“安全”的目的啊？ 所有漏洞最后不还是后端防住的么？ 不是很明白你对前后端的理解。前端代码做业务逻辑本来就不应该啊 |
 | 81 collen 2021-06-09 17:39:11 +08:00 娱乐圈日常任务罢了 建议解决提出问题的人 |
Select Language