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

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

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

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

    在谈安全的时候,往往是谈针对哪种问题是安全的,没有任何一种手段能解决所有安全问题。
    cnuser002
        21
    cnuser002  
       144 天前
    是的。

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

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