这是一个创建于 593 天前的主题，其中的信息可能已经有所发展或是发生改变。
对网络传输和安全这一块不太了解，最近公司让我们对接口出入参做个加解密，我便想去其他平台看看他们怎么做的，发现很多页面实际上都无法抓到实际的 XHR 接口，要么返回的是整个页面，要么直接在网络里面啥都找不到……
请问下大家这种具体是怎么做到的？是直接存在 CDN 之类的里面吗(可应该不会所有页面都在 CDN 吧)？
另外有必要对接口出入参做加解密吗？搜了一些文章，有些人说可以用 RSA 和 ASE 做加密，有些人又说出入参加解密根本没必要，因为 HTTPS 本身够安全，即使加密，前端代码也是公开的，能够直接破解。
 | 1 rqxiao 2024-02-26 15:50:58 +08:00  1 前端有代理服务器 |
 | 2 Moyyyyyyyyyyye PRO 1 服务器渲染做的 |
 | 3 flyqie 2024-02-26 15:52:18 +08:00 via Android 1 给个地址？ 真实请求无法隐藏。 |
 | 4 dapang1221 2024-02-26 15:52:31 +08:00 1 websocket quic 或者压根就是上古 MVC 架构服务器直接渲染出来的 - - |
 | 5 NelsonZhao 2024-02-26 15:52:59 +08:00 1 统一这个观点：因为 HTTPS 本身够安全，即使加密，前端代码也是公开的，能够直接破解。 建议问一下领导出入参加密的原因是啥。 |
| 6 flyqie nbsp; 2024-02-26 15:56:11 +08:00 via Android 1 |
 | 7 Puteulanus 2024-02-26 15:56:15 +08:00 1 你是不是遇上 SSR 的了，server side rendering 接口感觉一般是做签名，签名的函数再给混淆一下，防止用户模拟和重放 |
 | 8 clue 2024-02-26 15:57:04 +08:00 3 服务端渲染直出, websocket websocket 想要抓包, 得在一开始就打开 dev 面板, 在建立连接时抓到 另外对外开放的 API 一般不做加密(HTTPS 本身就够了)只做签名, 用于防重放/篡改, Timestamp+Nonce+Signature |
 | 9 corcre 2024-02-26 15:57:30 +08:00 1 MVC 可以做到, 也有可能是更远古的 PHP 混编整出来的 |
 | 10 flyingghost 2024-02-26 16:03:10 +08:00 1 https 只保护传输不被监听、窃取、篡改。 也就是客户端和服务器之间不会蹲有一个未知的“中间人”。 但客户端本身就是一个攻击面。如果客户端不安全，相当于一个逆向工程师蹲在浏览器里，所有输入、输出、渲染过程、前端交互逻辑、渲染数据都失密。 好在以上大部分都不怎么值钱，值钱的都服务端计算/渲染了。 唯一值钱的是当前账号个人数据，系统风险可控，法律风险更好甩，反倒是防护成本巨高效果不好，就这样吧。 |
 | 11 sniperhgy 2024-02-26 16:05:51 +08:00 1 现在有一些网站，也会专门针对“开发者模式”进行阻挠，之前想在一个外国的 online game 网站上用 F12 找到真正的游戏 rom 地址，结果直接就告诉我侦测到开发者模式，不能进行后续操作 |
 | 12 zorro2020 2024-02-26 16:09:19 +08:00 还遇到一些 APP 正常可以访问，手机一连代理，APP 就网络异常，什么请求都看不到了 |
 | 13 dyllen 2024-02-26 16:09:47 +08:00 1 曾经面试遇到面试官说 post 比 get 更安全，因为 get 参数放到 url 里面可以在地址栏直接复制。。。 |
 | 15 SoyaDokio 2024-02-26 16:10:55 +08:00 “开发者工具” 的 “网络监控” 里开启监控功能后看不到请求记录？？ 这个也行？有啥意义呢，抓包也都可以拿到阿？ 应该是我理解错了吧 |
 | 16 shadow1949 OP @Puteulanus 应该是 SSR ，之前只尝试打开一些网页，看不到正常出入参的接口感觉很奇怪。 现在重新去试了一些新增更新操作，发现 GET 请求基本都是返回页面，然后 POST 请求能够正常看到入参和出参的。 |
 | 17 me1onsoda 2024-02-26 16:11:17 +08:00 @NelsonZhao 增加破解成本，提高破解门槛 |
 | 18 blackcellcode 2024-02-26 16:26:55 +08:00 SSR |
 | 19 error451 2024-02-26 16:28:30 +08:00 https 可以防止中间人获取请求数据内容来进行中间人攻击。 对参数进行加密，目的是为了防止参数篡改重放， 就是攻击者修改原来的参数再次请求。 这两个安全措施的目的并不一样啊。 如果 API 加了安全令牌，时间戳等防重放的安全措施，则就没必要再对参数整体加密了。 |
 | 21 lm930129 2024-02-26 17:16:50 +08:00 参数加密确实没啥用，因为你肯定有个前端解密的过程，你前端代码是没法加密的。比如，某政府网站，接口通过物理 key 进行加解密，传出和传入参数都是密文，但是意义不大的，你在控制台，直接调用前端加密和解密函数，就可以得到明文的。 |
 | 22 datoujiejie221 2024-02-26 17:19:11 +08:00 现在单一的加解密已经很难防止破解了，看了 https 协议，你会发现最复杂的不是加解密，而是双方随机数的生成，就像 gpt 和文心一言网页版，虽然请求可以抓到明文，但是随机 token 的生成几乎不能破解。 |
 | 23 F7TsdQL45E0jmoiG 2024-02-26 17:24:20 +08:00 前后端分离天生就不安全 |
 | 24 ljsh093 2024-02-26 17:36:04 +08:00 ws 传输的吧 |
 | 25 Light3 2024-02-26 17:41:33 +08:00 十年前的模版渲染？ |
 | 26 lyc8503 2024-02-26 17:50:30 +08:00 可能性: 1. 使用了模板渲染 2. Websocket 3. Server-side rendering 解决方法: 1 直接用 bs4 解析 html 拿数据 2 直接看 Websocket 3 可以直接读取 __NEXT_DATA__ 如果要接口加密，自己 JS 写个签名算法，混淆 JS 能提升逆向难度，但也是治标不治本，有经验的人来很快就能分析出来 正确方法是后端进行风控，比如限制手机号登录，限制 IP 等 |
 | 27 sampeng 2024-02-26 17:57:39 +08:00 https 没必要把接口做加密。直接做签名就好了。签名包含时间。后端就能做风控了 |
 | 28 xiangyuecn 2024-02-26 19:12:44 +08:00 万物皆可破解，就看值不值 |
 | 29 Nosub 2024-02-26 19:22:28 +08:00 via Android 首先要说的是安全只是相对的，后端渲染和 socket 本身也有自己的局限性，数据全部加密不是不行，成本太高，前后端都要加解密，@sampeng 这个哥们说的基本是对的，如果网站本身已经是 https 了，做 api 的接口签名校验就可以了，敏感的数据还是要加密的，比如注册，登陆时候的账号密码，刚好我最近写了一篇文章，感兴趣的可以看看，https://nosub.net/posts/p/72 |
 | 30 kahlkn 2024-02-26 20:46:28 +08:00 前端加密只能防止一些门外汉（不过像登录账号密码等，可以考虑加个密）。 专心搞破解的，前端加密没啥用。 你说的那种抓不到 xhr ，大概率两种，一种就是服务端 渲染成 Html 直接到浏览器（比如 nodejs 服务端 和 古早的模板引擎）。 还有一种就是它走的是 JS ，再 某个 JS 文件中包含了数据，然后渲染到前端界面。 |
 | 31 gitlight 2024-02-26 20:49:42 +08:00 可能做 SSR 了 |
 | 32 rockyliang 2024-02-27 10:20:53 +08:00 @Nosub #29 ，文章里的 HTTPS 加解密流程图已经过时了，现在的 HTTPS 基本上都是使用 ECDHE 密钥交换协议，服务器的公钥每次都是随机生成的，并不会使用证书里的公钥来加密 AES 密钥 |
 | 33 Promtheus 2024-02-27 13:46:29 +08:00 1 很有可能是因为他请求的后台接口应用不是你前段看到的这个应用，是一个独立的应用。这样你就 f12 看不到了。抓包才可以看到 |
Select Language