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