安全性体系结构和设计审查

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 Distributed Transaction

7、 Coordinator (DTC) 的服务来启动分布式事务，内部防火墙是否为 DTC 通信打开了必要的端口？有关通过防火墙使用 DTC 的详细信息，请参阅 Microsoft 知识库文章 “INFO:Configuring Microsoft Distributed Transaction Coordinator (DTC) to Work Through a Firewall”，网址是 /default.aspx?scid=kb;en-us;Q（英文）。 部署拓扑结构是否包括远程应用程序服务器？如果部署拓扑结构包括了一个物理远程中间层，

8、请考虑下列问题：是否使用企业服务？如果是，是否已限制 DCOM 端口范围？内部防火墙是否打开了这些端口？注意：有时，使用中间层 Web 服务作为企业服务应用程序的前端是一种绝佳设计。使用该方法，Web 服务器可通过 80 端口使用简单对象访问协议 (SOAP) 与应用程序服务器进行通信。有关详细信息，请参阅下列 Microsoft 知识库文章：文章 “PRB:Cannot Set Fixed Endpoint for a COM+ Application”，位于：/default.aspx?scid=kb;en-us;Q（英文）。 文章 “

9、SAMPLE:A Simple DCOM Client Server Test Application”，位于：/default.aspx?scid=kb;en-us;Q（英文）。 文章 “PRB:DCOM Does Not Work over Network Address Translation-Based Firewall”，位于：/default.aspx?scid=kb;en-us;Q（英文）。 文章 “HOWTO:Configure RPC Dynamic Port Allo

10、cation to Work with Firewall”，位于：/default.aspx?scid=kb;en-us;Q（英文）。 是否使用 .NET 远程处理？远程处理用在受信服务器方案中。网络是否支持 IPSec 策略（确保只能从 Web 服务器访问中间层远程处理组件）？ASP.NET 承载远程组件是否支持身份验证和授权？是否使用 Web 服务？如果是，中间层 Web 服务如何验证 Web 应用程序的身份？Web 应用程序是否通过在 Web 服务代理中配置凭据来使 Web 服务验证 Web 服务器的身份？如果否，Web 服务如何明确

11、调用者？基础结构安全性要求的限制是什么？您的设计是否假定主机基础结构安全限制要失效？例如，安全限制可能要求根据所需的服务、协议或帐户特权来对设计进行权衡。请考虑下列问题：是否依赖可能不可用的服务或协议？开发和测试环境中可用的服务和协议可能在生产环境中不可用。请与基础结构安全负责组沟通，了解相关限制和要求。是否依赖敏感的帐户特权？您的设计应尽量使用特权最少的进程、服务和用户帐户。要执行的操作是否要求可能不被许可的敏感特权？例如，应用程序是否要创建线程级模拟令牌来创建资源访问的服务身份？这项操作要求“作为操作系统的一部分”特权，而该特权不应授予 Web 服务器进程（因为可能增加进程被利用的风险）。

12、如果需要此功能，设计应对更高级别的特权进行划分，例如，在进程外的企业服务应用程序中。是否考虑过 Web 场问题？如果应用程序部署在 Web 场中，无需对场中处理客户端请求的服务器作出假定。从同一客户端发出的连续请求可由不同的服务器进行处理。因此，您无需考虑下列问题：如何管理会话状态？在 Web 场中，您无法管理 Web 服务器的会话状态。实际上，您必须在设计中包含一个位于服务器的远程状态存储，然后通过该存储提供场中所有 Web 服务器的访问。有关详细信息，请参阅本模块后面的“会话管理”。是否使用特定于计算机的加密密钥？如果打算使用加密来对共享数据源（如数据库）的数据进行加密，则场中所有计算机的

13、加密和解密密钥都必须相同。请检查设计，确保设计中的加密机制不要求计算机关系。是否使用表单身份验证或受保护的视图状态？如果是，设计必须基于 设置。在 Web 场中，必须对所有服务器使用相同的密钥。是否使用安全套接字层 (SSL)？如果使用 SSL 加密浏览器和 Web 服务器之间的通信流，应在何处终止 SSL 连接？可能的选择有 Web 服务器、带加速卡的 Web 服务器和带加速卡的负载平衡器。通常，选择在带加速卡的负载平衡器处终止 SSL 性能最好，特别是有大量连接的站点。如果在负载平衡器处终止 SSL，则从负载平衡器到 Web 服务器的网络通信量是不加密的。这意味着，攻击者可趁数据在负载平衡

14、器和 Web 服务器之间传输时通过解密来捕获网络通信数据。可通过确保 Web 服务器环境的物理安全，或使用 IPSec 策略所提供的传输级加密来保护内部数据中心链接，从而应对这种威胁。目标环境支持何种信任级别？目标环境的代码访问安全信任级别决定了代码可访问的资源，以及它能执行的特权操作。请检查目标环境支持的信任级别。如果允许 Web 应用程序以完全信任级别运行，代码将能访问操作系统安全性许可的任何资源。如果 Web 应用程序必须以受限信任级别运行，则代码能访问的资源类型以及能执行的特权操作都将受到一定的限制。在部分信任案例中，设计应对特权代码进行沙盒 (sandboxing) 处理。此外，还应

15、使用不同的程序集来分隔特权代码。这样，您可以对特权代码和应用程序的其余部分单独配置特权代码，然后授予必要的附加代码访问权限。有关详细信息，请参阅模块 9 ASP.NET 代码访问安全性。 注意：如果打算将应用程序部署在共享服务器（或应用程序将由宿主公司运行），信任级别通常是个问题。此时，请检查安全策略，然后确定 Web 应用程序的信任级别。返回页首输入验证请对应用程序验证输入内容的方式进行检验，因为很多 Web 应用程序攻击都故意使用格式错误的输入。SQL 注入、跨站点脚本 (XSS)、缓冲区溢出、代码注入以及无数其他拒绝服务和特权提升攻击都可利用输入验证中的漏洞。表 5.1 重点列出了常见的

16、输入验证漏洞。表 5.1.常见输入验证漏洞漏洞影响超文本标记语言 (HTML) 输出流中有未经验证的输入应用程序易受 XSS 攻击。用于生成 SQL 查询的输入未经验证应用程序易受 SQL 注入攻击。依赖客户端的验证客户端验证很容易被忽略。使用输入文件名、URL 或用户名制定安全决策应用程序易出现规范化错误并导致安全漏洞。对恶意输入仅采用应用程序筛选器这基本上不可能达到目的，原因是可能的恶意攻击范围太大。应用程序应对输入进行约束、拒绝和净化。请考虑下列问题，帮助发现潜在的输入验证安全问题：如何验证输入？如何处理输入？ 如何验证输入？您的设计指定的输入验证方法是什么？首先，您的设计必须展示策略。

17、应用程序应对收到的所有输入进行约束、拒绝和净化。约束输入是最佳的方法，因为针对已知有效类型、模式和范围对数据进行验证要比通过查找已知坏字符来验证数据简单得多。如果使用深层防御策略，还要拒绝已知的坏输入并对输入进行净化。请考虑下列问题，帮助识别潜在的漏洞：是否清楚入口点？确保设计标出了应用程序的入口点，以便跟踪各个输入字段的操作。可考虑 Web 页输入、输入到组件和 Web 服务，以及从数据库输入。是否清楚信任边界？如果输入是从信任边界内的受信源传递的，并非总要验证输入；但如果输入是从不受信任的源传递的，必须强制要求验证输入。 是否验证 Web 页输入？请不要将最终用户看作受信任的数据源。确保对

18、正常和隐藏的表单字段、查询字符串和 cookie 都进行验证。是否对传递到组件或 Web 服务的参数进行验证？如果不进行验证，唯一的安全条件就是数据接收自当前信任边界之内。但是，如果使用深层防御策略，建议您使用多层验证。是否验证从数据库中检索的数据？这种形式的输入也应验证，特别是当其他应用程序也写入该数据库时。请不要对其他应用程序的数据验证程度进行假设。是否将方法集中起来？对于相同类型的输入字段类型，请检验使用的是否是相同的验证和筛选库，确保一致地执行验证规则。是否依赖客户端的验证？请不要这样做。客户端验证可用于降低到服务器的回程数量，但不能依靠它来维护安全性，因为它很容易被忽略。请在服务器验

19、证所有的输入。如何处理输入？请检查应用程序处理输入的方式，不同类型的处理可能导致不同类型的漏洞。例如，如果在 SQL 查询中使用输入，应用程序可能易受 SQL 注入攻击。请考虑下列问题，帮助发现潜在的漏洞：应用程序是否易受规范化问题的影响？检查应用程序是否使用基于输入的名称来制定安全决策。例如，应用程序是否接受用户名、文件名或 URL？由于名称的表示方法多种多样，以上各项都极易造成规范化错误问题。如果应用程序接受输入作为名称，请确保对它们进行验证并在处理之前将它们转换为规范的表示法。应用程序是否易受 SQL 注入攻击？请密切注意形成 SQL 数据库查询的所有输入字段。确保对这些字段的类型、格式

20、、长度和范围进行正确的验证。此外，请检查查询的生成方式。如果使用参数化的存储过程，输入参数将被当作文本，而不会当作可执行代码。这是降低风险的一种有效措施。应用程序是否易受 XSS 攻击？如果在 HTML 输出流中包括输入字段，可能受到 XSS 攻击。请确保对输入进行验证，并对输出进行编码。密切注意系统对接受一定范围 HTML 字符的输入字段的处理方法。返回页首身份验证检查应用程序验证调用者身份的方法、在何处使用身份验证，如何确保凭据在存储中或通过网络传递的安全。身份验证中的漏洞可能导致应用程序易受哄骗攻击、词典攻击、会话劫持等。表 5.2 重点列出了常见的身份验证漏洞。表 5.2：常见身份验证

21、漏洞漏洞影响弱密码增加了破解密码和词典攻击的风险。配置文件中使用明文凭据可访问服务器的内部人员（或利用主机漏洞下载配置文件的攻击者）都能直接访问该凭据。通过网络传递明文凭据攻击者可监控网络来盗取身份验证凭据并窃取身份。帐户的特权过强与进程和帐户泄露相关的风险增加。长会话与会话劫持相关的风险增加。 混用个性化数据的身份验证数据个性化数据适于永久的 cookie。而身份验证 cookie 不应是永久的。请考虑下列问题，确定在应用程序进行身份验证的方法中的潜在漏洞：是否区分公共访问和受限访问？是否明确服务帐户要求？如何验证调用者身份？如何验证数据库的身份？是否强制使用强帐户管理措施？是否区分公共访问

22、和受限访问？如果应用程序既有不要求身份验证的公共区域，也有要求身份验证的受限区域，请检查站点设计区分二者的方法。您必须为受限的页和资源使用单独的子文件夹，然后在 IIS 中将它们配置为要求 SSL 来确保安全。这种方法允许您只在需要的地方使用 SSL 来确保敏感数据和身法验证 cookie 的安全性，从而避免了因在整个站点中使用 SSL 而造成的附加性能负担。是否明确服务帐户要求？您的设计应明确连接不同资源（包括数据库、目录服务和其他类型的网络资源）的服务帐户范围。请确保在设计中不使用单个的、有高度特权的帐户（有足够的权限连接多种不同类型的资源）。设计是否要求特权最少的帐户？您是否已明确各种资

23、源和操作所需的特权？请检查设计并准确标识各帐户执行特定功能所需的特权，然后在任何情况下都使用特权最少的帐户。应用程序是否要维护服务帐户凭据？如果是，确保加密这些凭据，然后保存在受限的位置中。例如，保存在有受限访问控制列表 (ACL) 的注册表项。如何验证调用者身份？请考虑与调用者身份验证相关的下列事项。具体事项由设计中使用的身份验证类型决定。是否在网络中传递明文凭据？如果使用表单或基本身份验证（或使用 Web 服务并在 SOAP 头中传递凭据），请确保使用 SSL 来保护传输中的凭据。是否实现自己的用户存储？如果是，请检查用户凭据的存储位置和存储方式。一种常见错误是将明文或加密密码保存在用户存

24、储中。实际中，您必须保存密码的哈希值来进行身份验证。如果根据 SQL Server 用户存储验证凭据，请密切注意用户名和密码的输入。检查是否存在恶意注入的 SQL 字符。是否使用表单身份验证？如果是，除使用 SSL 保护凭据外，还应使用 SSL 来保护身份验证 cookie。此外，还要检查设计是否使用受限的会话生存期来抵御 cookie 重播攻击，并确保加密 cookie。有关表单身份验证的详细信息，请参阅模块 10 构建安全的 ASP.NET 网页和控件和模块 19 确保 ASP.NET 应用程序和 Web Services 的安全。 如何验证数据库的身份？如果应用程序要连接数据库，请检查使

25、用的身份验证机制、打算使用的帐户（一个或多个），以及如何在数据库中授权应用程序。明确下列问题有助于对数据库身份验证进行评价：是否使用 SQL 身份验证？在理想情况下，设计使用 Windows 身份验证来连接 SQL Server，因为这种方法本身更加安全。如果使用 SQL 身份验证，请检查在网络中和数据库连接字符串中确保凭据安全的方法。如果网络基础结构不提供 IPSec 加密通道，确保在数据库中安装服务器证书来提供自动 SQL 凭据加密。此外，还要检验确保数据库连接字符串安全的方法，因为这些字符串中包含 SQL 帐户的用户名和密码。是否使用进程帐户？如果使用应用程序的进程帐户并使用 Windo

26、ws 身份验证连接 SQL 服务器，请确保在设计中使用特权最少的帐户。本地 ASPNET 帐户便是为此提供的，尽管对于本地帐户来说，您需要在数据库服务器上创建一个相同的帐户。如果打算使用域帐户，请确保它是特权最少的帐户，然后打开相关的端口来确保所有相关防火墙都支持 Windows 身份验证。是否使用服务帐户？如果您的设计要求使用多个身份来支持数据库中的高粒度授权，请检查保存帐户凭据（在理想情况下，这些凭据使用数据保护 API (DPAPI) 加密并保存在安全注册表项中）的方法，以及使用服务身份的方法。此外，还要检查使用哪些进程通过该服务帐户创建模拟的安全上下文。该操作不应由 Microsoft

27、 Windows 2000 中的 ASP.NET 应用程序进程来完成，因为它将强制提升进程帐户的特权，并授予“作为操作系统的一部分”特权。这种情况必须尽量避免，它将大大增加风险。是否考虑使用匿名 Internet 用户身份？对于使用表单或 Passport 身份验证的应用程序而言，可为各个程序配置单独的匿名用户帐户。然后，启用模拟并使用匿名身份来访问数据库。该方法适于对同一服务器的不同应用程序进行单独的授权和身份跟踪。是否使用原始用户身份？如果您的设计要求模拟原始调用者，必须考虑该方法是否能提供足够的伸缩性，因为连接池是无效的。另一种备选方法是，通过受信的查询参数在应用程序级流动原始调用者身份

28、。如何保存数据库连接字符串？如果数据库连接字符串硬编码，或以明文形式保存在配置文件或 COM+ 目录中，则很容易受到攻击。实际中，您应加密它们，然后限制对加密数据的访问。有关连接 SQL Server 及安全保存数据库连接字符串的详细信息，请参阅模块 14 构建安全的数据访问。 是否强制使用强帐户管理措施？如果应用程序使用 Windows 身份验证，Windows 安全策略将强制使用强密码、受限登录和其他最佳帐户管理策略。其他情况，则由应用程序层负责这些措施。请考虑与应用程序帐户管理相关的下列问题：应用程序是否强制使用强密码？例如，ASP.NET Web 页是否使用正则表达式来验证密码复杂性规

29、则？是否限制失败登录的次数？这样做有助于对抗词典攻击。是否在故障发生后公开过多信息？确保不显示类似“不正确的密码”这样的消息，因为它将告诉恶意用户：用户名是正确的。结果，恶意用户便可集中精力破解密码。是否强制定期更改密码？建议这样做，如果不强制定期更改，用户极有可能不更改自己的密码，结果风险更高。是否能在泄露发生时迅速禁用帐户？如果帐户泄露，是否能方便地禁用帐户来防止攻击者继续使用帐户？应用程序是否记录登录企图？记录失败的登录企图是检测攻击者试图侵入的有效方法。返回页首授权请检查应用程序是如何向用户授权的。还要检验应用程序在数据库中是如何被授权的，以及如何控制系统级资源的访问。授权中的漏洞可能

30、导致信息泄漏、数据篡改及特权提升。使用深层防御策略是一种重要的方法，它可应用于应用程序的授权策略中。表 5.3 重点列出了常见的授权漏洞。表 5.3：常见授权漏洞漏洞影响依赖单个网关守卫如果网关守卫被忽略或配置不正确，用户能不经授权进行访问。不能根据应用程序身份锁定系统资源攻击者可强制应用程序访问受限的系统资源。不能将数据库访问限定于特定存储过程攻击者可利用 SQL 注入攻击来检索、操作或毁坏数据。特权隔离不充分没有责任或能力对每个用户进行授权。请考虑下列问题，帮助验证应用程序设计的授权策略：如何向最终用户授权？如何在数据库中授权应用程序？如何将访问限定于系统级资源？如何向最终用户授权？您应在

31、设计时从两种角度考虑授权。首先，考虑最终用户授权。哪些用户可访问哪些资源并执行哪些操作？其次，如何防止恶意用户使用应用程序访问系统级资源？请考虑下列问题，验证应用程序的授权策略：是否使用深层防御策略？确保设计不依赖单个网关守卫来加强访问控制。考虑该网关守卫失败（或攻击者设法忽略它）时发生的情况。使用了哪些网关守卫？可能的选择有 IIS Web 权限、NTFS 权限、ASP.NET 文件授权（仅适用于 Windows 身份验证）、URL 授权和用户权限请求。如果不使用某个特定类型，请明确不使用的理由。是否使用基于角色的方法？如果是，如何维护角色列表？维护角色列表所需的管理界面安全性如何？角色是否

32、提供足够的特权隔离？您的设计是否提供了适当的粒度，使不同用户角色的关联特权得到充分的隔离？避免出现仅为满足特定用户需要而授予角色较高特权的情况。考虑增加新的角色。如何在数据库中授权应用程序？在应用程序中连接数据库的帐户必须有受限的能力，只需满足应用程序的要求即可，不要再高了。应用程序是否使用存储过程来访问数据库？建议应用程序使用存储过程来访问数据库，因为您只能授予应用程序登录访问特定存储过程的权限。可以限制登录不在数据库中直接执行创建/读取/更新/删除 (CRUD) 操作。这样做对安全性和性能有利，且有助于提高日后的可维护性。有关数据库授权方法的详细信息，请参阅模块 14 构建安全的数据访问。

33、如何限制对系统级资源的访问？设计应用程序时，请考虑应用程序在可访问系统级资源方面的限制。只能授予应用程序访问最低限度的资源。这是缓解风险的一种策略，可在应用程序遭受攻击时限制受损程度。请考虑下列问题：设计是否使用代码访问安全性？代码访问安全性提供了一种资源约束模型，该模型可防止代码（和 Web 应用程序）访问特定类型的系统级资源。如果使用代码访问安全性，设计必将受到影响。请明确是否在设计规划中包括代码访问安全性，然后通过对特权代码进行隔离和沙盒处理 (sandboxing)，并将资源访问代码置于自己独立的程序集中，从而进行相应的设计。应用程序使用哪些身份？您的设计必须明确应用程序使用的所有身份

34、，包括进程身份和所有模拟身份（包括匿名 Internet 用户帐户和服务身份）。此外，设计还要指出这些身份要访问的资源。在部署时，可对系统级资源配置正确的 ACL，确保应用程序的身份只能访问所需的资源。有关设计代码访问安全性的详细信息，请参阅模块 9 ASP.NET 代码访问安全性。返回页首配置管理如果应用程序提供了可配置的管理界面，请检查确保管理界面安全的方法。此外，还要检查如何确保敏感配置数据的安全。表 5.4 显示了常见的配置管理漏洞。表 5.4：常见配置管理漏洞漏洞影响不安全的管理界面未经授权的用户可重新配置应用程序，并访问敏感数据。不安全的配置存储未经授权的用户可访问配置存储并获取机

35、密信息（如帐户名、密码和数据库连接详细信息）。明文配置数据可登录服务器的所有用户都能查看敏感的配置数据。管理员太多这使管理员的审核和评价工作变得很困难。进程帐户和服务帐户的特权过高这可导致特权提升攻击。请考虑下列问题，帮助验证应用程序设计在配置管理方面的方法：是否支持远程管理？是否确保配置存储的安全？是否隔离管理员特权？是否支持远程管理如果您的设计指定了远程管理，必须确保管理界面和配置存储的安全，因为这些操作本身非常敏感，而且通过管理界面访问的数据也很敏感。请考虑与远程管理设计相关的下列问题：是否使用强身份验证？必须要求对所有管理界面用户进行身份验证。使用强身份验证，如 Windows 或客户

36、端证书身份验证。是否加密网络通信数据？使用经过加密的信道，如 IPSec 或虚拟专用网络 (VPN) 连接提供的通道。不支持不安全通道中的远程管理。IPSec 允许您对可用来管理服务器的客户计算机的身份和数量进行限制。是否保证配置存储的安全？请明确应用程序的配置存储，然后检查限制访问这些存储的方法，以及确保存储中数据安全的方法。配置存储是否在 Web 空间中？对于保存在 Web 空间的文件中的配置数据，其安全性要低于保存在 Web 空间之外的数据。主机配置错误或未发现的 Bug 都可能导致攻击者通过 HTTP 检索并下载配置文件。配置存储中的数据是否安全？请确保在存储中加密关键的配置数据项（如

37、数据库连接字符串、加密密钥和服务帐户凭据）。如何限制对配置存储的访问？请确保管理界面提供必要的授权，确保只有经过验证的管理员可访问并操作这些数据。是否隔离管理员特权？如果管理界面支持不同的功能（如站点内容更新、服务帐户重新配置和数据库连接详细信息），请确认管理界面支持基于角色的授权，从而区分内容开发人员和操作员或系统管理员。例如，您不必许可更新静态 Web 站点的人改变客户的信用额度或重新配置数据库连接字符串。返回页首敏感数据请检查应用程序对存储中、应用程序内存中以及网络中的敏感数据的处理方法。表 5.5 显示了与处理敏感数据相关的常见漏洞。表 5.5：敏感数据处理中的常见漏洞漏洞影响在不必要

38、的情况下存储机密信息与不存储机密信息相比，这首先大大增加安全风险。在代码中存储机密数据如果代码位于服务器，攻击者可能下载它。在二进制程序集中，机密信息是可见的。以明文形式存储机密信息任何能登录服务器的人都可看到机密数据。在网络中以明文传递敏感数据窃听者可监控网络来获取并篡改这些数据。请考虑下列问题，帮助验证应用程序处理敏感数据的方法：是否存储机密信息？如何存储敏感数据？是否通过网络传递敏感数据？如何记录敏感数据？是否存储机密信息？机密信息包括了应用程序的配置数据，如帐户密码和加密密钥。如果可能，请明确其他避免保存机密信息的设计方法。如果要处理机密信息，请由系统平台处理它们，尽可能不在应用程序中

39、承担这一任务。如果确实要保存机密信息，请考虑下列问题：是否能避免存储机密信息？如果使用其他的实施技术，是否能避免存储机密信息。例如，如果只需了解用户是否知道密码，则无需存储密码。或者，仅保存单向的密码哈希值。此外，如果使用 Windows 身份验证，可通过嵌套凭据来避免存储连接字符串。如何存储机密信息？如果使用加密，如何确保加密密钥的安全？请考虑使用系统平台提供的 DPAPI 加密，这种加密能替您完成密钥管理。在何处保存机密信息？请检查应用程序保存加密数据的方法。要获得尽可能高的安全性，应使用 Windows ACL 限制对加密数据的访问。确认应用程序不以明文或源代码形式存储机密信息。如果使用

40、本地安全机构 (LSA)，检索机密信息的代码必须使用管理员特权才可以运行，这将增加风险。另一种不要求扩展特权的方法是使用 DPAPI。如何处理机密信息？请检验应用程序访问机密信息的方法，以及它们以明文形式存留在内存中的时间。机密信息通常应根据需要检索，并尽快使用，然后丢弃。是否在 cookie 中存储机密信息？如果是，请确保 cookie 是加密的，且不会永久保存在客户计算机中。如何存储敏感数据？如果存储了敏感的应用程序数据（如客户信用卡详细信息），请检查您的数据保护方法。使用怎样的加密算法？您应使用强加密算法来加密。例如，使用较长的密钥（如 Triple DES）。如何确保加密密钥的安全性？

41、数据的安全性与加密密钥安全性同等重要。因此，请检查确保密钥安全的方法。在理想状况下，使用 DPAPI 加密密钥并保存在受限位置（如注册表项中）来确保安全。是否在网络中传递敏感数据？如果通过网络传递敏感数据，请确保通过应用程序加密这些数据，或通过加密的通信链接来传递它们。是否记录敏感数据？请检查应用程序（或主机）是否在明文日志文件中记录用户帐户密码这样的敏感数据。通常，必须避免这样做。确保应用程序不在查询字符串中传递敏感数据，因为查询字符串会被记录，并可在客户端浏览器地址栏中直接看到。返回页首会话管理由于 Web 应用程序基于无状态的 HTTP 协议生成，因此会话管理是应用程序级任务。请检查应用

42、程序的会话管理方法，因为它将直接影响应用程序的整体安全。表 5.6 显示了与会话管理相关的常见漏洞。表 5.6：常见会话管理漏洞漏洞影响通过未加密的通道传递会话标识符攻击者可捕获会话标识符来窃取身份。会话生存期延长这将增加会话劫持和重播攻击的风险。会话状态存储不安全攻击者可访问用户的私有会话数据。查询字符串中的会话标识符可在客户端轻松修改会话标识符来窃取身份，然后作为另一用户访问应用程序。请考虑下列问题，帮助验证应用程序处理敏感数据的方法：如何交换会话标识符？是否限制会话生存期？如何确保会话状态存储的安全？如何交换会话标识符？请检查应用程序管理用户会话的会话标识符，以及这些会话标识符的交换方式

43、。请考虑下列问题：是否通过未加密的通道传递会话标识符？如果使用会话标识符（如 cookie 中包含的令牌）跟踪会话状态，请检查是否仅通过加密的通道（如 SSL）传递标识符或 cookie。是否加密会话 cookie？如果使用表单身份验证，确保应用程序使用 元素中的 protection=All 属性加密身份验证。建议同时使用 SSL 和这种方法，以便降低 XSS 攻击的风险，XSS 攻击可设法窃取用户的身份验证 cookie。是否在查询字符串中传递会话标识符？确保应用程序不在查询字符串中传递会话标识符。这些字符串可在客户端轻易修改，使用户能作为另一用户访问应用程序，访问其他用户的私有数据，并可

44、能提升特权。是否限制会话生存期？请检查应用程序认为会话标识符有效的时间。应用程序应限制这段时间的长度，以降低会话劫持和重播攻击的威胁。如何确保会话状态存储的安全？请检查应用程序存储会话状态的方法。会话状态可存储在 Web 应用程序进程、ASP.NET 会话状态服务，或 SQL Server 状态存储中。如果使用远程状态存储，请确保 Web 服务器到该远程存储的链接使用 IPSec 或 SSL 加密，以保护在网络中传输的数据。有关确保 ASP.NET 会话状态安全的详细信息，请参阅模块 19 确保 ASP.NET 应用程序和 Web Services 的安全中的“会话状态”。返回页首加密如果应用

45、程序使用加密来提供安全性，请检查加密的内容以及加密的使用方法。表 5.7 显示了与加密有关的常见漏洞。表 5.7：常见加密漏洞漏洞影响使用自定义加密安全性总是低于经过测试和考验的由系统平台提供的加密。使用错误的算法，或密钥大小过小使用较新的算法可提高安全性。使用较大的密钥也可提高安全性。不能确保加密密钥的安全性加密数据的安全性与加密密钥的安全性同等重要。在延长的时间段使用同一密钥如果长时间使用，静态密钥很容易被发现。请考虑下列问题，帮助验证应用程序处理敏感数据的方法：为何使用特定的算法？如何确保加密密钥的安全？为何使用特定的算法？加密只有在正确使用时才能提供真正的安全保障。不同作业使用不同算法

46、。算法的程度也非常重要。请考虑下列问题，评价所使用的加密算法：是否开发自己的加密技术？不要开发自己的加密技术。众所周知，加密算法和例程的开发非常难，而且很难成功。自定义实施的安全保护一般很弱，基本上不如久经考验的系统平台服务提供的安全措施。是否使用合适的密钥大小来应用正确的算法？检查应用程序使用的算法及使用该算法的目的。较大的密钥可提供较高的安全性，但会影响性能。对于在数据存储中长时间保存的永久数据，较强的加密非常重要。有关选择适当算法和密钥大小的详细信息，请参阅模块 4 Web 应用程序安全设计指南的“加密”部分。如何确保加密密钥的安全性？加密数据的安全与密钥安全同等重要。要破解加密数据，攻

47、击者必须能检索出密钥和密码文本。因此，请检查您的设计，确保加密密钥和加密数据的安全。请考虑下列评价问题：如何确保加密密钥的安全？如果使用 DPAPI，将由系统平台为您管理密钥。其他情况，则由应用程序负责密钥管理。检查应用程序确保加密密钥安全的方法。一种较好的方法是，使用 DPAPI 加密其他加密形式所需的加密密钥。然后，安全地保存加密密钥，例如，将其放在配置了受限 ACL 的注册表项下。回收密钥的频率如何？请不要滥用密钥。同一密钥使用的时间越长，被发现的可能性就越高。您的设计是否考虑了怎样回收密钥、回收的频率以及如何将它们分发并安置在服务器中？返回页首参数操作请检查应用程序使用参数的方法。这些

48、参数包括了在客户端和服务器间传递的表单字段、查询字符串、cookie、HTTP 头和视图状态。如果使用像查询字符串这样的参数传递敏感数据（如会话标识符），恶意客户端可轻松使用简单的参数操作逃避服务器端检查。表 5.8 显示了常见的参数操作漏洞。表 5.8：常见参数操作漏洞漏洞影响无法验证所有输入参数应用程序易受拒绝服务攻击和代码注入攻击，包括 SQL 注入和 XSS。未经加密的 cookie 中有敏感数据Cookie 数据可在客户端更改，也可通过网络传递获取并更改。查询字符串和表单字段中存在敏感数据这可在客户端轻松更改。信任 HTTP 头信息这可在客户端轻松更改。视图状态未保护这可在客户端轻松

49、更改。请考虑下列问题，帮助确保您的设计不受参数操作攻击影响：是否验证了所有的输入参数？是否在参数中传递了敏感数据？是否为了安全问题而使用 HTTP 头数据？是否验证所有的输入参数？确保应用程序验证所有的输入参数，包括正常和隐藏的表单字段、查询字符串和 cookie。是否在参数中传递敏感数据？如果应用程序在参数（如查询字符串或表单字段）中传递敏感数据，请检查应用程序使用这种方法而不是更安全方法（传递会话标识符）的原因。例如，在加密的 cookie 中传递会话标识符。使用这些信息将会话与在服务器状态存储中维护的用户状态相关联。请考虑下列评价问题：是否加密包含敏感数据的 cookie？如果应用程序使

50、用包含敏感数据的 cookie，如用户名或角色列表，请确保它是经过加密的。是否在查询字符串或表单字段中传递敏感数据？建议不要这样做，因为就操作查询字符串或表单字段中的数据而言，没有简便的方法可用。实际中，请考虑使用加密的会话标识符，然后将敏感数据保存在服务器的会话状态存储中。是否保护视图状态？如果 Web 页或控件使用视图状态在 HTTP 请求之间维持状态，请确保视图状态经过加密，并使用消息验证代码 (MAC) 检查其完整性。您可在计算机级配置该设置，也可按页配置。是否为了安全问题而使用 HTTP 头数据？确保 Web 应用程序不根据 HTTP 头中的信息制定安全决策，因为攻击者可轻松操作头。

51、不要依赖 HTTP 引用站点字段的值来检查源于页的请求是否由 Web 应用程序生成，这将带来漏洞。这种操作本身很不安全，因为引用站点字段可在客户端轻松更改。返回页首异常管理检查应用程序处理错误的方法。建议前后一致地使用结构化的异常处理。同样，确保应用程序不在发生异常时公开太多信息。表 5.9 显示了两大异常管理漏洞。表 5.9：常见异常管理漏洞漏洞影响无法使用结构化的异常处理应用程序更易受到拒绝服务攻击，并容易出现逻辑错误，从而暴露安全漏洞。向客户端公开太多信息攻击者可使用这些信息来规划和调整日后的攻击。请考虑下列问题，确保设计不易受到异常管理安全漏洞的影响：是否使用结构化的异常处理？是否向客户端公开了太多的信息？是否使用结构化的异常处理？检查应用程序如何使用结构化的异常处理。您的设计应强制在整个应用程序中使用一致的结构化异常处理。这将创建更强大的应用程序，应用程序因此不易处在暴露安全漏洞的不一致状态下。是否向客户端公开了太多的信息？确保恶意用户无法利用错误信息中的细节信息。请考虑下列问题：是否在服务器中捕获、处理和日志记录异常？确保应用程序不会将内部异常情况传播到应用程序边界以外。异常应在服务器中捕获并记录日志。