TCP会话劫持的应对
336 | 2015-05-14 13:50
不知道放在这个区里对不对，因为后面要用到javascript来解决问题，所以发在这里，如有不妥请告知。
事情起因：
最近点击各大电商主页，均被劫持至替人赚钱的链接，京东，当当，1号店无一幸免。各种花样的劫持，基本上就是靠Javasript吃饭。样本如下：
http://count.chanet.com.cn/click.cgi?a=527165&d=22338&u=&e=&url=http%3A%2F%2Fwww.jd.com
上网搜了一下TCP会话劫持，从lake2大侠那里学了点皮毛，参见《某电商网站流量劫持案例分析与思考》，用WireShark抓了一下包，本地出去的包TTL=64，正常从京东网站返回的TTL=56，而被劫持后返回的TTL=59，用tracert看了一下，
到 www.jdcdn.com [183.56.147.1] 的路由: 1问题应该就出在上面的某个地址上，这种劫持比DNS劫持还恶心，防不胜防，缓解的笨办法就是把那些重定向的域名通通在Host文件里定义成127.0.0.1，被重定向的网页就无法访问了，至少不当冤大头给人赚钱吧，但这种方法不是长久之计，网上有人提到一种办法就是通过代理的方法把数据包碎片化，让劫持的没办法一次性获取足够的数据知道你想去哪里，就不好下手劫持了，但是这种方法比较麻烦，我自己想了一个更笨的办法，但是比较好实现，我们知道劫持的即然是只有你访问电商时才下手，说明他有判断，可能跟他的性能有关系，数据量大了他也搞不定或者怕暴露，猜测他不会从IP地址入手，因为现在的分布式技术使得同一个网站不会对应简单的几个IP，那最有可能的就是从HTTP头中获取相关目的地信息，于是手工用Fiddler进行发包试验，先把Host这个HTTP头调整到所有HTTP头的后面，也就是最后一条，然后在HTTP头中插入一个自定义的HTTP头，它的值填充为长度很大的空白值，实验中为4K的空格，这样劫持的想要知道你的确切目的地就要进行大块的数据缓冲，否则Host头信息就无法抓取到，但这样的话他的设备性能能否承载就值得考虑，经实验十几次，这种方式发出的包收到都是正常的网页返回，再也没有被劫持，不知道自己的想法从理论上说对还是不对，在这里贴出希望各位大神们多多指导，如果这个想法可行的话，那唯一的缺点就是会给电商的服务器造成一丁点的额外付出，但是现在的WEB服务器应该能从容应对这种长度的HTTP头吧。实现的话我想可以在Chrome浏览器里通过插件的方式实现，Chrome里好象有一个web request的接口，可以在HTTP包发出前对HTTP头进行修正，用javascript应该能实现这种做法吧。有大神愿意造福大众来一个吗？
各种吐槽：
1#
hkAssassin | 2015-05-14 14:51
顶一个！2楼来回答！
2#
顺子 | 2015-05-14 15:37
我懂个卵哦！！
3#
南哥 | 2015-05-14 19:09
2楼屌爆炸伤三楼！由4楼来回答！
4#
0x12 (帽子掉了|多逛，少说话。|小学生 ) | 2015-05-14 19:50
头部302跳转怎么破
5#
336 | 2015-05-14 19:54
@0x12 我的想法是你只要让他取不到你的目的地，不触发他的劫持条件，他就不会往劫持你的回应包往里塞东西，包括头部302跳转这样的。
6#
MITM | 2015-05-14 22:55
强制用HTTPS啊！
7#
核攻击 (统治全球，奴役全人类！毁灭任何胆敢阻拦的有机生物！) | 2015-05-15 09:29
修改http头的想法不错。
文章来源于lcx.cc:TCP会话劫持的应对，如何避免HTTP被骨干线路劫持？
现在的客户端界面越做越好看了，很多用到了web技术，轻便、界面炫、更新快，但是这样web的缺点也就出来了，就是不稳定，容易受用户等因素影响。 因为很多客户端web是内嵌的，内部通信，所以很多对安全的考虑就很少，漏洞亦较多。在此，我想跟大家分享一下客户端的web…
- 左青龙
- 微信扫一扫
-
- 右白虎
- 微信扫一扫
-
评论