《安全性体系结构和设计审查》由会员分享，可在线阅读，更多相关《安全性体系结构和设计审查（23页珍藏版）》请在金锄头文库上搜索。
1、安全性体系结构和设计审查更新日期： 2004 年 04 月 12 日本页内容本模块内容目标适用范围如何使用本模块体系结构和设计审查过程部署与基础结构注意事项输入验证身份验证授权配置管理敏感数据会话管理加密参数操作异常管理审核和日志记录小结其他资源本模块内容要生成安全的 Web 应用程序，必须要有正确的体系结构和设计。如果在开发完成后再重新改造安全设置，代价实在太高。在开发阶段开始前研究体系结构和设计审查，有助于验证应用程序中与安全相关的设计功能。这样，您可以在漏洞被人探测到之前明确并修复潜在的漏洞，同时避免了修复中必需的重新工程处理。本模块提供了全面评价体系结构设计前必须考虑的问题。即便您已创
2、建了应用程序，仍要阅读本模块，然后重新审视在应用程序设计过程中使用的概念、原则和技术。返回页首目标使用本模块可以实现： 了解全面评价体系结构设计要考虑的问题。 分析 Web 应用程序的体系结构和设计。 开发并完善当前的安全评价措施。 建立在设计阶段修复漏洞的过程。 明确应用程序的关键部署和基础结构安全事项。 确保 Web 应用程序部署的平稳和安全。返回页首适用范围Web 应用程序返回页首如何使用本模块为了充分理解本模块内容，请： 在体系结构设计过程中增加安全评价。尽早在更改设计时使用本模块提供的步骤来评价更改。 开发安全评价措施。本模块提供了在完善设计安全时要考虑的问题。要完成评价过程，可能还
3、要增加一些特定于应用程序的问题。 理解潜在的威胁。模块 2 威胁和对策列出了影响应用程序各构成组件和层的威胁。只有了解这些威胁，才能完善评价过程的结果。返回页首体系结构和设计审查过程体系结构和设计审查过程要从安全角度分析。如果刚完成设计，可使用设计文档来帮助执行该过程。无论设计文档如何详尽，您都必须能分解应用程序并识别关键内容，包括信任边界、数据流、入口点和特权代码。此外，还必须了解应用程序的物理部署配置。请注意常出现漏洞的区域的设计方法。本指南将这些划分为应用程序漏洞类别。请在评价应用程序的体系结构和设计时考虑下列问题： 部署与基础结构。针对目标部署环境和相关安全策略来评价应用程序的设计。此
4、外，考虑底层基础结构层安全所要求的限制。 应用程序体系结构和设计。对应用程序关键区域采用的方法进行评价，这些区域包括身份验证、授权、输入验证、异常管理等。可将应用程序漏洞类别作为一种路线图，确保不在评价过程中遗漏任何关键区域。 逐层分析。对应用程序的各逻辑层进行分析，检验 ASP.NET Web 页和控件、Web 服务、服务组件、Microsoft .NET 远程处理、数据访问代码等的安全性。 图 5.1 显示了这种三路并进的评价方法。图 5.1应用程序评价 本模块的剩余部分提供了评价各不同区域时考虑的关键事项。返回页首部署与基础结构注意事项检验底层网络和主机基础结构提供给应用程序的安全设置，
5、然后检验目标环境要求的所有限制。此外，考虑部署的拓扑结构以及中间层应用程序服务器、外围区域以及内部防火墙对设计的影响。检验下列问题，确定可能存在的部署和基础结构问题： 网络是否提供了安全的通信？ 部署拓扑结构是否包括内部防火墙？ 部署拓扑结构中是否包括远程应用程序服务器？ 基础结构安全性要求的限制是什么？ 是否考虑了 Web 场问题？ 目标环境支持怎样的信任级别？网络是否提供了安全的通信？数据在客户端与服务器（或服务器与服务器）之间传输时最易受到攻击。数据应有怎样的私有程度？是否对客户数据负法律责任？应用程序负责在传输数据前处理并转换数据，网络负责数据传输的完整性和私密性。如果必须保留数据隐私
6、，可使用适当的加密算法。此外，还必须确保网络设备安全。因为这是维护网络完整性所必需的。部署拓扑结构是否包括内部防火墙？如果内部防火墙将 Web 服务器与应用程序服务器（或数据库服务器）分隔开来，请考虑下列问题，确保您的设计能适应这种配置： 下游服务器如何验证 Web 服务器的身份？如果使用域帐户和 Windows 身份验证，防火墙是否打开了必要的端口？如果不打开（或如果 Web 服务器和下游服务器位于不同的域），可使用镜像的本地帐户。例如，可复制特权最少的本地 ASPNET 帐户，用于在数据库服务器中运行 Web 应用程序。 是否使用分布式事务？如果 Web 服务器使用 Microsoft D
7、istributed Transaction Coordinator (DTC) 的服务来启动分布式事务，内部防火墙是否为 DTC 通信打开了必要的端口？有关通过防火墙使用 DTC 的详细信息，请参阅 Microsoft 知识库文章 250367“INFO:Configuring Microsoft Distributed Transaction Coordinator (DTC) to Work Through a Firewall”，网址是 http:/ 部署拓扑结构是否包括远程应用程序服务器？如果部署拓扑结构包括了一个物理远程中间层，请考虑下列问题： 是否使用企业服务？如果是，是否已限制
8、 DCOM 端口范围？内部防火墙是否打开了这些端口？注意：有时，使用中间层 Web 服务作为企业服务应用程序的前端是一种绝佳设计。使用该方法，Web 服务器可通过 80 端口使用简单对象访问协议 (SOAP) 与应用程序服务器进行通信。有关详细信息，请参阅下列 Microsoft 知识库文章： 文章 312960“PRB:Cannot Set Fixed Endpoint for a COM+ Application”，位于：http:/ 文章 259011“SAMPLE:A Simple DCOM Client Server Test Application”，位于：http:/ 文章 24
9、8809“PRB:DCOM Does Not Work over Network Address Translation-Based Firewall”，位于：http:/ 文章 154596“HOWTO:Configure RPC Dynamic Port Allocation to Work with Firewall”，位于：http:/ 是否使用 .NET 远程处理？远程处理用在受信服务器方案中。网络是否支持 IPSec 策略（确保只能从 Web 服务器访问中间层远程处理组件）？ASP.NET 承载远程组件是否支持身份验证和授权？ 是否使用 Web 服务？如果是，中间层 Web 服务如
10、何验证 Web 应用程序的身份？Web 应用程序是否通过在 Web 服务代理中配置凭据来使 Web 服务验证 Web 服务器的身份？如果否，Web 服务如何明确调用者？基础结构安全性要求的限制是什么？您的设计是否假定主机基础结构安全限制要失效？例如，安全限制可能要求根据所需的服务、协议或帐户特权来对设计进行权衡。请考虑下列问题： 是否依赖可能不可用的服务或协议？开发和测试环境中可用的服务和协议可能在生产环境中不可用。请与基础结构安全负责组沟通，了解相关限制和要求。 是否依赖敏感的帐户特权？您的设计应尽量使用特权最少的进程、服务和用户帐户。要执行的操作是否要求可能不被许可的敏感特权？例如，应用程
11、序是否要创建线程级模拟令牌来创建资源访问的服务身份？这项操作要求“作为操作系统的一部分” 特权，而该特权不应授予 Web 服务器进程（因为可能增加进程被利用的风险）。如果需要此功能，设计应对更高级别的特权进行划分，例如，在进程外的企业服务应用程序中。是否考虑过 Web 场问题？如果应用程序部署在 Web 场中，无需对场中处理客户端请求的服务器作出假定。从同一客户端发出的连续请求可由不同的服务器进行处理。因此，您无需考虑下列问题： 如何管理会话状态？在 Web 场中，您无法管理 Web 服务器的会话状态。实际上，您必须在设计中包含一个位于服务器的远程状态存储，然后通过该存储提供场中所有 Web
12、服务器的访问。有关详细信息，请参阅本模块后面的“会话管理” 。 是否使用特定于计算机的加密密钥？如果打算使用加密来对共享数据源（如数据库）的数据进行加密，则场中所有计算机的加密和解密密钥都必须相同。请检查设计，确保设计中的加密机制不要求计算机关系。 是否使用表单身份验证或受保护的视图状态？如果是，设计必须基于 设置。在 Web 场中，必须对所有服务器使用相同的密钥。 是否使用安全套接字层 (SSL)？如果使用 SSL 加密浏览器和 Web 服务器之间的通信流，应在何处终止 SSL 连接？可能的选择有 Web 服务器、带加速卡的 Web 服务器和带加速卡的负载平衡器。通常，选择在带加速卡的负载平
13、衡器处终止 SSL 性能最好，特别是有大量连接的站点。如果在负载平衡器处终止 SSL，则从负载平衡器到 Web 服务器的网络通信量是不加密的。这意味着，攻击者可趁数据在负载平衡器和 Web 服务器之间传输时通过解密来捕获网络通信数据。可通过确保 Web 服务器环境的物理安全，或使用 IPSec 策略所提供的传输级加密来保护内部数据中心链接，从而应对这种威胁。目标环境支持何种信任级别？目标环境的代码访问安全信任级别决定了代码可访问的资源，以及它能执行的特权操作。请检查目标环境支持的信任级别。如果允许 Web 应用程序以完全信任级别运行，代码将能访问操作系统安全性许可的任何资源。如果 Web 应用
14、程序必须以受限信任级别运行，则代码能访问的资源类型以及能执行的特权操作都将受到一定的限制。在部分信任案例中，设计应对特权代码进行沙盒 (sandboxing) 处理。此外，还应使用不同的程序集来分隔特权代码。这样，您可以对特权代码和应用程序的其余部分单独配置特权代码，然后授予必要的附加代码访问权限。有关详细信息，请参阅模块 9 ASP.NET 代码访问安全性。 注意：如果打算将应用程序部署在共享服务器（或应用程序将由宿主公司运行），信任级别通常是个问题。此时，请检查安全策略，然后确定 Web 应用程序的信任级别。返回页首输入验证请对应用程序验证输入内容的方式进行检验，因为很多 Web 应用程序
15、攻击都故意使用格式错误的输入。SQL 注入、跨站点脚本 (XSS)、缓冲区溢出、代码注入以及无数其他拒绝服务和特权提升攻击都可利用输入验证中的漏洞。表 5.1 重点列出了常见的输入验证漏洞。表 5.1.常见输入验证漏洞漏洞 影响超文本标记语言 (HTML) 输出流中有未经验证的输入应用程序易受 XSS 攻击。用于生成 SQL 查询的输入未经验证 应用程序易受 SQL 注入攻击。依赖客户端的验证 客户端验证很容易被忽略。使用输入文件名、URL 或用户名制定安全决策应用程序易出现规范化错误并导致安全漏洞。对恶意输入仅采用应用程序筛选器 这基本上不可能达到目的，原因是可能的恶意攻击范围太大。应用程序应对输入进行约束、拒绝和净化。请考虑下列问题，帮助发现潜在的输入验证安全问题： 如何验证输入？ 如何处理输入？ 如何验证输入？您的设计指定的输入验证方法是什么？首先，您的设计必须展示策略。应用程序应对收到的所有输入进行约束、拒
