为什么“浏览器劫持”能够如此猖狂呢？放眼众多论坛的求助贴，我们不时可以看到诸如“我的IE被主页被改了，我用杀毒工具扫了一遍都没发现病毒，我把主页改回自己的地址，可是一重启它又回来了！”、“我的系统一开机就跳出一个广告，我明明用了最新版的杀毒软件的啊！”等这类关于IE异常问题的求助，80%的提问者都表示纳闷，他们已经安装了杀毒软件，可是IE仍然被“黑”了，这又是为什么？
其实这些都是典型的“浏览器劫持”现象，但是受害者不是已经安装了杀毒软件吗？为什么浏览器依然躲不过这只黑手？许多用户对这个领域都存在一种误区心理：浏览器劫持？我有最新的杀毒软件，我不怕！
于是，当他们遭遇“浏览器劫持”时，惊讶了。
要知道，杀毒软件自身也只是一种辅助工具，它不可能完全保护系统的安全，更何况，杀毒软件用户必须知道一个事实：“浏览器劫持”的攻击手段是可以通过被系统认可的“合法途径”来进行的！杀毒软件只能通过“特征码”的形式来判断程序是否合法，但这是建立在人为定义以后的，而实施“浏览器劫持”的程序可以有很多，防不胜防。
为什么说“浏览器劫持”可以说是合法的呢？因为大部分浏览器劫持的发起者，都是通过一种被称为“BHO”（Browser Helper Object，浏览器辅助对象）的技术手段植入系统的。
BHO是微软早在1999年推出的作为浏览器对第三方程序员开放交互接口的业界标准，它是一种可以让程序员使用简单代码进入浏览器领域的“交互接口”（INTERACTIVED Interface）。通过BHO接口，第三方程序员可以自己编写代码获取浏览器的一些行为（Action）和事件通知（Event），如“后退”、“前进”、“当前页面”等，甚至可以获取浏览器的各个组件信息，像菜单、工具栏、坐标等。由于BHO的交互特性，程序员还可以使用代码去控制浏览器的行为，比如常见的修改替换浏览器工具栏、在浏览器界面上添加自己的程序按钮等操作，而这些操作都被视为“合法”的，这就是一切罪恶根源的开始。
BHO的出现帮助程序员更好的打造个性化浏览器或者为自己的程序实现了方便简洁的交互功能，可以说，如果没有BHO接口的诞生，我们今天就不能用一些工具实现个性化IE的功能了。从某一方面来看，BHO的确是各种缤纷网络互动功能的幕后功臣，但是一切事物都是有两面性的，这个恒古不变的真理同样对BHO有效，于是就有了今天让安全界头痛的“浏览器劫持”的攻击手段诞生。
看看前面我提到的BHO接口特性，你想到了什么？BHO可以获知和实现浏览器的大部分事件和功能，也就是说，它可以利用少量的代码控制浏览器行为。程序员可以设计出一个BHO按钮以实现用户点击时通知浏览器跳转到某个页面完成交互功能，当然就可以进一步写出控制浏览器跳转到他想让用户去的页面，这就是最初的“浏览器劫持”的成因：BHO劫持。
在描述BHO劫持之前，我们先要对BHO接口的启动做个简单介绍：符合BHO接口标准的程序代码被写为DLL动态链接库形式在注册表里注册为COM对象，还要在BHO接口的注册表入口处进行组件注册，以后每次IE启动时都会通过这里描述的注册信息调用加载这个DLL文件，而这个DLL文件就因此成为IE的一个模块（BHO组件），与IE共享一个运行周期，直到IE被关闭。
IE启动时，会加载任何BHO组件，这些组件直接进入IE领域，而IE则成为它们的父进程和载体，从此IE的每一个事件都会通过IUnknown接口传递到BHO用以提供交互的IObjectWithSite接口里，这是BHO实现与IE交互的入口函数。
BHO接收到IE接口传递来的参数后开始判断IE正在做什么，理论上BHO可以获取IE的大部分事件，然后根据程序员编写的代码，BHO持有对特定事件做出反应的决定权，例如一个可以实现“中文网址”的BHO，就是通过GetSite方法获取到IE当前打开的站点URL（或通过IURLSearchHook接口来获知），如果BHO发现获取到的URL和内置的判断条件匹配，该BHO就会启用SetSite方法强制IE跳转到程序员设定的页面去，这个过程就是利用about:blank篡改主页的“浏览器劫持”方法之一，它的实现原理其实很简单，程序员编写一个恶意BHO组件，当它获取到IE窗口的当前站点为“about:blank”时就强制IE内部跳转到指定的广告页面，于是闹出了不久之前沸沸扬扬的“IE空白页劫持事件”。
了解了这种类似恶作剧的作案手段，要解决它就容易了，只要找到并删除这个隐藏在系统里的BHO程序即可。
除了这类“广告软件”性质的BHO，还有一种利用IURLSearchHook接口实现的另一类更隐蔽的BHO，这种BHO从某些方面来说大概不算BHO，因为它并不是响应IUnknown，而是等待IE创建IURLSearchHook来启动。IURLSearchHook被浏览器用来转换一个未知的URL协议地址，当浏览器企图去打开一个未知协议的URL地址时，浏览器首先尝试从这个地址得到当前的协议，如果不成功，浏览器将寻找系统里所有注册为“URL Search Hook”（资源搜索钩子，USH）的对象并把这个IE不能理解的地址发送过去，如果某个USH对象“认识”这个地址，它就返回一个特定的标识告诉IE它知道怎么打开这个地址，然后IE就根据约定的方法调用它，最终打开这个地址。其实USH对象并不陌生，我们一些偷懒的用户就经常为了省事而不输入“http://”，但是IE最终还是能认出并打开某个地址，就是USH的功劳，但是这一点又被恶意程序员拿来磨刀了，通过创建自己的USH对象，恶意程序员能够命令IE在找不到一些网站时自动跳转到事先设置的站点里，如果这个站点带毒或者挂马，用户就完了。
这类BHO的解决方法和前面一样，只是它比较隐蔽，除非用户经常偷懒，否则可能直到系统崩溃也不会知道自己已经感染了这种东西。也许你会说，只要用户的输入永远不会让IE无法识别，这种渗透不就白费了？但是事实不容乐观，我们无法得知BHO作者还会不会通过其他方法拦截IE，说不定每隔一段时间就让IE弹出一个广告呢？
上面说了这么多BHO和IE合作搞破坏的事例，可能会给读者造成一种“BHO必须在IE传递数据后才能行动”的误解，然而事实并非如此，浏览器自身也是一个标准的可执行程序，而BHO只是借用这个程序进程启动的DLL，它并非API那种要用的时候就让你过来忙活，忙活完了就一脚踹开的奴隶形态DLL，前面说过了，BHO是一种在浏览器加载时一同启动的例程，它相当于一种自身运行逻辑不太明确的子进程（里面都是对IE事件的响应和操作代码），这个特性就造成了BHO DLL和API DLL本质的区别，BHO并不需要所有事件都必须依赖这个大家伙，它可以有自己决定的权利，只要适当的修改，就能用BHO实现类似DLL木马的功能，当然，这并不是说我们就能在IE眼皮下公然的肆无忌弹干坏事的，由于BHO自身是作为IE子进程启动的，它就必须受到一些限制，例如程序员不能在里面自己创建网络连接，这样会导致IE报错崩溃并供出你写的DLL，害怕BHO成为另一种后门的用户可以松口气了，要在BHO里实现Winsock大概只能在IE休息的时候才可以，但是会有哪个用户开着个开空IE什么事情都不做呢？
文章整理：西部数码--专业提供域名注册、虚拟主机服务
http://www.west263.com
以上信息与文章正文是不可分割的一部分,如果您要转载本文章,请保留以上信息，谢谢!
