有没有办法通过脚本禁用 MSFT IE XML 数据绑定功能？
问题：是否可以构建一个网页，其中包含一个脚本来关闭 MSIE 中的 XML 数据绑定？ 理想的方法是编写一个 HTML 页面，并指示办公室中的所有人员使用显示“关闭数据绑定”的按钮来访问该页面。
理由：桌面系统管理员目前不可用，目标是创建一种简单的方法让人们关闭此功能，而无需引导他们完成一堆 MSIE 配置菜单。
Question: Is it possible to construct a web page that has a script to turn off XML data-binding in MSIE? The ideal approach would be to code an HTML page and instruct all people in the office to visit the page with a button that says "turn off data-binding".
Rationale: The desktop sysadmin is not available at this time and the goal is to create a brain-dead simple way to let people turn this feature off without having to walk them through a bunch of MSIE configuration menus.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
我假设您正在谈论Microsoft 安全通报 (961051)。
如果您可以使用客户端脚本禁用 XML 数据绑定，那么有人可以使用客户端脚本启用它并再次暴露该漏洞。 所以这是不可能的。
但是，如果每个人都运行相同版本的 Windows 和相同的位数风格，那么只需将他们发送到一个页面，他们可以在其中将其复制并粘贴到“开始”>“ 运行：
Regsvr32.exe /u“Program Files\Common Files\System\Ole DB\oledb32.dll”
请注意，这将防止当前的攻击，但为了全面防范该漏洞，他们建议应用另一种解决方法。 更多信息 此处。
鼓励您的员工通过电子邮件访问网站并运行他们被告知要运行的内容可能是一个坏主意，因为这会让他们面临各种网络钓鱼攻击，因为大多数人无法区分来自自己公司 IT 部门的电子邮件和恶意人员发送的电子邮件。
有关可用解决方法的更多信息，请参阅此处。
最后，最佳实践是推出上述知识库文章中所述的解决方法之一。
I'm assuming you're talking about Microsoft Security Advisory (961051).
If you could disable XML data-binding using client-side script, then someone could enable it with client-side script and expose the vulnerability again. So that isn't possible.
However, if everyone is running the same version of Windows and the same bitness flavor, then just send them to a page where they can copy and paste this into Start > Run:
Regsvr32.exe /u "Program Files\Common Files\System\Ole DB\oledb32.dll"Note that this will protect against current attacks but to comprehensively protect against the vulnerability they recommend applying another workaround. More on that here.
And encouraging your employees to go to a website in an E-mail and run something they've been told to run is probably a bad idea as it opens them up to various phishing attacks since most people won't be able to distinguish between an E-mail from their own company IT department and an E-mail sent by a malicious person.
More about the available workarounds here.
In the end, the best practice would be to push out one of the workarounds as described in the above KB article.