1、现象是什么？
大约从今年年初开始，很多人就发现，在浏览一些网站的时候，地址栏的url后面会被莫名其妙地加上“?curtime=xxxxxxxxxx”（x为数字），并且弹出广告窗口。很多人以为这是网站自己弹出的广告，也就没有在意。
我是属于很在意的那些人之一。
2、这是怎么回事？
经过测试和分析，我们发现，上述现象与使用何种浏览器无关（我们测试了各种流行的http客户端），与使用何种操作系统也无关（Linux用户也有相关报告）。我对出现该现象的IE浏览器进程进行了跟踪调试，没有发现任何异常。可以断定，并不是系统被安装了adware或者spyware。
那么是不是那些网站自己做的呢？后来发现，访问我们自己管理的网站时也出现了这种情况，排除了这个可能。
那么剩下唯一的可能就是：有人在某个或某几个关键网络节点上安装了inject设备，劫持了我们的HTTP会话——我实在是不愿相信这个答案，这个无耻、龌龊的答案。
伟大的谢洛克·福尔摩斯说过：当其他可能都被排除之后，剩下的，即使再怎么不可思议，也一定是答案。
为了验证这个想法，我选择了一个曾经出现过上述现象的网站附近网段的某个IP。直接访问这个IP的HTTP服务，正常情况下是没有页面的，应该返回 404错误。我写了一个脚本。不断访问这个IP，同时记录进出的数据包。在访问进行了120次的时候，结束请求，查看数据。120次请求中，118次返回的都是正常的404错误：
HTTP/1.1 404 Object Not Found Server: Microsoft-IIS/5.0 Date: Mon, 19 Jul 2004 12:57:37 GMT Connection: close Content-Type: text/Html Content-Length: 111 〈html〉〈head〉〈title〉Site Not Found〈/title〉〈/head〉 〈body〉No web site is configured at this address.〈/body〉〈/html〉
但是有两次，返回了这个:
HTTP/1.1 200 OK
Content-type: text/html
〈html〉
〈meta http-equiv='Pragma' content='no-cache'〉
〈meta http-equiv='Refresh' content='0;URL=?curtime=1091231851'〉
〈script〉
window.open('http://211.147.5.121/DXT06-005.htm', '', 'width=400,height=330');
〈/script〉
〈head〉
〈title〉〈/title〉
〈/head〉
〈body〉
〈/body〉
〈/html〉
更进一步分析数据包，可知劫持流程如下：
A、在某个骨干路由器的边上，躺着一台旁路的设备，监听所有流过的HTTP会话。这个设备按照某种规律，对于某些HTTP请求进行特殊处理。
B、当一个不幸的HTTP请求流过，这个设备根据该请求的seq和ack，把早已准备好的数据作为回应包，发送给客户端。这个过程是非常快的。我们的 HTTP请求发出之后，仅过了0.008秒，就收到了上面的回应。而任何正常的服务器都不可能在这么短的时间内做出回应。
C、因为seq和ack已经被伪造的回应用掉了，所以，真正的服务器端数据过来的时候，会被当作错误的报文而不被接受。
D、浏览器会根据〈meta http-equiv='Refresh' content='0;URL=?curtime=1091231851'〉这一行，重新对你要访问的URL进行请求，这一次，得到了请求的真正页面，并且调用window.open函数打开广告窗口。
在Google中以“PHP?curtime”、“htm?curtime”、“ASP?curtime”为关键字搜索，出现的基本上是国内网站，这表明，问题出在国内。用于inject的设备插在国内的某个或某几个大节点上。
3、现在怎么办？
在坏家伙被捉出来之前，我们要想不受这个玩意的骚扰，可以考虑下面的方法：
A、请各单位的网络管理员，在网络的边界设备上，完全封锁211.147.5.121。
B、在你自己的个人防火墙上，完全封锁211.147.5.121。
C、如果你的浏览器是Firefox、Opera、GreenBrowser、或者MyIE，可以把“http://211.147.5.121/*”丢到弹出窗口过滤列表中去。
绝不只是广告那么简单，这涉及到我们的选择，我们的自由，这比垃圾邮件更加肮脏和无耻。今天是广告，明天就可能在你下载软件的时候给你加个adware或者加个病毒进去，谁知道呢？我们的HTTP通信完全控制在别人手里。
4、如何把坏家伙揪出来？
从技术上，可以考虑下面的手段：
方法1：
伪造的回应数据中并没有处理TTL，也就是说，我们得到的回应数据中TTL是和inject设备位置相关的。以我收到的数据包为例，真实的服务器端回应 TTL是107，伪造的回应TTL是53。那么，从我们这里到被请求的服务器之间经过了21(128-107)个节点，从我们这里到inject设备经过了11(64-53)个节点。只需要traceroute一下请求的服务器，得到路由回溯，往外数第11个节点就是安插inject设备的地方！
方法2：
假如坏家伙也看到了这篇文章，修改了TTL，我们仍然有办法。在google上以下面这些关键字搜索：php?curtime,htm? curtime,asp?curtime,可以得到大量访问时会被inject的网址。编写脚本反复访问这些网址，验证从你的ip访问过去是否会被inject。将确实会被inject的结果搜集起来，在不同的网络接入点上挨个用traceroute工具进行路由回溯。分析回溯的结果。
上面我们已经说明了，坏家伙是在某个或者某些重要节点上安插了inject设备，那么这个节点必然在被inject的那些网址到我们的IP之间的某个位置上。例如有A、B、C、D四个被inject到的网站，从四个地方进行路由回溯的结果如下：
MyIP-12-13-14-15-65-[89]-15-57-A
MyIP-66-67-68-69-85-[89]-45-68-84-52-44-B
MyIP-34-34-36-28-83-[89]-45-63-58-64-48-41-87-C
MyIP-22-25-29-32-65-45-[89]-58-D
显然，inject设备极大可能就在“89”所在的机房。
方法3：
另一方面，可以从存放广告业面的211.147.5.121这个IP入手，whois查询结果如下：
inetnum: 211.147.0.0 - 211.147.7.255 netname: DYNEGY-COMMUNICATION descr: DYNEGY-COMMUNICATION descr: CO.LTD descr: BEIJING country: CN admin-c: PP40-AP tech-c: SD76-AP mnt-by: MAINT-CNNIC-AP changed: [email protected] 20011112 status: ALLOCATED PORTABLE source: APNIC person: Pang Patrick nic-hdl: PP40-AP e-mail: [email protected] address: Fl./8, South Building, Bridge Mansion, No. 53 phone: +86-10-63181513 fax-n +86-10-63181597 country: CN changed: [email protected] 20030304 mnt-by: MAINT-CNNIC-AP source: APNIC person: ShouLan Du address: Fl./8, South Building, Bridge Mansion, No. 53 country: CN phone: +86-010-83160000 fax-n +86-010-83155528 e-mail: [email protected] nic-hdl: SD76-AP mnt-by: MAINT-CNNIC-AP changed: [email protected] 20020403 source: APNIC
（出处：http://www.sheup.com）