1
maocat 2023-10-08 15:07:55 +08:00
http 就是不安全的
|
2
rekulas 2023-10-08 15:10:22 +08:00 4
可以这样理解 通信安全和身份校验是两回事
|
3
Ayanokouji 2023-10-08 15:10:47 +08:00
有 https 不是也可以吗
|
4
IvanLi127 2023-10-08 15:13:32 +08:00
服务端好像从来都不知道请求是不是真正的用户吧,只能说发个凭证给用户,用户每次请求带有这个凭证就认定是这个用户。
这个和 HTTPS / HTTP 没啥关系,HTTPS 的安全,没双向认证的话,只能让用户安全些,服务端该不安全还是不安全。 |
5
nottyjay 2023-10-08 15:13:47 +08:00
jwt ,oauth 都是认证方案啊。因为 http 只能传输文本,没有别的更多的信息。不过,你要是说在 jwt 里还打包了你请求的源 ip ,然后通过对比后续请求过来的 ip 是不是和 jwt 中的一致,还是能勉强做一下安全的。但这种别人只要切换网络导致 ip 变动就会自动掉线了
|
6
noe132 2023-10-08 15:14:52 +08:00
换个说法,抓包拿到用户名密码之后模拟请求,是不是服务端根本分不出请求方是不是真正的用户。
|
7
MFWT 2023-10-08 15:16:05 +08:00
鉴权和加密和防篡改,是几码事
|
9
di1012 2023-10-08 15:18:27 +08:00
jwt 安不安全跟 http 没关系吧
|
10
kneo 2023-10-08 15:20:10 +08:00 via Android 1
安全是多方面,多环节的。任何一个环节有漏洞就是不安全的。认证只是其中一小步。
|
11
bing1178 2023-10-08 15:23:57 +08:00
jwt 是否安全 和 https 没有关系。
jwt 本身是自洽的。 但是不能明文传输,所以 jwt+https 结合使用就比较安全,比如网站的登录态 |
12
mightybruce 2023-10-08 15:26:16 +08:00
jwt 用的是是鉴权和防篡改,而不是考虑加密。jwt 也不存敏感信息
计算机安全是包含认证和授权,而不是仅仅加密。 |
13
celisee 2023-10-08 15:27:23 +08:00
看你如何定义安全啊
|
14
opengps 2023-10-08 15:33:14 +08:00
https 只是保证两个点之间中间链路传输的安全,所以通过一些操作也是可以用中间人方式绕过的
|
15
IvanLi127 2023-10-08 15:41:36 +08:00
@NoKey 得看客户端有没有信任中间人证书咯,不过这个也保不了服务端的安全呀,没双向认证的话只能保客户端不会访问错服务端。
|
16
pkoukk 2023-10-08 15:47:05 +08:00
鉴权机制只是安全机制的一部分,不是全部
有人拿着你的银行卡和密码就能取出钱来,银行不会考虑这人是你的亲戚还是绑匪 但是他可以通过行为机制冻结银行卡,如果你的转账目标是可以账户,如果你的金额过大等等,他会冻你的卡 如果你想保证账户安全,你还需要行为检测,账户风控系统,不能只靠鉴权 |
17
e7 2023-10-08 16:00:43 +08:00 1
jwt 有点像景点门票🎫,验票人员只能检验票的真假,但票是不是你的管不了
|
18
GrayXu 2023-10-08 16:05:32 +08:00
加密和认证不是一个东西
|
19
realJamespond 2023-10-08 16:07:46 +08:00
jwt 包含的信息怎么解开?
|
20
libook 2023-10-08 16:19:48 +08:00
JWT 只能保证 token 不能被伪造,没有其他安全功能。
HTTPS 只能保证数据出了终端后不被第三方知道内容,前提是终端是安全的。 在谈安全的时候,往往是谈针对哪种问题是安全的,没有任何一种手段能解决所有安全问题。 |
21
cnuser002 2023-10-08 16:39:08 +08:00
是的。
像 Oath ,jwt 这些认证手段,他们的主要作用是在 Web 应用中保持你的登录状态,不至于让你每次操作都要输入用户名和密码。 而 HTTPS ,它属于信道加密,防止你跟 web 应用的通信内容被监听、篡改,学名叫中间人攻击。像你用的抓包就是一种中间人攻击。HTTP 因为用的是明文传输,无法避免这个行为。而 HTTPS 结合了非对称加密+对称加密+CA 作保,确保你访问受信任的网站时,通信内容别人看不懂。 |
22
wanguorui123 2023-10-08 17:04:03 +08:00
https 主要是防止中间人劫持流量
|
23
gps949 2023-10-08 17:55:39 +08:00
并不绝对。比如,你可以在 http 协议下,通过 body 依照 tls 协议实现一遍。
|
24
BBCCBB 2023-10-08 18:08:44 +08:00
jwt 只是一个 token, 里面不存敏感信息. 不存在安不安全这一说法. 只要你的密钥不泄露. 就安全..
|
25
justdoit123 2023-10-08 18:23:27 +08:00
https 保证通讯安全。jwt 只是保证认证的格式,你用自己生成的随机数都可以,只不过它带有一些基础信息,可以省去向中心服务验证的过程。
客户端拿到 token 后,要自己存在一个安全的地方。 - 像浏览器场景,基本都要存在 http-only 的 cookie 里。这个 http-only 表示只有浏览器能读取,js 无法读取。跟 http/https 没关系。这样能保证攻击注入的 js 无法读出你的 token 。 - app 场景,应该是直接存 app 本地就好,别的 app 读取不到,没写过 app 不知道这方面的安全规范。 - server 2 server 场景,你拿到 token 后就自己存好,方式各种各样。大部分情况下,因为这个 server 只有你能访问,所以直接明文“随意”存个位置也是可以的。 你辛辛苦苦把 token 保存得很好,但是对外传输的时候竟然用了明文的 http ,那别人就特别容易截到你的 token ,来伪造你的请求。比如,把你网上银行的钱转走。。。 |
26
fescover 2023-10-08 18:33:38 +08:00
https + jwt + cookie ( httpOnly + secure + Samesite=Strict )+ ip + deviceId + reCAPTCHA
|
27
Ericcccccccc 2023-10-08 19:16:18 +08:00
这都不是一回事...
|
28
iX8NEGGn 2023-10-09 00:00:46 +08:00 via iPhone
最近好多帖子关于签名、jwt 、https 的,分不清“所谓安全”:
“第一种安全”:你不想你的接口被第三方工具请求,请求只能从你的客户端 APP 发出。 “第二种安全”:你的数据在传输过程中,不想被电信运营商等中间人偷看。 “第三种安全”:验证用户是是否已认证或已授权,防止越权访问。 |
29
duwenink248 2023-10-09 08:45:29 +08:00
你把安全理解成舒适,你把你开发的引用比喻成造车,
HTTP 相当于泥泞坑洼的小路 HTTPS 相当于平坦的路 你的程序和别人的程序就是车 安全与否就是舒适与否 别人的豪车开在 HTTP 上 也会觉得不舒服,这是外部的 你的平板车开在 HTTPS 上 觉得不舒服,这是内部导致的 |
30
codehz 2023-10-09 09:11:21 +08:00
@gps949 你不能安全实现,攻击者预计可以直接修改你的代码,剥离或者直接魔改加密代码,而且 TLS 的核心在于证书链,要有方法证明证书符合需求,因为你的代码和证书终究也还是通过 http 传输的
(当然你可以说你能给代码加 114514 层混淆,但这么比就没意思了) |
31
gps949 2023-10-09 09:30:18 +08:00
@codehz
还没回复你,你为啥要说 114514 层混淆这种先自己杠自己的话呢…… 个人从 0 手搓协议,完善性肯定有问题的。你不说我也认可,我相信每个人都认可。 但我只是说的一种可能性不是么?我一上来说的也是“并不绝对”,而不是“绝对安全”吧? 就比如 OpenSSL 也是肉体凡胎的人们写的,也出现过 Heartbleed 这样极为严重的 Bug 。也就是你即使不自己手搓,使用全球广泛使用被认可的现有协议实现,也依然不能绝对规避风险。 另外你提到证书链、代码这些,我是这个行业内的,所以这些很清楚。 即使你走 HTTPS 协议,浏览器也是通过 CSP 、KeyStore 、P11 这类接口调预先配置的证书链(受信根证书颁发机构),很多中间人攻击 HTTPS 协议,也是通过在客户端安装它的 CA 根证书实现的。 这些跟代码混淆不混淆这种前端技术没啥关系,因为 RSA 、SHA 这些 SSL/TLS 协议用到的密码算法套件实现可以完全公开,完全没必要混淆。至于公钥(证书)本身就是公开的,也没必要混淆。 SSL/TLS 协议本身保障能力也就是针对信道,无法保护终端。比如客户端篡改系统受信根证书颁发机构、客户端篡改代码让客户端不执行对服务端验证、客户端窃取已经解开的明文数据、(双向 SSL 情况下)客户端“骗签”这些,都不属于 SSL/TLS 保护范畴。仅仅靠标准浏览器+标准 HTTPS 协议本身(不添加其他 SSL/TLS 协议外的实现)也无法防范。 |
32
codehz 2023-10-09 09:40:04 +08:00
@gps949 问题就是中间人攻击在 http 的场景下,不需要在客户端上搞事情啊,只要中途魔改你的代码即可,你没有任何办法验证,因为验证的代码也可以被改,不是说你实现有问题导致出事,而是就算实现完全没问题,假设一点协议上的漏洞都没有,它也不能提供任何可靠的安全保障
https 的一个性质就是双方有一个预先共享的信息(和代码),而这个信息和代码显然不能通过同一个不安全的信道传输 一个最简单的攻击方案,中间人直接在它设备上模拟浏览器,将渲染结果传递给受害者,然后把受害者的输入通过这个模拟浏览器传回服务器,而这个过程中,受害者除了真的去阅读每一行代码以外(实际上不可能),没有任何感知 https 的情况,你中间人要做这个,在没有服务器的证书的情况下,就没办法伪造你服务器的身份,因为验证代码和证书链都是已经预制在客户端上的,你不能在不接触客户端的前提下去修改验证代码或者注入证书,因而客户端总是会显示证书错误信息 |
33
amxsa 2023-10-09 11:37:10 +08:00
这个问题也可以这么问:
没有 https 的情况下,Cookie 、SESSIONID 是不是也不安全? |
34
wtfedc 2023-10-09 14:20:38 +08:00
jwt 就是明文,只是保证没有被篡改,抓包的 jwt 可以随意用
|