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