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

接口防重放 是不是存粹的脱了裤子放屁?

  •  
  •   bigbigeggs · 12 天前 · 10244 次点击

    防重放解决的是攻击者拿到 url 和参数之后,不断地请求服务端。

    1. 服务端针对下单,支付,转账这种操作肯定有幂等,肯定不能胡来乱来

    2. 放重放生成一个 token ,这个 token 人人都知道如何生成的,比如 timestap+参数 用 md5 进行加密,攻击者也可以完全模拟这个 token 的生成规则,来绕过服务端

    3. 像 https ,客户端私钥加签服务端公验证,都是解决过程中的安全,放重放解决“客户端”的安全,感觉完全没必要,反而增加了成本

    上周面试被问到,感觉存粹为了面试而面试,包括 sync ,lock ,多线程等,工作中根本用不到,完全不问业务上的问题,上来就啪啪的八股文走起。

    为了面试由此写了一篇接口放重放的文章,欢迎大家指正,真感觉多次一举,为了面试而面试。

    我真不相信,哪一家,真的在项目中写了防重放的实现逻辑。

    93 条回复    2024-06-13 16:24:19 +08:00
    yuhaofe
        1
    yuhaofe  
       12 天前   ❤️ 2
    重点是看防谁、防什么吧,不就是你文章里说的增加攻击人的成本吗,看你想不想防比如我这种看到个接口就想调试下的脚本 boy😂,可能看到麻烦点就放弃了
    zjp
        2
    zjp  
       12 天前 via Android
    云服务的接口都有防重放
    没有可以实现幂等的地方,只能在请求参数上防止重复请求
    porjac233
        3
    porjac233  
       12 天前 via iPhone   ❤️ 38
    你出门好会锁门吗? 你知道开锁师傅开个锁仅需几分钟吗? 锁门是不是脱裤子放屁?
    安全不绝对,所以安全措施就没必要存在?
    什么 2B 结论?
    kran
        4
    kran  
       12 天前 via Android
    甚至不知道哪家会不防请求重放
    whusnoopy
        5
    whusnoopy  
       12 天前
    我司写了

    一是出于本能的安全防御
    二是服务部署在平台方的私有云上,平台方的安全团队会时不时重放 URL 请求来做安全监测
    erwsd32ew
        6
    erwsd32ew  
       12 天前
    这是很常见的方案,你的最后一行疑问才是比较离谱的,没用过的话见也应该见过不少,特征为 timestamp+nonce 。
    IvanLi127
        7
    IvanLi127  
       12 天前   ❤️ 8
    不是拿不到 url 和参数的时候,把抓的包拿去重放吗?你开头是不是直接错了
    forvvvv123
        8
    forvvvv123  
       12 天前
    楼上正解,防止重放一般是考虑攻击者拿到了正常用户的流量,仿冒正常用户去请求的这种场景;
    StinkyTofus
        9
    StinkyTofus  
       12 天前   ❤️ 1
    只要不是个人随便玩玩的项目, 接口防重放是必须做的, 参数加签都是标配的。 但凡对接过其他公司的 API 都不会有这样的疑问。
    LeeReamond
        10
    LeeReamond  
       12 天前
    说了半天感觉不对。我感觉问题可能是现在传输层都用 tls 保护了,是否还有必要实现业务防重放
    ysc3839
        11
    ysc3839  
       12 天前 via Android
    按我个人理解,重放攻击属于中间人攻击,防重放攻击防不了客户端攻击,而 HTTPS 本身已经有防重放攻击的能力了,所以不需要自己特意去防重放攻击。你文章里提到的情况,实际不是重放攻击,而是“非官方客户端”,攻击者尝试绕过你的客户端逻辑,直接请求接口。
    LeeReamond
        12
    LeeReamond  
       12 天前
    还有一个问题是,例如 select 类操作,实现幂等很容易。新添加数据,加入幂等也不难。但是例如 A 给 B 转账这种操作能实现幂等吗?
    me1onsoda
        13
    me1onsoda  
       12 天前
    @zjp 能做防重放肯定能做幂等,防重放某种意义上也可以叫幂等吧
    Aloento
        14
    Aloento  
       12 天前   ❤️ 1
    安全不绝对 = 绝对不安全!
    wind1986
        15
    wind1986  
       12 天前   ❤️ 2
    包括 sync ,lock ,多线程等,工作中根本用不到
    想问问工作几年了, 怎么会这些用不到
    StinkyTofus
        16
    StinkyTofus  
       12 天前
    @wind1986 #15 我估计他都没说完, 事务,分布式锁我估计他也用不到🐶
    xmumiffy
        17
    xmumiffy  
       12 天前
    是,大部分人要的不是防重放,而是 1. 防爬虫 2. 限频
    akira
        18
    akira  
       12 天前   ❤️ 4
    啊? 重放最主要不是要解决用户手抖的问题么。。其他的都是顺带的呀
    zjp
        19
    zjp  
       12 天前
    @me1onsoda 说得不严谨,业务逻辑部分的幂等,不是请求的整体
    angeni
        20
    angeni  
       12 天前   ❤️ 2
    这种面试其实看的是你的下限,不是上限。

    个人感觉八股文其实是软件发展的一个脉络,应该懂但是不要照本宣科


    最后你的那句 `防重放用处不大` 是完全错误的,每个注入点都是血的教训我举个场景

    验证码重放可以遍历用户弱口令,短信发送重放可以刷接口或者做短信轰 X 炸
    binux
        21
    binux  
       12 天前 via Android   ❤️ 1
    最近做了一个买票刷票软件,虽然它对请求加密了,但是就是因为没有防重放,连解密都省了
    purrgil
        22
    purrgil  
       12 天前
    不防重放的话,抓包,下载个 curl 然后复制 http 请求到.bat 里循环执行,就直接刷得飞起了。
    weijancc
        23
    weijancc  
       12 天前
    我之前爬过许多大网站的接口, 防重放可以说是基操了.
    macaodoll
        24
    macaodoll  
       12 天前 via Android   ❤️ 1
    一看就是没接触过电商抢购功能。
    yxzblue
        25
    yxzblue  
       12 天前   ❤️ 7
    攻击者也可以完全模拟这个 token 的生成规则,来绕过服务端

    攻击者怎么会知道服务端的生成规则?
    skuuhui
        26
    skuuhui  
       12 天前
    在移动端刚兴起的年代,大部分防重放是为了解决弱网环境下重试导致的无效请求的问题。现在技术成熟了,确实失去了百分之 99 情况下的用处了。现在还执着追求这个的,要么历史原因,要么过于迂腐了。对于大部分程序员来说,模仿很容易,动脑真的很难
    crackidz
        27
    crackidz  
       12 天前
    重放不是指 TCP 流重放,是指 HTTP 的接口重放,不在同一层。
    即便通过 token 防止重放,也不应该单纯使用三方都知道的信息生成,至少应该包含攻击方不知道的信息
    x2420390517
        28
    x2420390517  
       12 天前   ❤️ 1
    你要不先看看你有多少错别字?
    2.token 的生成,是一种对原信息的签名操作,因为只有服务器有秘钥,所以你不可以伪造
    3.https 客户端什么时候能用私钥签?服务器用公钥验,你要不要看看你说的什么?
    darkengine
        29
    darkengine  
       12 天前
    想得挺美,我是不会点那个链接 /狗头
    InkStone
        30
    InkStone  
       12 天前
    1. 防重放的 nonce 可以服务端生成下发。
    2. 仅客户端也可以做防重放的,加固了解一下。别说什么加固也可以破,现实是就是有很多加固现在还好好运行在那里没被破。
    wqhui
        31
    wqhui  
       12 天前
    https 保证的是传输过程安全,但你怎么保证发起请求的人是可信的
    请求的 token 一般会混入一些像私钥一样的东西,要生成先得盗私钥

    多线程之类的不算八股文,日常偶尔就用,除非问你底层 JVM 怎么实现 sync 跟 lock ,19 年的账号居然没用过多线程。。
    geligaoli
        32
    geligaoli  
       12 天前
    接口的重放攻击,基本是必然遇到的。做过的项目,只要用户量一大,无论是否公开,必然在日志里面会记录到重放攻击。处理实际也好办,幂等或 hash 过滤。
    FawkesV
        33
    FawkesV  
       12 天前
    sync ,lock ,多线程 这不是很常用的吗??
    dhb233
        34
    dhb233  
       12 天前
    一个很现实的问题,支付接口是幂等的,QPS 能支持多大?防重放能支持多大 QPS ?
    jqknono
        35
    jqknono  
       12 天前
    认清自己
    cnevil
        36
    cnevil  
       12 天前
    "放重放生成一个 token ,这个 token 人人都知道如何生成的,比如 timestap+参数 用 md5 进行加密,攻击者也可以完全模拟这个 token 的生成规则,来绕过服务端"
    我怀疑你连 token 都没搞明白
    blankmiss
        37
    blankmiss  
       12 天前
    包括 sync ,lock ,多线程等,工作中根本用不到 , 你们是什么公司 还是说你菜的一匹
    salmon5
        38
    salmon5  
       12 天前
    salmon5
        39
    salmon5  
       12 天前
    你以为客户端 HTTPS 安全,客户端的浏览器可不老实。
    zhwguest
        40
    zhwguest  
       12 天前
    接口上 timestamp + nonce ,nonce 在 now + timer 时间范围内缓存,非常简单基础的方案,自己把问题想岔了吧?
    hallDrawnel
        41
    hallDrawnel  
       12 天前
    你甚至已经分析到了掘金的点赞防重复逻辑,在进一步想放重放逻辑不是千篇一律的啊。我们所有有重放可能的接口都有防重放逻辑。
    Richared
        42
    Richared  
       12 天前
    其实这些我一直有个疑问,不管用什么方式去做,都不能影响正常用户请求吧。比如 timestamp 过期了,正常的用户是给续期么?那么做攻击的人不是也可以续期。
    lovelylain
        43
    lovelylain  
       12 天前
    防重放 token 可能是上一步接口后台生成返回,上一步接口可能是验证用户登录态是用户行为触发,登录态和 token 都有时效性。
    sampeng
        44
    sampeng  
       12 天前   ❤️ 1
    这个问题嘛。。。怎么说呢。只能说,你经验太少。所以觉得很无所谓。

    我作为运维,要是谁的接口涉及到钱的不做防重放。我直接就贴脸放大了。是是是。你懒得做,然后我一看账单短信被刷几十万,被骂的人是我。研发来一句脱裤子放屁试试。。

    这是主问题。次问题。。是是是,你用不到就是八股文。

    那我是不是可以建一个画像:

    1.crud Boy
    2.不学习任何计算机底层知识。sync ,lock ,多线程在很多领域都要用。你只会 crud 当然涉及不到,你还不学。业务有啥?很高精尖吗?写个 crud 能写出花来?
    3.对于技术只停留在表象,不深究其原理和为什么要这么做

    你一句不信,我默默看着我司代码库里面这都是啥?我们组十年前的项目不带防重放,技术评审都过不去
    tomkliyes
        45
    tomkliyes  
       12 天前
    我理解的防重放:一个请求发过去了,但是服务器没有响应,客户端不知道是否成功了,如果没有幂等 id ,客户端再发一个请求过去,服务器可能把两个请求当成独立的,分别处理了。
    aino
        46
    aino  
       12 天前
    我以前和你一样的想法,后面我明白了,面试官问的就是想得到他想要的答案罢了,你想那么多干嘛呢,管他什么呢,问啥就说啥,你爽我也爽,也许你瞧不起面试官,觉得他问的东西浅薄,但是你也确实需要这份工作
    iX8NEGGn
        47
    iX8NEGGn  
       12 天前   ❤️ 2
    你把“重放”理解错了,计算机网络和网络安全相关书籍中都提到“重放攻击”,防重放是 HTTP 时代的一种安全措施,它是网络层的东西不是应用层,防的网络层中间人抓包后原封不动把包发给服务端。

    不做防重放即使加密通信也没用,但 HTTPS 自带加密和防重放功能,如果现在还使用原先的防重放做法,那它的主要用作就是提高反扒的难度。
    TeresaPanda
        48
    TeresaPanda  
       12 天前
    可以增加一点攻击者的调试难度吧
    yankebupt
        49
    yankebupt  
       11 天前
    @bigbigeggs 如果客户端不那么瘦,可以拿到自己的公网 ip 地址,那么在不那么信任时间戳(比如网络很差或 CPU 调度很差,NTP 精确不到 1 秒)的时候还能多一种选择
    毕竟重放攻击大部分时候是时间不同,ip 地址不同(有 ip 一样的,少见,毕竟攻击者自己拿不到回复了)
    猜测神经过敏一点的人甚至会用包 TTL 波动 filter 重放攻击要求重新登陆,我觉得太容易误判了……
    iX8NEGGn
        50
    iX8NEGGn  
       11 天前
    至于 OP 说的 “我真不相信,哪一家,真的在项目中写了防重放的实现逻辑。”

    我随便找了几个大厂的文档,签名中带有时间或者随机数的大都是用来放重放的:

    阿里: https://help.aliyun.com/zh/sdk/product-overview/rpc-mechanism
    SignatureNonce 参数的描述:“签名唯一随机数。用于防止网络重放攻击,建议您每一次请求都使用不同的随机数,随机数位数无限制。”

    腾讯: https://cloud.tencent.com/document/product/551/15615
    Nonce 参数的描述:“随机正整数,与 Timestamp 联合起来,用于防止重放攻击。”

    火山: https://www.volcengine.com/docs/6469/93892
    t 参数的描述:“来自火山引擎的事件通知请求默认过期时间是 10 分钟,如果一条事件请求通知中的 t 值所指定的时间已经过期,则可以判定此条事件请求通知无效,通过此方法可以防止网络重放攻击。”
    lyxxxh2
        51
    lyxxxh2  
       11 天前
    第一次听说"接口防重放",查了下资料:
    "一条消息表示用户支取了一笔存款,攻击者完全可以多次发送这条消息而偷窃存款。"
    --- 来自: https://juejin.cn/post/6890798533473992717
    总结: 扯淡。
    1. 发多次? 难道不校验金额?
    2. 并发的话,接口幂和悲观锁是吃干饭的?
    楼主第一句也说了:
    "服务端针对下单,支付,转账这种操作肯定有幂等,肯定不能胡来乱来"

    ***
    重放攻击(英語:replay attack ,或称为回放攻击)是一种恶意或欺诈的重复或延迟有效数据的网络攻击形式。 这可以由发起者或由拦截数据并重新传输数据的对手来执行。这是“中间人攻击”的一个较低级别版本。
    --来自: https://zh.wikipedia.org/wiki/%E9%87%8D%E6%94%BE%E6%94%BB%E5%87%BB

    所以可知,防重放就是专门针对这种攻击。
    不过正如楼主所说: 大部分都是 https,你都获取不到客户端请求。
    我也赞同是脱了裤子放屁。
    除非你项目是金融级别的。
    SSang
        52
    SSang  
       11 天前
    很明显,你对重放的理解就不对。防重放是用来防中间人攻击的。不然你以为 https 的 seq_num 是用来干什么的。客户端攻击那不叫重放,最多叫 DDOS
    SSang
        53
    SSang  
       11 天前   ❤️ 1
    还有,幂等是幂等,重放是重放,看起来好像都是请求两次相同的数据,本质上一个是客户端行为,一个是中间人行为,一个是业务,一个是安全。
    SSang
        54
    SSang  
       11 天前
    1. 下单,支付,转账,这种一般是做幂等,但做不做幂等和做不做防重放没有关系。不是说你幂等了就不需要防重放了。
    2. 客户端一般只生成 nonce ,生成 token 干嘛?除非你要搞回调。
    3. 重放解决的是过程安全,你说的所谓客户端安全,那叫防抖或防 DDOS 吧。
    zhwguest
        55
    zhwguest  
       11 天前
    @Richared 正常用户基本上不可能重复出现 nonce ,如果有重复的 nonce 了,那基本上不是正常用户了,当然不提供正常服务啊。
    enumer
        56
    enumer  
       11 天前
    安全不绝对就是绝对不安全
    looveh
        57
    looveh  
       11 天前
    @wind1986 我也没用过,工作 7,8 年了。难怪这么菜😭我对锁什么的概念都很模糊
    Nosub
        58
    Nosub  
       11 天前
    op 主应该很少抓包,防止重放肯定不是脱裤子放屁;

    很久之前我就写了一篇文章,
    HTTP 请求数据签名原理以及实战,https://nosub.net/posts/p/72
    对所有 HTTP 请求和返回数据做签名校验,拒绝中间人攻击; https://nosub.net/posts/p/70
    zephyru
        59
    zephyru  
       11 天前   ❤️ 3
    安全上用处的确不大,防脚本小子的确是很有用...毕竟打开 F12 复制个接口请求,各种模拟组合拉数据成本实在太低了...
    虽然逆向肯定是拿的到这些重放用的参数,但怎么都是成本不是
    dif
        60
    dif  
       11 天前
    多线程经常用到吧。
    dode
        61
    dode  
       11 天前
    领优惠礼品,网速慢,连点了几下,领到了好几份话费
    dode
        62
    dode  
       11 天前
    接口幂等,岂不是在更高的层次上实现了接口防重放
    ShuWei
        63
    ShuWei  
       11 天前
    op 还是太年轻了
    jinxjhin
        64
    jinxjhin  
       11 天前
    @iX8NEGGn #50 这些防重放手段只能用于防止中间人重放吧? https 为何还要防止中间人重放?
    iX8NEGGn
        65
    iX8NEGGn  
       11 天前
    @jinxjhin 我在 #47 也说了网络层防重放是 HTTP 时代的产物,至于为什么现在的大厂还在用,我也想知道,也有可能只是历史遗留做法而已。
    totoro52
        66
    totoro52  
       11 天前
    没接触过 = 没用
    index90
        67
    index90  
       11 天前
    1. 防重放和幂等是两码事,不要混为一谈。
    2. 你在胡言乱语,你需要搞清楚票据和签名的概念。除非攻击者掌握私钥,否者即使知道算法也无法模拟真实用户请求。
    3. https 也可以重放的,另外什么是“放重放解决“客户端”的安全”,又是胡言乱语。
    bigbigeggs
        68
    bigbigeggs  
    OP
       11 天前
    @cnevil token=MD5(timestamp+参数)生成的,假设你的项目中使用了防重放,我难道不知道你的这个 token 的生成规则?普遍都是这样生成的,很容易就能猜到的
    bigbigeggs
        69
    bigbigeggs  
    OP
       11 天前
    @yxzblue token=MD5(timestamp+参数)生成的,假设项目中使用了防重放,很容易就知道这个 token 的生成规则,所以这也是我比较诟病的一点,我想过通过加 salt 来解决,但是前端怎么安全保证这个 salt 呢?
    bigbigeggs
        70
    bigbigeggs  
    OP
       11 天前
    1. 大部分人回复还是比较友好的,一部分人戾气比较重,没必要哈,大家都相互不认识,纯纯上网冲浪
    2. 多线程的确不是八股文会用到,写差了。sync ,lock 谁在工作中用到?这不纯纯的八股文,要也是分布式锁
    3. 防重放我理解评论有些人应该讲清楚了,应该为了防止中间人攻击。但防不住真实的用户拿到 url ,去循环请求。比如掘金的那个点赞(掘金那个感觉是查了一边数据库,然后返回重复点赞的)
    4. 防重放的 token 生成规则,token=MD5(timestamp+参数)生成的,这个我感觉没用啊,人人都知道这个规则,我随便用 f12 就知道怎么生成的了
    yxzblue
        71
    yxzblue  
       11 天前
    @bigbigeggs token=MD5(timestamp+参数)
    已知 token: ff0ff58ff2b0901d47b8070ec0819812 ,timestamp: 1718117839 ,求解参数?
    Nosub
        72
    Nosub  
       11 天前 via iPhone
    op 主的问题是,自己有了结论,要别人认同你的结论,而大部分人不认同。

    其实这个问题很好理解,你家里有一把门锁,大家都觉得锁的存在是有价值的,有用的,你觉得没用,你的道理是门锁是都可以撬开,撬不开也可以砸开,安装了也是摆设。

    很多人应该会认同一个观点:安全只是相对的,无非是你要花多大的代价去做这件事,当代价,成本足够高的时候,你自然就放弃了,既然 op 觉得前端加密毫无意义,你可以试试去破解抖音的前端加密逻辑,是不是如你所说的按下 F12 就可以搞定。
    LeeReamond
        73
    LeeReamond  
       11 天前
    @zephyru 感觉除非搞前端加密,否则直接调到封装那里,我感觉所谓的成本也就是看五分钟代码的成本。。。至于前端加密,那更是神秘领域了。。
    GeruzoniAnsasu
        74
    GeruzoniAnsasu  
       11 天前
    @bigbigeggs

    1. 不要只考虑 CRUD ,多线程是软件架构中最最基础的特性之一,你只是目前没机会写到单机高性能非 HTTP 并发服务而已。
    2. 重放是个应用层行为,TLS 传输层从抽象原理上就解决不了,就像地基稳不稳影响不了房子盖得丑不丑。拿 HTTPS 出来讲说明你没理解安全风险出在哪里。
    3. 防重放不是在防中间人。是在防非法请求。 我合法用户自己把客户端的请求抓包下来,拿重放器短时高并发重放,有没有可能破坏业务系统的公平性或可靠性?我现在还是不是一个合法用户?
    4. 为什么「放重放的 token 规则」 与 MD5(timestamp+参数) 等价? 生成唯一凭证仅有你说的这一种可能性吗?
    5. 实现幂等性是不是要考虑防重放?




    我怀疑你把防重放和防抖防重发混淆了
    yc8332
        75
    yc8332  
       11 天前
    redis 锁用 string ,get/set 能防住?这个水平到生产环境不会被搞死吗?
    lyxxxh2
        76
    lyxxxh2  
       11 天前
    @bigbigeggs
    多线程 sync lock 我真用到。
    https://imgur.com/uftrwPY

    sync,是说 async 吧, 基本都是 js,后端比较少。pip install asyncio

    至于 lock,做接口幂需要啊。
    https://learnku.com/docs/laravel/7.x/cache/7482#8a1c7c
    再普遍点,db 锁不也是锁。

    我用没问题,要是问八股文,我估计会 gg 。
    yxd19
        77
    yxd19  
       11 天前
    @x2420390517 虽然但是,密钥
    lizhisty
        78
    lizhisty  
       11 天前
    你这认知太挫了,能防住 90%的普通人就行
    restkhz
        79
    restkhz  
       11 天前
    @bigbigeggs 其实我觉得你说的是很有趣的。不知道为什么现在人们戾气这么重。
    这是很好的思考,这种质疑,是搞信息安全的素养。但是很明显基础知识不够。
    然后结论说的比较武断了,防止重放是必要的。但是你说的这种方法的确不是好方法,你对它的质疑是正确的。
    一般对抗重放都会引入随机和一次性。引入 Nonce 和速率限制可能是更有意义的做法。而不是用大家都知道的内容比如时间戳之类的 hash 得到 token 。
    如果有 HTTPS 也不用特别担心中间人搞重放了。

    话说你面试被问这个问题...你准备的这个答案可能就不好...
    pkoukk
        80
    pkoukk  
       11 天前
    所有问题都是 成本-收益 的取舍问题
    没有绝对的安全,我想入侵你的系统,可以找黑鬼杀手绑架你,你说你系统还安全么?
    防重放措施虽然简陋,但手段也简单啊,成本也低啊,能防住同样简陋的人就行
    提高别人搞事的成本就行
    要不现在为什么这么多网站套一层 CF ?能彻底反爬么?能彻底防搞事么?
    不能,但能大幅提高你搞事的成本就行了
    uiosun
        81
    uiosun  
       11 天前
    > sync ,lock ,多线程等,工作中根本用不到

    什么薪资、什么业务,怎么会连这些都不用……现在连 PHP 都考虑做单核并行化了,到底是什么水准很迷惑。

    那不叫重试,那叫幂等性……给我看尴尬了。
    uiosun
        82
    uiosun  
       11 天前
    @bigbigeggs #70

    我看到你 70 楼的话了。怎么说呢,to C 业务 QPS 5~30k 起,并行化、分布式锁、链路熔断等,都会用到的。

    譬如你要处理 50G 甚至更多的一份数据,流、ETL 或 Excel 等方式进来,你就需要并行化和锁来保证你的数据可靠性——同时提升效率。

    只能说,多去大公司体验一下吧,QPS/数量级稍微高一些,很多问题都是需要你说的“用不到”的工具来更高效、可靠的解决。
    momo2789
        83
    momo2789  
       11 天前 via iPhone
    看了半天,也没看懂防重放的要点。
    giiiiiithub
        84
    giiiiiithub  
       10 天前
    脱裤子只会被爆菊
    johnhuangemc2
        85
    johnhuangemc2  
       10 天前
    防重放在 99.9%的情况下都没有价值, 但遇到那 0.1%的情况轻些要花掉一个下午的时间梳理恢复数据, 重些年终奖就泡汤了
    FengMubai
        86
    FengMubai  
       10 天前
    @bigbigeggs #69 客户端生成一对公私钥, 用私钥签名
    cnevil
        87
    cnevil  
       10 天前
    @bigbigeggs 我做安全的不是专业开发本不想跟你扯这么多,既然你回我了,那就跟你友好探讨一下,首先我认为 token 应该是服务端生成告诉客户端的,客户端怎么会知道你是用什么参数生成的呢?客户端只需要请求的时候带上即可。即攻击者获得了 url ,例如 del?id=1&token=xxx ,攻击者不知道这个用户现在有效的 token ,这个请求到服务器经过校验是无效的啊,为什么不能防止重放呢?
    其次,讨论的重点是重放,什么场景会有重放?重放有可能是想针对客户的攻击,例如我把嗅探到的其他用户转账的请求包重放;也可能是针对服务端的攻击,例如我把点赞重放来刷票,甚至也可能是用户觉得页面有点卡他又刷新了一下,你总不能说我在付款页面刷新一下你又扣了一遍款吧?重放不需要考虑你是怎么生成的,我只管把数据包重新发送就行,构造恶意的请求那是另一个范畴了。你可能把重放和 csrf 两个东西搞混了?
    反而我认为你还被其他人误导了,中间人和重放不是完全划等号的,逻辑应该是存在中间人攻击的话会出现在重放这个问题,因为我可以获取到你的数据包,但重放也不只在中间人攻击中存在,所以 token 防止不了 mitm ,只能用来解决重放。你想想我都能获取到你往来的请求了,你下一个 token 我也知道是什么,我完全可以构造一个请求带上服务端给你返回的有效 token 。但是我重放你请求的包是没用的,使用 https 才是可以解决 mitm 的方案,之一,https 也并不完全安全,尤其是支持一些老版本的 tls 。
    所以我才说你连 token 都没搞明白,因为我从你的描述中感觉你只知道 token 应该怎么生成,但你不知道怎么用,也不知道为什么要用
    wushenlun
        88
    wushenlun  
       10 天前 via Android
    如果所有人时间都是准的那么完全没问题
    ForkNMB
        89
    ForkNMB  
       10 天前
    @bigbigeggs
    (1)业务幂等,这后端应该做的,没啥好讨论的
    (2)保证请求参数合法,需要验证签名,确保参数是客户端发出的,客户端可以使用临时的密钥对,用私钥签名,请求的时候带上公钥,服务端验证签名。(用什么固定的 token 或者商量的盐值算 md5 什么的,都不太严谨,至于具体选择的算法不在此讨论
    (3)防重放,这个防的是中间人攻击,一般做法请求参数里面有时间戳和 nonce
    正常的项目,业务要关心的就是(1) 因为前人肯定搞定了(2)和(3),这种通用的流程一次做好封装好就可以了的
    009694
        90
    009694  
       10 天前 via iPhone
    openai 做防重放了吗?
    l4ever
        91
    l4ever  
       10 天前
    > 放重放生成一个 token ,这个 token 人人都知道如何生成的,比如 timestap+参数 用 md5 进行加密,攻击者也可以完全模拟这个 token 的生成规则,来绕过服务端

    ???有点意思,你说的是知道 jwt token 吗?

    还是你自己选一些参数经过组合再 md5 加密,带着这个结果提交?你认为这就是 token ?
    harryWebb
        92
    harryWebb  
       10 天前
    你太年轻了。。。。你根本不知道大部分的攻击者都是半桶水,只要稍微做一下防重放,他的破解成本就会几何倍上升,你要知道很多脚本 boy 都是没有阅读源码的能力的,你作为一个开发者,肯定会觉得破解很简单,这是处于你了解并且知晓的情况下,实际上破解人处于黑盒状态,完全不知道为什么请求会被拦截,造成信息紊乱,大大提高了破解的难度,就好像我之前为了防止别人功能,即使把公钥放前端代码里面加密,依然能挡住 99.999%的攻击,剩下 0.0001%的人,是真大神,也没必要防了
    zltningx
        93
    zltningx  
       9 天前
    CSRF Token 不是最基本的吗
    关于   ·   帮助文档   ·   博客   ·   API   ·   FAQ   ·   实用小工具   ·   2297 人在线   最高记录 6679   ·     Select Language
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.8.5 · 31ms · UTC 04:51 · PVG 12:51 · LAX 21:51 · JFK 00:51
    Developed with CodeLauncher
    ♥ Do have faith in what you're doing.