V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
villivateur
V2EX  ›  信息安全

怎么排查重放攻击的来源?还有,重放攻击这么常见吗?

  •  
  •   villivateur · 2023-04-21 12:17:09 +08:00 · 3181 次点击
    这是一个创建于 580 天前的主题,其中的信息可能已经有所发展或是发生改变。

    https://v2ex.com/t/933049 里写了我用 ESP8266 做了一个访问 HTTP URL 的开关,因为单片机很难做 HTTPS ,为了避免恶意访问和重放攻击,我写了一个简单的策略。

    ESP8266 用一个随机数乘以一个预共享的大整数,作为 URL 的参数之一,服务端判断是否合法并确保此随机数没被用过。

    然后实际测试发现服务端的 Log 中包含连续的两个访问请求,参数一样,相隔几分钟。我确定我的单片机代码正确。怎么排查重放攻击的来源呢?

    运营商是江苏电信。

    附图:

    18 条回复    2023-06-16 13:12:06 +08:00
    swulling
        1
    swulling  
       2023-04-21 12:26:53 +08:00
    最简单方案:用 HTTPS
    swulling
        2
    swulling  
       2023-04-21 12:27:48 +08:00
    ESP 也可以做 HTTPS ,如果慢可以挂一个加密专用芯片,能单独高速计算加密算法
    liuxu
        3
    liuxu  
       2023-04-21 12:28:50 +08:00
    查不了,非要查你得找公安去电信运营商查路由日志
    adai2
        4
    adai2  
       2023-04-21 12:29:03 +08:00
    类似这样 Authorization: Basic md5(username+":"+password+":"+extime)
    url 把 extime 带过去
    接收到再 MD5 核对下。

    可以吗
    lsk569937453
        5
    lsk569937453  
       2023-04-21 12:30:40 +08:00
    你这个源 IP 是本地的,应该可以记录下 request 的源 ip 的
    1423
        6
    1423  
       2023-04-21 12:31:07 +08:00
    IP 打出来就看到来源了呀
    jackyzy823
        7
    jackyzy823  
       2023-04-21 12:32:41 +08:00 via Android
    HTTP 的话全链路都能看到你的请求,说不定中间那个设备就是以缓存 /检测为目的再一次请求。(不如把参数放在 POST 请求里试试
    swulling
        8
    swulling  
       2023-04-21 12:35:22 +08:00
    如果就是做不了 HTTPS ,那就需要参考百度云、阿里云的 HTTP 鉴权方案。

    逻辑也很简单,就是让生成的认证信息有效时间(比如 10s 内),这样你的 HTTP 请求到达服务端后,如果在 1 分钟后被重放攻击,你的服务端就会拒绝掉非法请求。
    yyf1234
        9
    yyf1234  
       2023-04-21 12:35:54 +08:00 via iPhone
    post 就行了
    ysc3839
        10
    ysc3839  
       2023-04-21 13:17:33 +08:00 via Android
    看上去你是用了内网穿透,建议换成 WireGuard 来实现内网穿透,配置一下可以实现把源 IP 传递过来,然后就能 ban IP 了。
    fbichijing
        11
    fbichijing  
       2023-04-21 15:55:48 +08:00
    我有些好奇,你这种策略每一个 secret 应该存在着生效期。一方面内存一般会限制所有随机数内存的大小,另一方面过多的随机数是不是就会踢掉最早的随机数?如果这样的话,某人拿到这个数据包,等上几天(某些日期)以后,是不是就能重放成功了?
    我只是觉得这个策略和另一个软件的策略很像,个人感觉似乎存在上面的问题。没有恶意。
    nilai
        12
    nilai  
       2023-04-21 15:59:03 +08:00
    你这个策略应该是生效了的吧? 第二次重放的请求的响应是 403 了啊。
    villivateur
        13
    villivateur  
    OP
       2023-04-21 17:10:15 +08:00
    @fbichijing 是的,但我这个 buff 挺大的,我用的频率也不高,所以短期内是安全的。而且我也只是做了一个非常简单的策略,如果能上 AES 之类的加密会更好。


    @nilai 确实是生效了,我只是好奇这个重放攻击是哪来的
    qwq11
        14
    qwq11  
       2023-04-21 17:14:43 +08:00
    签个名就好了,rsa ,eddsa 随便选,应该不至于这些这没有吧
    8520ccc
        15
    8520ccc  
       2023-04-21 17:26:57 +08:00 via iPhone
    签名加时间,假设有效时间 10 分钟,那可以把 10 分钟内的请求 token 存到 redis 只要是存在的 token 就拒绝请求,超时也拒绝
    guomuzz
        16
    guomuzz  
       2023-04-21 19:16:37 +08:00
    @fbichijing 加个时间戳就行了 一般 client 到 server 5 分钟足够了 nonce + timestamp + signature(body+nonce+timestamp)
    realpg
        17
    realpg  
       2023-04-21 19:27:15 +08:00
    你自己调试这个接口用的啥?浏览器?

    建议彻底干掉 GET/POST 请求,我这边的 API 都是 PUT/DELETE 请求起步 就会少很多事儿
    server 也不 handle GET
    humbass
        18
    humbass  
       2023-06-16 13:12:06 +08:00 via Android
    时间 加 密钥生成 md5 ,服务端可以很方便的控制时间有效性,简单可行。
    关于   ·   帮助文档   ·   博客   ·   API   ·   FAQ   ·   实用小工具   ·   994 人在线   最高记录 6679   ·     Select Language
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.8.5 · 25ms · UTC 19:53 · PVG 03:53 · LAX 11:53 · JFK 14:53
    Developed with CodeLauncher
    ♥ Do have faith in what you're doing.