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

HTTP 会话劫持防御想法

  •  1
     
  •   heiher · 2014-09-10 20:52:17 +08:00 · 4669 次点击
    这是一个创建于 3736 天前的主题,其中的信息可能已经有所发展或是发生改变。
    鉴于当前 HTTP 会话劫持几乎都是针对 HTTP 请求的首个 TCP 数据承载包的(是否存在能够维护独立的 TCP 上下文的方案不确定,个人觉得当前在用的系统没有实现的),是否人为干预HTTP请求在两个或多个独立的TCP承载包中就可以使得劫持程序不命中呢?
    19 条回复    2014-09-17 17:50:54 +08:00
    lehui99
        1
    lehui99  
       2014-09-10 20:55:29 +08:00 via Android
    想了2个星期这种方法了,做个proxy进行拆包,可惜一直很忙没时间做。
    dant
        2
    dant  
       2014-09-10 23:27:35 +08:00 via iPhone
    把第一个包拆开,比如

    HTTP/1
    ---------
    .1 GET /
    Accept-****
    dant
        3
    dant  
       2014-09-10 23:29:55 +08:00 via iPhone
    手滑按快了。。

    当时写出这样一个程序之后发现电信的劫持暂停了(或许跟我在微博上问候了它们的亲人有关),所以没法测试。等到后来再遇到劫持的时候就找不到了。。
    julyclyde
        4
    julyclyde  
       2014-09-11 07:51:59 +08:00 via iPad
    tcp不是包,而是流
    首先要坚定这个信念,然后再谈别的
    heiher
        5
    heiher  
    OP
       2014-09-11 08:52:12 +08:00
    @julyclyde 从应用层看是流,但劫持程序的角度实际在传输层,应该是由于维护网络上所有的 TCP 会话上下文开销很大,而且这样做可能也不会带来太多的好处。我想多数的劫持程序还是假设一个完整(或至少包含了 QueryString, Host)的 HTTP 请求在第一个包含数据的 TCP 包中的,如果打破这个假设劫持程序的匹配应该就不会命中了。我只是在想从哪个层面实现最简单、方便、通用。来这里和大家讨论一下。
    heiher
        6
    heiher  
    OP
       2014-09-11 08:58:30 +08:00
    @lehui99 工作在应用层的 proxy 如何保证一定会拆包呢?是通过延迟控制吗?
    mengzhuo
        7
    mengzhuo  
       2014-09-11 09:34:50 +08:00
    @heiher

    应用层才是最方便的
    MITM攻击层出不穷,工具也不少

    只是这样劫持需要伪造的证书得是可信CA发的
    一般CA会向域名注册信息里的邮箱发封邮件确认
    苹果、Linux、Windows都经常更新证书的可靠性
    所以无解
    typcn
        8
    typcn  
       2014-09-11 09:41:51 +08:00
    普及 HTTPS 才是关键
    lehui99
        9
    lehui99  
       2014-09-11 14:38:33 +08:00 via Android
    @heiher setsockopt中有多种方式可以控制发送缓冲区
    heiher
        10
    heiher  
    OP
       2014-09-11 14:42:53 +08:00
    @lehui99 我试试这个方式看看行不行,我正好有一个 socks5 server,https://github.com/heiher/hev-socks5-proxy
    heiher
        11
    heiher  
    OP
       2014-09-11 16:11:19 +08:00
    @lehui99 实现了一个代理版本(https://github.com/heiher/hev-socks5-proxy/tree/anti-hijack),方式是前向链路在完成 Socks5 协议处理后,将前向链路的 Buffer 长度限制在了 16 字节。抓包看的确被拆分了:
    p0: GET / HTTP/1.1\r\n
    p1: Host: xxxx ....
    lehui99
        12
    lehui99  
       2014-09-11 17:15:45 +08:00 via Android
    @heiher 嗯,算是完成了我一直想做的东西了。本来设想还包括使用libpcap检测服务器回包的ttl,如果不一致则说明被劫持。如果是get则重发请求,其他的断开链接。然后把libpcap做成可选项,可以选择是否启用。
    heiher
        13
    heiher  
    OP
       2014-09-11 17:26:53 +08:00
    @lehui99 TTL 正常情况下就有可能变化。
    julyclyde
        14
    julyclyde  
       2014-09-11 19:22:32 +08:00 via iPad
    按包替换,后面根本拼不出来
    heiher
        15
    heiher  
    OP
       2014-09-11 21:06:15 +08:00
    @julyclyde 按包替换是什么意思?
    heiher
        16
    heiher  
    OP
       2014-09-11 21:06:39 +08:00
    @julyclyde 这个按包替换是什么意思?
    jedihy
        17
    jedihy  
       2014-09-12 19:37:53 +08:00
    @lehui99 听说你这样做会触发GFW的IP封锁
    heiher
        18
    heiher  
    OP
       2014-09-14 10:38:33 +08:00
    @jedihy 这是为什么?
    lehui99
        19
    lehui99  
       2014-09-17 17:50:54 +08:00
    @heiher 这种及其偶然的情况基本上可以忽略了。


    @jedihy 封锁哪个IP?
    关于   ·   帮助文档   ·   博客   ·   API   ·   FAQ   ·   实用小工具   ·   3753 人在线   最高记录 6679   ·     Select Language
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.8.5 · 24ms · UTC 10:32 · PVG 18:32 · LAX 02:32 · JFK 05:32
    Developed with CodeLauncher
    ♥ Do have faith in what you're doing.