Silverlight 5的安全性：为局域网而设计

     <p> Silverlight 所扮演的角色一直为人所误解。人们最初认为 Silverlight 要和 Flash 竞争，但是 Flash 本身已经被 HTML 5 所取代。人们还认为它是一种交付跨平台应用程序的方式，但是 iOS 让这个希望也破灭了。让人奇怪的是，它在人们认为应该是 WPF 的领域——企业内部业务应用程序——中繁荣起来，而 Silverlight 5 中改进的安全性模型也反映了这一点。</p>    <p> Silverlight 2 是人们普遍认可的第一个真正意义上的版本，它出现后不久，人们就想要了解交付传统样式应用程序的方法。这项特性叫做“浏览器之外（out-of- brwoser）”或者 OOB，它最早是在 Silverlight 3 中提供的。但是早在发布之前，人们就开始要求访问 COM。但是正如我们所知，考虑到安全性问题，在浏览器中访问 COM 是非常可怕的想法。尽管微软缓解了这个问题，并在 Silverlight 4 中添加了这个特性，但是仅针对 OOB 应用程序。</p>    <p> 一旦 Silverlight 的开发者尝到了 COM 的甜头，他们就要求对底层操作系统由更多的访问权限。并且他们要求即便是在浏览器中运行，也要能够访问。所以我们现在有了带有p/invoke 功能的 Silverlight 5，它在浏览器之中拥有完全信任关系，这不仅仅是一种幻想，而且要成为一种公司的技术。有些人可能认为这是非常大胆的声明，但是了解一下更新的 <a href="/misc/goto?guid=4958327281395735260">Silverlight 安全性概览</a>中所传达的信息，就会发现并不尽然。</p>    <blockquote>     <p>在浏览器信任的应用程序中，和浏览器之外信任的应用程序一样，它们拥有其它权利，像访问文件系统和调用 COM 对象。在浏览器中，只有它们带有可信任发行商密钥的签名时，才能够带有信任关系运行，而这属于企业环境中组策略设置的一部分。它永远都不会提示用户赋权。</p>    </blockquote>    <p> 成为“可信任的发行商”并不像购买密码签名证书那样简单。想要被添加到那个列表中，用户需要手动导入证书，并使用为微软管理控制台所提供的 snap-in 功能来安装。在控制面板中并没有这个快捷方式；用户需要从命令行运行。</p>    <p> 在 Silverlight 4 中，应用程序至少需要拥有管理员的权限。但那个限制已经被去掉了。</p>    <blockquote>     <p>Silverlight 5 不会去除管理员权限。在 Silverlight 4 中，如果以管理员权限运行 Silverlight 应用程序，那么 Silverlight 就会载入另一个受限的进程并结束原来的进程，从而移除管理员权限。受限的权限与 Windows Vista 及以上版本中的用户账户控制（User Account Control，UAC）限制类似。Silverlight 5 摆脱了这种逻辑，并遵循了正常的操作系统规则，在 Silverlight 5 中，如果应用程序是作为管理员运行的，那么它就会带有管理员权限运行，如果没有作为管理员运行，那么就不会带有管理员权限运行。</p>    </blockquote>    <p> <strong>代码签名</strong></p>    <p> 如果你在部署面向互联网的 Silverlight 应用程序，那么你就可以忽略所有受信应用程序的内容，但是还需要考虑很多安全性方面的指标。首先，微软建议你<strong>对所有 Silverlight 签名</strong>。“如果你无法使用证书颁发机构发布的签名，那么至少应该自己对应用程序签名，以避免有人在更新应用程序时进行中间攻击。”</p>    <p> <strong>重新部署（Re-hosting）</strong></p>    <p> Silverlight 应用程序所要面对的主要风险因素就是重新部署。有人可以创建<a href="/misc/goto?guid=4958327282202472974">钓鱼</a>站点，在其中放置真正 Silverlight 应用程序的副本。然后服务调用会通过虚假站点跳转，这样用户名和密码就会泄漏。</p>    <p> 降低这种攻击风险的一种方式是，进行检查以查看应用程序是从哪个页面载入的。如果不是从正确的域中载入，那么你就应该在启动的时候退出。</p>    <p> <strong>跨站点脚本攻击和页面/应用程序信任</strong></p>    <p> 默认情况下，Silverlight 并不容易受到跨站点脚本攻击。然而，暴露脚本函数就会引入这个问题，特别是在那些函数调用 XamlReader.Load 或 AssemblyPart.Load 的时候。作为一种规则，所有带有 ScriptableMemberAttribute 标签的函数都可以从 JavaScript 调用，所以你应该仔细检查，看其中是否存在安全性漏洞。</p>    <p> 另一种可能是引入了调用页面上 JavaScript 脚本的恶意 Silverlight 应用程序。为了减少这种可能，标签中的 EnableHtmlAccess 属性应尽可能显式地设置为 false。（注： 当页面和应用程序来自于不同的域时，false 是默认值。）</p>    <p> <strong>直接服务调用（Direct Service Invocation）</strong></p>    <p> 一种经常被忽略的攻击点是应用程序使用的服务调用。WCF 没有一种可靠的方式用于检测 web 服务是否真正来自于 Silverlight 应用程序，所以你需要假设所有服务调用都可能是恶意的，并且要在服务器中再次执行在客户端已经完成的验证操作。</p>    <p> <strong>查看英文原文：</strong><a href="/misc/goto?guid=4958327282998680873">Silverlight 5 Security:Designed for the Intranet</a><br /> 来自: <a id="link_source2" href="/misc/goto?guid=4958327283799312879" target="_blank">InfoQ</a></p>