V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
NoKey
V2EX  ›  程序员

没有 https 的情况下, jwt 是不是也不安全?

  •  
  •   NoKey · 2023-10-08 15:01:44 +08:00 · 3602 次点击
    这是一个创建于 402 天前的主题,其中的信息可能已经有所发展或是发生改变。
    抓包拿到 jwt 之后模拟请求,是不是服务端根本分不出请求方是不是真正的用户。
    所以说,所有的安全,都应该是由 https 来兜底?
    其他各种 jwt ,oauth 什么的,都是一种认证方法,不是安全机制?
    34 条回复    2023-10-09 14:20:38 +08:00
    maocat
        1
    maocat  
       2023-10-08 15:07:55 +08:00
    http 就是不安全的
    rekulas
        2
    rekulas  
       2023-10-08 15:10:22 +08:00   ❤️ 4
    可以这样理解 通信安全和身份校验是两回事
    Ayanokouji
        3
    Ayanokouji  
       2023-10-08 15:10:47 +08:00
    有 https 不是也可以吗
    IvanLi127
        4
    IvanLi127  
       2023-10-08 15:13:32 +08:00
    服务端好像从来都不知道请求是不是真正的用户吧,只能说发个凭证给用户,用户每次请求带有这个凭证就认定是这个用户。
    这个和 HTTPS / HTTP 没啥关系,HTTPS 的安全,没双向认证的话,只能让用户安全些,服务端该不安全还是不安全。
    nottyjay
        5
    nottyjay  
       2023-10-08 15:13:47 +08:00
    jwt ,oauth 都是认证方案啊。因为 http 只能传输文本,没有别的更多的信息。不过,你要是说在 jwt 里还打包了你请求的源 ip ,然后通过对比后续请求过来的 ip 是不是和 jwt 中的一致,还是能勉强做一下安全的。但这种别人只要切换网络导致 ip 变动就会自动掉线了
    noe132
        6
    noe132  
       2023-10-08 15:14:52 +08:00
    换个说法,抓包拿到用户名密码之后模拟请求,是不是服务端根本分不出请求方是不是真正的用户。
    MFWT
        7
    MFWT  
       2023-10-08 15:16:05 +08:00
    鉴权和加密和防篡改,是几码事
    NoKey
        8
    NoKey  
    OP
       2023-10-08 15:18:00 +08:00
    @IvanLi127 走 https 的话,数据加密,可以避免中间抓包吧
    di1012
        9
    di1012  
       2023-10-08 15:18:27 +08:00
    jwt 安不安全跟 http 没关系吧
    kneo
        10
    kneo  
       2023-10-08 15:20:10 +08:00 via Android   ❤️ 1
    安全是多方面,多环节的。任何一个环节有漏洞就是不安全的。认证只是其中一小步。
    bing1178
        11
    bing1178  
       2023-10-08 15:23:57 +08:00
    jwt 是否安全 和 https 没有关系。

    jwt 本身是自洽的。 但是不能明文传输,所以 jwt+https 结合使用就比较安全,比如网站的登录态
    mightybruce
        12
    mightybruce  
       2023-10-08 15:26:16 +08:00
    jwt 用的是是鉴权和防篡改,而不是考虑加密。jwt 也不存敏感信息
    计算机安全是包含认证和授权,而不是仅仅加密。
    celisee
        13
    celisee  
       2023-10-08 15:27:23 +08:00
    看你如何定义安全啊
    opengps
        14
    opengps  
       2023-10-08 15:33:14 +08:00
    https 只是保证两个点之间中间链路传输的安全,所以通过一些操作也是可以用中间人方式绕过的
    IvanLi127
        15
    IvanLi127  
       2023-10-08 15:41:36 +08:00
    @NoKey 得看客户端有没有信任中间人证书咯,不过这个也保不了服务端的安全呀,没双向认证的话只能保客户端不会访问错服务端。
    pkoukk
        16
    pkoukk  
       2023-10-08 15:47:05 +08:00
    鉴权机制只是安全机制的一部分,不是全部
    有人拿着你的银行卡和密码就能取出钱来,银行不会考虑这人是你的亲戚还是绑匪
    但是他可以通过行为机制冻结银行卡,如果你的转账目标是可以账户,如果你的金额过大等等,他会冻你的卡
    如果你想保证账户安全,你还需要行为检测,账户风控系统,不能只靠鉴权
    e7
        17
    e7  
       2023-10-08 16:00:43 +08:00   ❤️ 1
    jwt 有点像景点门票🎫,验票人员只能检验票的真假,但票是不是你的管不了
    GrayXu
        18
    GrayXu  
       2023-10-08 16:05:32 +08:00
    加密和认证不是一个东西
    realJamespond
        19
    realJamespond  
       2023-10-08 16:07:46 +08:00
    jwt 包含的信息怎么解开?
    libook
        20
    libook  
       2023-10-08 16:19:48 +08:00
    JWT 只能保证 token 不能被伪造,没有其他安全功能。
    HTTPS 只能保证数据出了终端后不被第三方知道内容,前提是终端是安全的。

    在谈安全的时候,往往是谈针对哪种问题是安全的,没有任何一种手段能解决所有安全问题。
    cnuser002
        21
    cnuser002  
       2023-10-08 16:39:08 +08:00
    是的。

    像 Oath ,jwt 这些认证手段,他们的主要作用是在 Web 应用中保持你的登录状态,不至于让你每次操作都要输入用户名和密码。

    而 HTTPS ,它属于信道加密,防止你跟 web 应用的通信内容被监听、篡改,学名叫中间人攻击。像你用的抓包就是一种中间人攻击。HTTP 因为用的是明文传输,无法避免这个行为。而 HTTPS 结合了非对称加密+对称加密+CA 作保,确保你访问受信任的网站时,通信内容别人看不懂。
    wanguorui123
        22
    wanguorui123  
       2023-10-08 17:04:03 +08:00
    https 主要是防止中间人劫持流量
    gps949
        23
    gps949  
       2023-10-08 17:55:39 +08:00
    并不绝对。比如,你可以在 http 协议下,通过 body 依照 tls 协议实现一遍。
    BBCCBB
        24
    BBCCBB  
       2023-10-08 18:08:44 +08:00
    jwt 只是一个 token, 里面不存敏感信息. 不存在安不安全这一说法. 只要你的密钥不泄露. 就安全..
    justdoit123
        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 ,来伪造你的请求。比如,把你网上银行的钱转走。。。
    fescover
        26
    fescover  
       2023-10-08 18:33:38 +08:00
    https + jwt + cookie ( httpOnly + secure + Samesite=Strict )+ ip + deviceId + reCAPTCHA
    Ericcccccccc
        27
    Ericcccccccc  
       2023-10-08 19:16:18 +08:00
    这都不是一回事...
    iX8NEGGn
        28
    iX8NEGGn  
       2023-10-09 00:00:46 +08:00 via iPhone
    最近好多帖子关于签名、jwt 、https 的,分不清“所谓安全”:
    “第一种安全”:你不想你的接口被第三方工具请求,请求只能从你的客户端 APP 发出。
    “第二种安全”:你的数据在传输过程中,不想被电信运营商等中间人偷看。
    “第三种安全”:验证用户是是否已认证或已授权,防止越权访问。
    duwenink248
        29
    duwenink248  
       2023-10-09 08:45:29 +08:00
    你把安全理解成舒适,你把你开发的引用比喻成造车,
    HTTP 相当于泥泞坑洼的小路
    HTTPS 相当于平坦的路
    你的程序和别人的程序就是车
    安全与否就是舒适与否
    别人的豪车开在 HTTP 上 也会觉得不舒服,这是外部的
    你的平板车开在 HTTPS 上 觉得不舒服,这是内部导致的
    codehz
        30
    codehz  
       2023-10-09 09:11:21 +08:00
    @gps949 你不能安全实现,攻击者预计可以直接修改你的代码,剥离或者直接魔改加密代码,而且 TLS 的核心在于证书链,要有方法证明证书符合需求,因为你的代码和证书终究也还是通过 http 传输的
    (当然你可以说你能给代码加 114514 层混淆,但这么比就没意思了)
    gps949
        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 协议外的实现)也无法防范。
    codehz
        32
    codehz  
       2023-10-09 09:40:04 +08:00
    @gps949 问题就是中间人攻击在 http 的场景下,不需要在客户端上搞事情啊,只要中途魔改你的代码即可,你没有任何办法验证,因为验证的代码也可以被改,不是说你实现有问题导致出事,而是就算实现完全没问题,假设一点协议上的漏洞都没有,它也不能提供任何可靠的安全保障
    https 的一个性质就是双方有一个预先共享的信息(和代码),而这个信息和代码显然不能通过同一个不安全的信道传输
    一个最简单的攻击方案,中间人直接在它设备上模拟浏览器,将渲染结果传递给受害者,然后把受害者的输入通过这个模拟浏览器传回服务器,而这个过程中,受害者除了真的去阅读每一行代码以外(实际上不可能),没有任何感知
    https 的情况,你中间人要做这个,在没有服务器的证书的情况下,就没办法伪造你服务器的身份,因为验证代码和证书链都是已经预制在客户端上的,你不能在不接触客户端的前提下去修改验证代码或者注入证书,因而客户端总是会显示证书错误信息
    amxsa
        33
    amxsa  
       2023-10-09 11:37:10 +08:00
    这个问题也可以这么问:
    没有 https 的情况下,Cookie 、SESSIONID 是不是也不安全?
    wtfedc
        34
    wtfedc  
       2023-10-09 14:20:38 +08:00
    jwt 就是明文,只是保证没有被篡改,抓包的 jwt 可以随意用
    关于   ·   帮助文档   ·   博客   ·   API   ·   FAQ   ·   实用小工具   ·   5399 人在线   最高记录 6679   ·     Select Language
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.8.5 · 37ms · UTC 07:26 · PVG 15:26 · LAX 23:26 · JFK 02:26
    Developed with CodeLauncher
    ♥ Do have faith in what you're doing.