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

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

  •  
  •   bigbigeggs · 5 天前 · 10060 次点击

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

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

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

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

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

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

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

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

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

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


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

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

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

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

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

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

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

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

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

    不做防重放即使加密通信也没用,但 HTTPS 自带加密和防重放功能,如果现在还使用原先的防重放做法,那它的主要用作就是提高反扒的难度。
    TeresaPanda
        48
    TeresaPanda  
       5 天前
    可以增加一点攻击者的调试难度吧
    yankebupt
        49
    yankebupt  
       5 天前
    @bigbigeggs 如果客户端不那么瘦,可以拿到自己的公网 ip 地址,那么在不那么信任时间戳(比如网络很差或 CPU 调度很差,NTP 精确不到 1 秒)的时候还能多一种选择
    毕竟重放攻击大部分时候是时间不同,ip 地址不同(有 ip 一样的,少见,毕竟攻击者自己拿不到回复了)
    猜测神经过敏一点的人甚至会用包 TTL 波动 filter 重放攻击要求重新登陆,我觉得太容易误判了……
    iX8NEGGn
        50
    iX8NEGGn  
       5 天前
    至于 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  
       5 天前
    第一次听说"接口防重放",查了下资料:
    "一条消息表示用户支取了一笔存款,攻击者完全可以多次发送这条消息而偷窃存款。"
    --- 来自: 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  
       4 天前
    很明显,你对重放的理解就不对。防重放是用来防中间人攻击的。不然你以为 https 的 seq_num 是用来干什么的。客户端攻击那不叫重放,最多叫 DDOS
    SSang
        53
    SSang  
       4 天前   ❤️ 1
    还有,幂等是幂等,重放是重放,看起来好像都是请求两次相同的数据,本质上一个是客户端行为,一个是中间人行为,一个是业务,一个是安全。
    SSang
        54
    SSang  
       4 天前
    1. 下单,支付,转账,这种一般是做幂等,但做不做幂等和做不做防重放没有关系。不是说你幂等了就不需要防重放了。
    2. 客户端一般只生成 nonce ,生成 token 干嘛?除非你要搞回调。
    3. 重放解决的是过程安全,你说的所谓客户端安全,那叫防抖或防 DDOS 吧。
    zhwguest
        55
    zhwguest  
       4 天前
    @Richared 正常用户基本上不可能重复出现 nonce ,如果有重复的 nonce 了,那基本上不是正常用户了,当然不提供正常服务啊。
    enumer
        56
    enumer  
       4 天前
    安全不绝对就是绝对不安全
    looveh
        57
    looveh  
       4 天前
    @wind1986 我也没用过,工作 7,8 年了。难怪这么菜😭我对锁什么的概念都很模糊
    Nosub
        58
    Nosub  
       4 天前
    op 主应该很少抓包,防止重放肯定不是脱裤子放屁;

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

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

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

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




    我怀疑你把防重放和防抖防重发混淆了
    yc8332
        75
    yc8332  
       4 天前
    redis 锁用 string ,get/set 能防住?这个水平到生产环境不会被搞死吗?
    lyxxxh2
        76
    lyxxxh2  
       4 天前
    @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  
       4 天前
    @x2420390517 虽然但是,密钥
    lizhisty
        78
    lizhisty  
       4 天前
    你这认知太挫了,能防住 90%的普通人就行
    restkhz
        79
    restkhz  
       4 天前
    @bigbigeggs 其实我觉得你说的是很有趣的。不知道为什么现在人们戾气这么重。
    这是很好的思考,这种质疑,是搞信息安全的素养。但是很明显基础知识不够。
    然后结论说的比较武断了,防止重放是必要的。但是你说的这种方法的确不是好方法,你对它的质疑是正确的。
    一般对抗重放都会引入随机和一次性。引入 Nonce 和速率限制可能是更有意义的做法。而不是用大家都知道的内容比如时间戳之类的 hash 得到 token 。
    如果有 HTTPS 也不用特别担心中间人搞重放了。

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

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

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

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

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

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

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

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