|
作为一名 Microsoft 服务顾问,我定期与客户和合作伙伴一起进行应用程序安全性讨论。 在本文中,我将介绍一些在这些讨论中提出的主题。 特别是,我将重点介绍编程人员在尝试保护 Silverlight 应用程序的安全时所面临的新挑战,而且我将考虑开发团队应该将其资源集中于哪些方面。
本文提到了许多技术概念,您可以在其他位置(包括本杂志)找到这些概念的更多详细信息。 因此,我就不在技术层面更加深入地讨论这些主题。 本文的目标是“理清头绪”并介绍如何利用这些概念保护您的应用程序的安全。
当规划应用程序的安全性时,考虑三个 A 非常有用:身份验证 (Authentication)、授权 (Authorization) 和审核 (Audit)。
身份验证是确认用户身份的行为。 我们通常使用用户名和密码执行此操作。
授权是指在进行身份验证之后,确认用户实际上具有执行特定操作或访问特定资源的适当权限的过程。
审核是维护活动记录,以便用户无法拒绝对系统执行的操作和请求的行为。
在 Silverlight 应用程序上下文中,我将重点介绍前两项(身份验证和授权)。 由于这是一个富 InterNET 应用程序 (RIA),因此本文中描述的大多数概念同样适用于异步 JavaScript 和 XML (AJAX) 或其他 RIA 方法。 我还将讨论如何防止对您的 Silverlight 应用程序文件进行不必要的访问。
拓扑
Silverlight 是一种跨浏览器插件,其利用 Windows Presentation Foundation (WPF) 率先采用的许多图形概念,使 Web 开发人员能够创建丰富的用户体验,这些用户体验将超出仅使用 HTML 和 JavaScript 创建的体验。
与 ASP.NET 不同的是,Silverlight 是一种客户端技术,它在用户的计算机上运行。 因此,Silverlight 开发无疑与 Windows 窗体或 WPF 有许多共同之处,而与 ASP.NET 的共同之处相对较少。 在许多方面,这是 Silverlight 的最大优势之一,因为它消除了 Web 应用程序的无状态性所导致的许多问题。 不过,由于所有 UI 代码都是在客户端计算机上运行的,因此您不能再相信它。
服务
与 Windows 窗体不同的是,Silverlight 在浏览器沙盒内运行且拥有的功能减少,因此它所提供的安全程度提高(尽管在 Silverlight 4 中,用户可以将某些应用程序标识为可信并将程序的权限提升为允许 COM 互操作)。 正因为如此,Silverlight 不能直接连接到数据库,您必须创建一个可提供对您的数据和业务逻辑的访问的服务层。
例如,您通常会将这些服务承载于您的 Web 服务器上,就像使用 ASP.NET Web 窗体一样。 假定 Silverlight 代码运行于服务器与现实世界之间的信任边界的可信度较差的一侧(参见图 1),您的团队的工作重点应始终是保护服务的安全。
图 1 Silverlight 运行于信任边界的可信度较差的一侧
在您的 Silverlight 代码内实现严格的安全检查几乎没有意义。 毕竟,攻击者可以很容易就完全摆脱 Silverlight 应用程序并直接调用您的服务,从而避开您实现的任何安全措施。 此外,恶意人员可以使用像 Silverlight Spy或 Debugging Tools for Windows 这样的实用程序更改您的应用程序在运行时的行为。
我们要认识到的重要一点是:服务无法确切地知道哪个应用程序正在调用它或者该应用程序在某些方面尚未被修改。 因此,您的服务必须确保:
- 调用方已经过适当的身份验证
- 调用方已获授权执行所请求的操作
鉴于上述原因,本文的大部分内容重点介绍如何采用与 Silverlight 兼容的方式保护服务的安全。 特别是,我将考虑通过 ASP.NET 在 Microsoft IIS 中承载两种不同类型的服务。 第一种类型是使用 Windows Communication Foundation (WCF)创建的服务,它为构建服务提供一种统一的编程模型。 第二种类型是 WCF 数据服务(以前称为“ADO.NET 数据服务”),其构建于 WCF 之上,允许您使用标准 HTTP 谓词(一种称为“具象状态传输”(REST)的方法)快速公开数据。
通常,如果担心安全性,则加密客户端和服务器之间的任何通信始终是明智之举。 建议使用 HTTPS/SSL 加密,且本文内假定使用此加密方法。
目前,Web 开发人员在 Microsoft 平台上最常用的两种身份验证方法是 Windows 身份验证和窗体身份验证。
Windows 身份验证
Windows 身份验证利用本地安全机构或 Active Directory验证用户凭据。 这在许多方案中都是一大优势;它意味着您可以使用系统管理员已经熟悉的工具集中管理用户。 Windows 身份验证可以使用 IIS 支持的任何方案,包括基本身份验证、摘要式身份验证、集成身份验证(NTLM/Kerberos)和证书。
在使用 Windows 身份验证时,通常都会选择集成方案,因为用户无需再次提供其用户名和密码。 用户在登录到 Windows 之后,浏览器可采用用于确认个人身份的令牌或握手形式转发凭据。 但是由于客户端和服务器需要了解用户的域,使用集成身份验证有许多缺点。 因此,集成身份验证最适用于 IntraNET 方案。 此外,尽管它自动与 Microsoft InterNET Explorer 一起使用,但其他浏览器(如 Mozilla Firefox)需要进行额外配置。
通常,基本身份验证和摘要式身份验证需要用户在启动与您的网站的会话时,重新输入其用户名和密码。 但是,由于这两种身份验证都属于 HTTP 规范,因此它们在大多数浏览器中均可正常使用,即使是从组织外部进行访问也是如此。
Silverlight 利用浏览器进行通信,因此使用刚才讨论的任何 IIS 身份验证方法,均可轻松实现 Windows 身份验证。 有关如何实现的详细说明,建议阅读分步指南“如何:在 Windows 窗体中,使用 WCF 中的 basicHttpBinding 进行 Windows 身份验证并使用 TransportCredentialOnly”(网址为:msdn.microsoft.com/library/cc949012)。 此示例实际上使用 Windows 窗体测试客户端,但相同的方法也适用于 Silverlight。
窗体身份验证
窗体身份验证是一种为 ASP.NET 中的自定义身份验证提供简单支持的机制。 因此,它特定于 HTTP,这意味着它也可在 Silverlight 中轻松使用。
用户输入用户名和密码组合,此信息将提交给服务器进行验证。 服务器根据可信的数据源(通常是用户数据库)检查凭据,如果凭据正确,则返回一个 FormsAuthentication Cookie。 然后,客户端在随后的请求中提供此 Cookie。 Cookie 经过签名和加密,因此只有服务器才能解密,恶意用户既无法解密,也无法篡改。
调用窗体身份验证的确切方式因登录屏幕的实现方式而异。 例如,如果在验证了用户的凭据后,使用重定向到您的 Silverlight 应用程序的 ASP.NET Web 窗体,您可能不再需要执行身份验证工作。 Cookie 已发送到浏览器,且每当请求该域时,您的 Silverlight 应用程序都将继续使用该 Cookie。
不过,如果您希望在 Silverlight 应用程序内实现登录屏幕,您将需要创建一个公开您的身份验证方法并发送相应 Cookie 的服务。 但幸运的是,ASP.NET 已经提供了您所需要的身份验证服务, 您只需在您的应用程序中启用它即可。 有关详细指南,建议阅读“如何:使用 ASP.NET 身份验证服务通过 Silverlight 应用程序登录”(网址为:msdn.microsoft.com/library/dd560704(VS.96))。
ASP.NET 身份验证的另一项强大的功能是其可扩展性。 成员资格提供程序描述了用于验证用户名和密码的机制。 幸运的是,ASP.NET 附带了许多成员资格提供程序,包括一个可使用 SQL Server 数据库的成员资格提供程序,还有一个使用 Active Directory的成员资格提供程序。 然而,如果没有符合您要求的提供程序,可直接创建一个自定义实现。
ASP.NET 授权
在您的用户通过身份验证后,请务必确保只有他们才能尝试调用服务。 在 ASP.NET 应用程序中,普通 WCF 服务和 WCF 数据服务均以.svc 文件表示。 本示例中,将在 IIS 中通过 ASP.NET 来承载服务,我将演示如何使用文件夹确保对服务的安全访问。
采用这种方式保护.svc 文件的安全有点令人迷惑不解,因为默认情况下,对此类文件的请求实际上会跳过大多数 ASP.NET 管道,从而绕过授权模块。 因此,为了能够利用许多 ASP.NET 功能,您必须启用 ASP.NET 兼容性模式。 在任何情况下,WCF 数据服务都会强制要求您启用它。 在您的配置文件内进行简单的切换即可完成任务:
<system.serviceModel> <serviceHostingEnvironment ASPNETCompatibilityEnabled="true"/></system.serviceModel><system.web> <authorization> <deny users="?"/> </authorization></system.web>
NET技术:保护您的 Silverlight 应用程序的安全,转载需保留来源!
郑重声明:本文版权归原作者所有,转载文章仅为传播更多信息之目的,如作者信息标记有误,请第一时间联系我们修改或删除,多谢。