1.1.1 应用安全评估
应用评估概述
针对企业关键应用的安全性进行的评估，分析XXX 应用程序体系结构、设计思想和功能模块，从中发现可能的安全隐患。全面的了解应用系统在网络上的“表现”，将有助于对应用系统的维护与支持工作。了解XXX 应用系统的现状，发现存在的弱点和风险，作为后期改造的需求。本期项目针对XXX 具有代表性的不超过10个关键应用进行安全评估。
在进行应用评估的时候，引入了威胁建模的方法，这一方法是一种基于安全的分析，有助于我们确定应用系统造成的安全风险，以及攻击是如何体现出来的。
输入：
对于威胁建模，下面的输入非常有用：
⏹ 用例和使用方案
⏹ 数据流
⏹ 数据架构
⏹ 部署关系图
虽然这些都非常有用，但它们都不是必需的。但是，一定要了解应用程序的主要功能和体系结构。
输出：
威胁建模活动的输出结果是一个威胁模型。威胁模型捕获的主要项目包括：
威胁列表
漏洞列表
应用评估步骤
五个主要的威胁建模步骤如图 1 所示。
图1
我们把应用系统的安全评估划分为以下五个步骤：
1. 识别应用系统的安全目标：其中包括系统业务目标和安全目标。目
标清晰有助于将注意力集中在威胁建模活动，以及确定后续步骤要做多少工作。11
2. 了解应用系统概况：逐条列出应用程序的重要特征和参与者有助于
在步骤 4 中确定相关威胁。
3. 应用系统分解：全面了解应用程序的结构可以更轻松地发现更相
关、更具体的威胁。
4. 应用系统的威胁识别：使用步骤 2 和 3 中的详细信息来确定与您的
应用程序方案和上下文相关的威胁。
5. 应用系统的弱点分析：查应用程序的各层以确定与威胁有关的弱
点。
步骤1：识别安全目标
业务目标是应用系统使用的相关目标和约束。安全目标是与数据及应用
程序的保密性、完整性和可用性相关的目标和约束。
以约束的观点来考虑安全目标利用安全目标来指导威胁建模活动。请考虑这个问题，“您不希望发生什么？”例如，确保攻击者无法窃取用户凭据。
通过确定主要的安全目标，可以决定将主要精力放在什么地方。确定目标也有助于理解潜在攻击者的目标，并将注意力集中于那些需要密切留意的应用程序区域。例如，如果将客户帐户的详细信息确定为需要保护的敏感数据，那么您可以检查数据存储的安全性，以及如何控制和审核对数据的访问。
业务目标：一个应用系统的业务目标应该从如下几个方面入手进行分析：
⏹ 信誉：应用系统发生异常情况以及遭到攻击造成的商业信
誉的损失；
⏹ 经济：对于应用系统，如果发生攻击或者其它安全时间造
成的直接和潜在的经济损失。
⏹ 隐私：应用系统需要保护的用户数据。
⏹ 国家的法律或者政策：例如：等级化保护要求、SOX 法案
等。
⏹ 公司的规章制度。
⏹ 国际标准：例如：ISO17799、ISO13335等。
⏹ 法律协议。
⏹ 公司的信息安全策略。
安全目标：一个应用系统的安全目标应该从如下几个方面入手进行分析：
⏹ 系统的机密性：明确需要保护哪些客户端数据。应用系统
是否能够保护用户的识别信息不被滥用？例如：用户的信息被盗取用于其它非法用途；
⏹ 系统的完整性：明确应用系统是否要求确保数据信息的有
效性。
⏹ 系统的可用性：明确有特殊的服务质量要求。应用系统得
可用性应该达到什么级别（例如：中断的时间不能超过10分钟/
年）？根据系统可靠性的要求，可以重点保护重点的应用系统，从而节约投资。
通过访谈的方式确定应用系统业务目标和安全目标，对业务目标和安全目标进行细化，得到应用系统安全要求。
输入：访谈备忘录
输出：应用系统业务目标、安全目标和安全要求。
步骤2：应用系统概述
在本步骤中，概述应用系统的行为。确定应用程序的主要功能、特性和客户端。
创建应用系统概述步骤：
⏹ 画出端对端的部署方案。
⏹ 确定角色。
⏹ 确定主要使用方案。
⏹ 确定技术。
⏹ 确定应用程序的安全机制。
下面几部分将对此逐一进行说明：
画出端对端的部署方案：
画出一个描述应用程序的组成和结构、它的子系统以及部署特征的粗略图。随着对身份验证、授权和通信机制的发现来添加相关细节。
部署关系图通常应当包含以下元素：
⏹ 端对端的部署拓扑：显示服务器的布局，并指示 Intranet 、
Extranet 或 Internet 访问。从逻辑网络拓扑入手，然后在掌握详细信息时对其进行细化，以显示物理拓扑。根据所选的特定物理拓扑来添加或删除威胁。
⏹ 逻辑层:显示表示层、业务层和数据访问层的位置。知道物
理服务器的边界后，对此进行细化以将它们包括在内。
⏹ 主要组件:显示每个逻辑层中的重要组件。明确实际流程和
组件边界后，对此进行细化以将它们包括在内。
⏹ 主要服务:确定重要的服务。
⏹ 通信端口和协议。显示哪些服务器、组件和服务相互进行
通信，以及它们如何进行通信。了解入站和出站信息包的细节后，显示它们。
⏹ 标识：如果您有这些信息，则显示用于应用程序和所有相
关服务帐户的主要标识。
⏹ 外部依赖项：显示应用程序在外部系统上的依赖项。在稍
后的建模过程中，这会帮助您确定由于您所作的有关外部系统的假设是错误的、或者由于外部系统发生任何更改而产生的漏洞。
随着设计的进行，您应当定期复查威胁模型以添加更多细节。例如，最初您可能不了解所有的组件。应根据需要细分应用程序，以获得足够的细节来确定威胁。
确定角色：
确定应用程序的角色：即，确定应用程序中由谁来完成哪些工作。用户能做什么？您有什么样的高特权用户组？例如，谁可以读取数据、谁可以更新数据、谁可以删除数据？利用角色标识来确定应当发生什么以及不应当发生什么。
确定主要的使用方案：
确定的应用程序的主要功能是什么？它可以做什么？利用应用程序的用例来获得这些信息。确定应用程序的主要功能和用法，并捕获 Create 、Read 、Update 和 Delete 等方面。
经常在用例的上下文中解释主要功能。可以帮助理解应用程序应当如何使用，以及怎样是误用。用例有助于确定数据流，并可以在稍后的建模过程
中确定威胁时提供焦点。在这些用例中，您可以考察误用业务规则的可能性。例如，考虑某个用户试图更改另一个用户的个人详细资料。您通常需要考虑为进行完整的分析而同时发生的几个用例。
确定技术:
只要您能确定，就列出软件的技术和主要功能，以及您使用的技术。确定下列各项：
⏹ 操作系统。
⏹ 服务器软件。
⏹ 数据库服务器软件。
⏹ 在表示层、业务层和数据访问层中使用的技术。
⏹ 开发语言。
确定技术有助于在稍后的威胁建模活动中将主要精力放在特定于技术的威胁上，有助于确定正确的和最适当的缓解技术。
步骤3：系统分解
通过分解应用程序来确定信任边界、数据流、入口点和出口点。对应用程序结构了解得越多，就越容易发现威胁和漏洞。
分解应用程序按如下步骤：
⏹ 确定信任边界。
⏹ 确定数据流。
⏹ 确定入口点。
⏹ 确定出口点。
下面几部分将对此逐一进行说明。
确定信任边界：
确定应用程序的信任边界有助于将分析集中在所关注的区域。信任边界指示在什么地方更改信任级别。可以从机密性和完整性的角度来考虑信任。例如，在需要特定的角色或特权级别才能访问资源或操作的应用程序中，更改访问控制级别就是更改信任级别。另一个例子是应用程序的入口点，您可能不会完全信任传递到入口点的数据。
如何确定信任边界：
1. 从确定外部系统边界入手。例如，应用程序可以写服务器 X 上的文
件，可以调用服务器Y 上的数据库，并且可以调用 Web 服务 Z。这就定义了系统边界。
2. 确定访问控制点或需要附加的特权或角色成员资格才能访问的关键
地方。例如，某个特殊页可能只限于管理人员使用。该页要求经过身份验证的访问，还要求调用方是某个特定角色的成员。
3. 从数据流的角度确定信任边界。对于每个子系统，考虑是否信任上
游数据流或用户输入，如果不信任，则考虑如何对数据流和输入进行身份验证和授权。了解信任边界之间存在哪些入口点可以使您将威胁识别集中在这些关键入口点上。例如，可能需要在信任边界处对通过入口点的数据执行更多的验证。
确定数据流：
从入口到出口，跟踪应用程序的数据输入通过应用程序。这样做可以了解应用程序如何与外部系统和客户端进行交互，以及内部组件之间如何交互。要特别注意跨信任边界的数据流，以及如何在信任边界的入口点验证这些数据。还要密切注意敏感数据项，以及这些数据如何流过系统、它们通过网络传递到何处以及在什么地方保留。一种较好的方法是从最高级别入手，然后通过分析各个子系统之间的数据流来解构应用程序。例如，从分析应用程序、中间层服务器和数据库服务器之间的数据流开始。然后，考虑组件到组件的数据流。
确定入口点：
应用程序的入口点也是攻击的入口点。入口点可以包括侦听前端应用程序。这种入口点原本就是向客户端公开的。存在的其他入口点（例如，由跨应用程序层的子组件公开的内部入口点）。考虑访问入口点所需的信任级别，以及由入口点公开的功能类型。
确定出口点：
确定应用程序向客户端或者外部系统发送数据的点。设置出口点的优先级，应用程序可以在这些出口点上写数据，包括客户端输入或来自不受信任的源（例如，共享数据库）的数据。
步骤4：威胁识别
在本步骤中，确定可能影响应用程序和危及安全目标的威胁和攻击。这
些威胁可能会对应用程序有不良影响。
可以使用两种基本方法：
1. 从常见的威胁和攻击入手。利用这种方法，您可以从一系列按应用
程序漏洞类别分组的常见威胁入手。接下来，将威胁列表应用到您自己的应用程序体系结构中。
2. 使用问题驱动的方法。问题驱动的方法确定相关的威胁和攻击。
STRIDE 类别包括各种类型的威胁，例如，欺骗、篡改、否认、信息泄漏和拒绝访问。使用 STRIDE 模型来提出与应用程序的体系结构和设计的各个方面有关的问题。这是一种基于目标的方法，您要考虑的是攻击者的目标。例如，攻击者能够以一个虚假身份来访问您的服务器或 Web 应用程序吗？他人能够在网络或数据存储中篡改数据吗？当您报告错误消息或者记录事件时会泄漏敏感信息吗？他人能拒绝服务吗？
确定威胁时，要逐级、逐层、逐功能地进行检查。通过关注漏洞类别，将注意力集中在那些最常发生安全错误的区域。
在本步骤中，您要完成下列任务：
⏹ 确定常见的威胁和攻击。
⏹ 根据用例来确定威胁。
⏹ 根据数据流来确定威胁。
⏹ 利用威胁/攻击树研究其他威胁.
下面几部分将对此逐一进行说明。
确定常见的威胁和攻击：
许多常见的威胁和攻击依赖于常见的漏洞，根据应用程序安全框架确定威胁、根据用例确定威胁、根据数据流确定威胁和利用威胁/攻击树研究其他威胁。
应用程序安全框架
下面的漏洞类别是由安全专家对应用程序中数量最多的安全问题进行调查和分析后提取出来的。本部分为每个类别都确定了一组主要问题。
1. 身份验证
通过提出下列问题，对身份验证进行检查：
⏹ 攻击者如何欺骗身份？
⏹ 攻击者如何访问凭据存储？
⏹ 攻击者如何发动字典攻击？您的用户凭据是如何存储的以及执行的
密码策略是什么？
⏹ 攻击者如何更改、截取或回避用户的凭据重置机制？
2. 授权
通过提出下列问题，对授权进行检查：
⏹ 攻击者如何影响授权检查来进行特权操作？
⏹ 攻击者如何提升特权？
3. 输入和数据验证
⏹ 通过提出下列问题，对输入和数据验证进行检查：
⏹ 攻击者如何注入 SQL 命令？
⏹ 攻击者如何进行跨站点脚本攻击？
⏹ 攻击者如何回避输入验证？
⏹ 攻击者如何发送无效的输入来影响服务器上的安全逻辑？
⏹ 攻击者如何发送异常输入来使应用程序崩溃？
4. 配置管理
通过提出下列问题，对配置管理进行检查：
⏹ 攻击者如何使用管理功能？
⏹ 攻击者如何访问应用程序的配置数据？
5. 敏感数据
通过提出下列问题，对敏感数据进行检查：
⏹ 您的应用程序将敏感数据存储在何处以及如何存储？
⏹ 敏感数据何时何地通过网络进行传递？
⏹ 攻击者如何查看敏感数据？
⏹ 攻击者如何使用敏感数据？
6. 会话管理
通过提出下列问题，对会话管理进行检查：
⏹ 您使用的是一种自定义加密算法并且信任这种算法吗？
⏹ 攻击者如何攻击会话？
⏹ 攻击者如何查看或操纵另一个用户的会话状态？
7. 加密
通过提出下列问题，对加密进行检查：
⏹ 攻击者需要获得什么才能破解您的密码？
⏹ 攻击者如何获得密钥？
⏹ 您使用的是哪一种加密标准？如果有，针对这些标准有哪些攻击？ ⏹ 您创建了自己的加密方法吗？
⏹ 您的部署拓扑如何潜在地影响您对加密方法的选择？
8. 参数管理
通过提出下列问题，对参数管理进行检查：
⏹ 攻击者如何通过管理参数来更改服务器上的安全逻辑？
⏹ 攻击者如何管理敏感参数数据？
9. 异常管理
通过提出下列问题，对异常管理进行检查：
⏹ 攻击者如何使应用程序崩溃？
⏹ 攻击者如何获得有用的异常细节？
10. 审核与记录
通过提出下列问题，对审核与记录进行检查：
⏹ 攻击者如何掩盖他或她的踪迹？
⏹ 您如何证明攻击者（或合法用户）执行了特定的动作？
根据用例确定威胁:
检查以前确定的每个应用程序的主要用例，并检查用户能够恶意或无意地强制应用程序执行某种未经授权的操作或者泄漏敏感数据或私人数据的方法。
提出问题并尝试从攻击者的角度进行思考。您提出的问题类型应该包括：
⏹ 客户端在这里如何注入恶意输入？
⏹ 写出的数据是基于用户输入还是未验证的用户输入？
⏹ 攻击者如何操纵会话数据？
⏹ 当敏感数据在网络上传递时，攻击者如何获得它？
⏹ 攻击者如何回避您的授权检查？
根据数据流确定威胁:
检查主要用例和方案，并分析数据流。分析体系结构中各个组件之间的数据流。跨信任边界的数据流尤其重要。一段代码应该假定该代码的信任边界之外的数据都是恶意的。该代码应当对数据进行彻底验证。
当确定与数据流相关的威胁时，提出如下问题：
数据是如何从应用程序的前端流到后端的？
⏹ 哪个组件调用哪个组件？
⏹ 有效数据的外部特征是什么？
⏹ 验证在何处进行？
⏹ 如何约束数据？
⏹ 如何根据预期的长度、范围、格式和类型来验证数据？
⏹ 在组件之间和网络上传递什么敏感数据，以及在传输过程中如何保
护这些数据？
利用威胁/攻击树研究其他威胁:
前面的活动已经确定了更加明显和普遍的安全问题。现在研究其他威胁和攻击。攻击树和攻击模式是许多安全专家使用的主要工具。它们允许您更深入地分析威胁，而不会停留在对确定其他威胁可能性的理解上。已知威胁的类别列表只显示了常见的已知威胁，其他方法（如使用攻击树和攻击模式）可以确定其他潜在威胁。
攻击树是一种以结构化和层次化的方式确定和记录系统上潜在攻击的方法。这种树结构为您提供了一张攻击者用来危及系统安全的各种攻击的详细图画。通过创建攻击树，创建了一种可重复使用的安全问题表示法，这有助于将注意力集中在威胁上并减轻工作量。攻击模式是一种捕获企业中攻击信息的正规化方法。这些模式可以帮助确定常见的攻击方法。
创建攻击树：在创建攻击树时，可以假定攻击者的角色。考虑要发起一次成功的攻击您必须要做什么，并确定攻击的目标和子目标。利用一个谱系图来表示攻击树表示。
要构建攻击树，首先要创建表示攻击者的目标的根节点。然后添加叶节点，它们是代表唯一攻击的攻击方法。
步骤5：漏洞分析
在本步骤中，检查应用程序的安全框架，并显式地查找漏洞。一种有效的方法是逐层检查应用程序，考虑每层中的各种漏洞类别。
身份验证
通过提出下列问题，确定身份验证漏洞：
⏹ 用户名和密码是以明文的形式在未受保护的信道上发送的吗？敏感
信息有专门的加密方法吗？
⏹ 存储证书了吗？如果存储了，是如何存储和保护它们的？ ⏹ 您执行强密码吗？执行什么样的其他密码策略？
⏹ 如何验证凭据？
⏹ 首次登录后，如何识别经过身份验证的用户？
通过查找这些常见的漏洞检查身份验证：
⏹ 在未加密的网络链接上传递身份验证凭据或身份验证 cookie ，这会
引起凭据捕获或会话攻击
⏹ 利用弱密码和帐户策略，这会引起未经授权的访问
⏹ 将个性化与身份验证混合起来
授权
通过提出下列问题，确定授权漏洞：
⏹ 在应用程序的入口点使用了什么样的访问控制？
⏹ 应用程序使用角色吗？如果它使用角色，那么对于访问控制和审核
目的来说它们的粒度足够细吗？
⏹ 您的授权代码是否安全地失效，并且是否只准许成功进行凭据确认
后才能进行访问？
⏹ 您是否限制访问系统资源？
⏹ 您是否限制数据库访问？
⏹ 对于数据库，如何进行授权？
通过查找这些常见漏洞检查授权：
⏹ 使用越权角色和帐户
⏹ 没有提供足够的角色粒度
⏹ 没有将系统资源限制于特定的应用程序身份
输入和数据验证
通过提出下列问题，确定输入和数据验证漏洞：
⏹ 验证所有输入数据了吗？
⏹ 您验证长度、范围、格式和类型了吗？
⏹ 您依赖于客户端验证吗？
⏹ 攻击者可以将命令或恶意数据注入应用程序吗？
⏹ 您信任您写出到 Web 页上的数据吗？或者您需要将它进行 HTML
编码以帮助防止跨站点脚本攻击吗？
⏹ 在 SQL 语句中使用输入之前，您验证过它以帮助防止 SQL 注入
吗？
⏹ 在不同的信任边界之间传递数据时，在接收入口点验证数据吗？ ⏹ 您信任数据库中的数据吗？
⏹ 您接受输入文件名、URL 或用户名吗？您是否已解决了规范化问
题？
通过查找这些常见漏洞检查输入验证：
⏹ 完全依赖于客户端验证
⏹ 使用 deny 方法而非 allow 来筛选输入
⏹ 将未经验证的数据写出到 Web 页
⏹ 利用未经验证的输入来生成 SQL 查询
⏹ 使用不安全的数据访问编码技术，这可能增加 SQL 注入引起的威胁 ⏹ 使用输入文件名、URL 或用户名进行安全决策
配置管理
通过提出下列问题，确定配置管理漏洞：
⏹ 您如何保护远程管理界面？
⏹ 您保护配置存储吗？
⏹ 您对敏感配置数据加密吗？
⏹ 您分离管理员特权吗？
⏹ 您使用具有最低特权的进程和服务帐户吗？
通过查找这些常见漏洞检查配置管理：
⏹ 以明文存储配置机密信息，例如，连接字符串和服务帐户证书 ⏹ 没有保护应用程序配置管理的外观，包括管理界面
⏹ 使用越权进程帐户和服务帐户
敏感数据
通过提出下列问题，确定敏感数据漏洞：
⏹ 您是否在永久性存储中存储机密信息？
⏹ 您如何存储敏感数据？
⏹ 您在内存中存储机密信息吗？
⏹ 您在网络上传递敏感数据吗？
⏹ 您记录敏感数据吗？
通过查找这些常见漏洞检查敏感数据：
⏹ 在不需要存储机密信息时保存它们
⏹ 在代码中存储机密信息
⏹ 以明文形式存储机密信息
⏹ 在网络上以明文形式传递敏感数据
会话管理
通过提出如下问题，确定会话管理漏洞：
⏹ 如何生成会话 cookie？
⏹ 如何交换会话标识符？
⏹ 在跨越网络时如何保护会话状态？
⏹ 如何保护会话状态以防止会话攻击？
⏹ 如何保护会话状态存储？
⏹ 您限制会话的生存期吗？
⏹ 应用程序如何用会话存储进行身份验证？
⏹ 凭据是通过网络传递并由应用程序维护的吗？如果是，如何保护它
们？
通过查找这些常见漏洞检查会话管理：
⏹ 在未加密信道上传递会话标识符
⏹ 延长会话的生存期
⏹ 不安全的会话状态存储
⏹ 会话标识符位于查询字符串中
加密
通过提出下列问题，确定加密漏洞：
⏹ 使用什么算法和加密技术？
⏹ 您使用自定义的加密算法吗？
⏹ 您为何使用特定算法？
⏹ 密钥有多长、如何保护它们？
⏹ 多长时间更换一次密钥？
⏹ 如何发布密钥？
通过查找这些常见漏洞检查加密：
⏹ 使用自定义加密方法
⏹ 使用错误的算法或者长度太短的密钥
⏹ 没有保护密钥
⏹ 对于延长的时间周期使用同一个密钥
参数管理
通过提出下列问题，确定参数管理漏洞：
⏹ 验证所有的输入参数吗？
⏹ 您验证表单域、视图状态、cookie 数据和 HTTP 标题中的所有参数
吗？
⏹ 您传递敏感数据参数吗？
⏹ 应用程序检测被篡改的参数吗？
通过查找这些常见漏洞检查参数管理：
⏹ 没有验证所有的输入参数这使您的应用程序容易受到拒绝服务攻击
和代码注入攻击，包括 SQL 注入和 XSS。
⏹ 未加密的 cookie 中包含敏感数据。攻击者可以在客户端更改 cookie
数据，或者当它在网络上传递时进行捕获和更改。
⏹ 查询字符串和表单域中包含敏感数据。很容易在客户端更改查询字
符串和表单域。
⏹ 信任 HTTP 标题信息。这种信息在客户端很容易更改。
异常管理
通过提出下列问题，确定异常管理漏洞：
⏹ 应用程序如何处理错误条件？
⏹ 允许异常传播回客户端吗？
⏹ 异常消息包含什么类型的数据？
⏹ 您是否显示给客户端太多的信息？
⏹ 您在哪里记录异常的详细资料？日志文件安全吗？
通过查找这些常见漏洞检查异常管理：
⏹ 没有验证所有的输入参数
⏹ 显示给客户端的信息太多
审核与记录
通过提出下列问题确定审核与记录漏洞：
⏹ 您确定进行审核的主要活动了吗？
⏹ 您的应用程序是跨所有层和服务器进行审核的吗？
⏹ 如何保护日志文件？
通过查找这些常见漏洞检查审核与记录：
⏹ 没有审核失败的登录
⏹ 没有保护审核文件
⏹ 没有跨应用程序层和服务器进行审核
通过弱点分析，输出应用系统漏洞列表。
1.1.1 应用安全评估
应用评估概述
针对企业关键应用的安全性进行的评估，分析XXX 应用程序体系结构、设计思想和功能模块，从中发现可能的安全隐患。全面的了解应用系统在网络上的“表现”，将有助于对应用系统的维护与支持工作。了解XXX 应用系统的现状，发现存在的弱点和风险，作为后期改造的需求。本期项目针对XXX 具有代表性的不超过10个关键应用进行安全评估。
在进行应用评估的时候，引入了威胁建模的方法，这一方法是一种基于安全的分析，有助于我们确定应用系统造成的安全风险，以及攻击是如何体现出来的。
输入：
对于威胁建模，下面的输入非常有用：
⏹ 用例和使用方案
⏹ 数据流
⏹ 数据架构
⏹ 部署关系图
虽然这些都非常有用，但它们都不是必需的。但是，一定要了解应用程序的主要功能和体系结构。
输出：
威胁建模活动的输出结果是一个威胁模型。威胁模型捕获的主要项目包括：
威胁列表
漏洞列表
应用评估步骤
五个主要的威胁建模步骤如图 1 所示。
图1
我们把应用系统的安全评估划分为以下五个步骤：
1. 识别应用系统的安全目标：其中包括系统业务目标和安全目标。目
标清晰有助于将注意力集中在威胁建模活动，以及确定后续步骤要做多少工作。11
2. 了解应用系统概况：逐条列出应用程序的重要特征和参与者有助于
在步骤 4 中确定相关威胁。
3. 应用系统分解：全面了解应用程序的结构可以更轻松地发现更相
关、更具体的威胁。
4. 应用系统的威胁识别：使用步骤 2 和 3 中的详细信息来确定与您的
应用程序方案和上下文相关的威胁。
5. 应用系统的弱点分析：查应用程序的各层以确定与威胁有关的弱
点。
步骤1：识别安全目标
业务目标是应用系统使用的相关目标和约束。安全目标是与数据及应用
程序的保密性、完整性和可用性相关的目标和约束。
以约束的观点来考虑安全目标利用安全目标来指导威胁建模活动。请考虑这个问题，“您不希望发生什么？”例如，确保攻击者无法窃取用户凭据。
通过确定主要的安全目标，可以决定将主要精力放在什么地方。确定目标也有助于理解潜在攻击者的目标，并将注意力集中于那些需要密切留意的应用程序区域。例如，如果将客户帐户的详细信息确定为需要保护的敏感数据，那么您可以检查数据存储的安全性，以及如何控制和审核对数据的访问。
业务目标：一个应用系统的业务目标应该从如下几个方面入手进行分析：
⏹ 信誉：应用系统发生异常情况以及遭到攻击造成的商业信
誉的损失；
⏹ 经济：对于应用系统，如果发生攻击或者其它安全时间造
成的直接和潜在的经济损失。
⏹ 隐私：应用系统需要保护的用户数据。
⏹ 国家的法律或者政策：例如：等级化保护要求、SOX 法案
等。
⏹ 公司的规章制度。
⏹ 国际标准：例如：ISO17799、ISO13335等。
⏹ 法律协议。
⏹ 公司的信息安全策略。
安全目标：一个应用系统的安全目标应该从如下几个方面入手进行分析：
⏹ 系统的机密性：明确需要保护哪些客户端数据。应用系统
是否能够保护用户的识别信息不被滥用？例如：用户的信息被盗取用于其它非法用途；
⏹ 系统的完整性：明确应用系统是否要求确保数据信息的有
效性。
⏹ 系统的可用性：明确有特殊的服务质量要求。应用系统得
可用性应该达到什么级别（例如：中断的时间不能超过10分钟/
年）？根据系统可靠性的要求，可以重点保护重点的应用系统，从而节约投资。
通过访谈的方式确定应用系统业务目标和安全目标，对业务目标和安全目标进行细化，得到应用系统安全要求。
输入：访谈备忘录
输出：应用系统业务目标、安全目标和安全要求。
步骤2：应用系统概述
在本步骤中，概述应用系统的行为。确定应用程序的主要功能、特性和客户端。
创建应用系统概述步骤：
⏹ 画出端对端的部署方案。
⏹ 确定角色。
⏹ 确定主要使用方案。
⏹ 确定技术。
⏹ 确定应用程序的安全机制。
下面几部分将对此逐一进行说明：
画出端对端的部署方案：
画出一个描述应用程序的组成和结构、它的子系统以及部署特征的粗略图。随着对身份验证、授权和通信机制的发现来添加相关细节。
部署关系图通常应当包含以下元素：
⏹ 端对端的部署拓扑：显示服务器的布局，并指示 Intranet 、
Extranet 或 Internet 访问。从逻辑网络拓扑入手，然后在掌握详细信息时对其进行细化，以显示物理拓扑。根据所选的特定物理拓扑来添加或删除威胁。
⏹ 逻辑层:显示表示层、业务层和数据访问层的位置。知道物
理服务器的边界后，对此进行细化以将它们包括在内。
⏹ 主要组件:显示每个逻辑层中的重要组件。明确实际流程和
组件边界后，对此进行细化以将它们包括在内。
⏹ 主要服务:确定重要的服务。
⏹ 通信端口和协议。显示哪些服务器、组件和服务相互进行
通信，以及它们如何进行通信。了解入站和出站信息包的细节后，显示它们。
⏹ 标识：如果您有这些信息，则显示用于应用程序和所有相
关服务帐户的主要标识。
⏹ 外部依赖项：显示应用程序在外部系统上的依赖项。在稍
后的建模过程中，这会帮助您确定由于您所作的有关外部系统的假设是错误的、或者由于外部系统发生任何更改而产生的漏洞。
随着设计的进行，您应当定期复查威胁模型以添加更多细节。例如，最初您可能不了解所有的组件。应根据需要细分应用程序，以获得足够的细节来确定威胁。
确定角色：
确定应用程序的角色：即，确定应用程序中由谁来完成哪些工作。用户能做什么？您有什么样的高特权用户组？例如，谁可以读取数据、谁可以更新数据、谁可以删除数据？利用角色标识来确定应当发生什么以及不应当发生什么。
确定主要的使用方案：
确定的应用程序的主要功能是什么？它可以做什么？利用应用程序的用例来获得这些信息。确定应用程序的主要功能和用法，并捕获 Create 、Read 、Update 和 Delete 等方面。
经常在用例的上下文中解释主要功能。可以帮助理解应用程序应当如何使用，以及怎样是误用。用例有助于确定数据流，并可以在稍后的建模过程
中确定威胁时提供焦点。在这些用例中，您可以考察误用业务规则的可能性。例如，考虑某个用户试图更改另一个用户的个人详细资料。您通常需要考虑为进行完整的分析而同时发生的几个用例。
确定技术:
只要您能确定，就列出软件的技术和主要功能，以及您使用的技术。确定下列各项：
⏹ 操作系统。
⏹ 服务器软件。
⏹ 数据库服务器软件。
⏹ 在表示层、业务层和数据访问层中使用的技术。
⏹ 开发语言。
确定技术有助于在稍后的威胁建模活动中将主要精力放在特定于技术的威胁上，有助于确定正确的和最适当的缓解技术。
步骤3：系统分解
通过分解应用程序来确定信任边界、数据流、入口点和出口点。对应用程序结构了解得越多，就越容易发现威胁和漏洞。
分解应用程序按如下步骤：
⏹ 确定信任边界。
⏹ 确定数据流。
⏹ 确定入口点。
⏹ 确定出口点。
下面几部分将对此逐一进行说明。
确定信任边界：
确定应用程序的信任边界有助于将分析集中在所关注的区域。信任边界指示在什么地方更改信任级别。可以从机密性和完整性的角度来考虑信任。例如，在需要特定的角色或特权级别才能访问资源或操作的应用程序中，更改访问控制级别就是更改信任级别。另一个例子是应用程序的入口点，您可能不会完全信任传递到入口点的数据。
如何确定信任边界：
1. 从确定外部系统边界入手。例如，应用程序可以写服务器 X 上的文
件，可以调用服务器Y 上的数据库，并且可以调用 Web 服务 Z。这就定义了系统边界。
2. 确定访问控制点或需要附加的特权或角色成员资格才能访问的关键
地方。例如，某个特殊页可能只限于管理人员使用。该页要求经过身份验证的访问，还要求调用方是某个特定角色的成员。
3. 从数据流的角度确定信任边界。对于每个子系统，考虑是否信任上
游数据流或用户输入，如果不信任，则考虑如何对数据流和输入进行身份验证和授权。了解信任边界之间存在哪些入口点可以使您将威胁识别集中在这些关键入口点上。例如，可能需要在信任边界处对通过入口点的数据执行更多的验证。
确定数据流：
从入口到出口，跟踪应用程序的数据输入通过应用程序。这样做可以了解应用程序如何与外部系统和客户端进行交互，以及内部组件之间如何交互。要特别注意跨信任边界的数据流，以及如何在信任边界的入口点验证这些数据。还要密切注意敏感数据项，以及这些数据如何流过系统、它们通过网络传递到何处以及在什么地方保留。一种较好的方法是从最高级别入手，然后通过分析各个子系统之间的数据流来解构应用程序。例如，从分析应用程序、中间层服务器和数据库服务器之间的数据流开始。然后，考虑组件到组件的数据流。
确定入口点：
应用程序的入口点也是攻击的入口点。入口点可以包括侦听前端应用程序。这种入口点原本就是向客户端公开的。存在的其他入口点（例如，由跨应用程序层的子组件公开的内部入口点）。考虑访问入口点所需的信任级别，以及由入口点公开的功能类型。
确定出口点：
确定应用程序向客户端或者外部系统发送数据的点。设置出口点的优先级，应用程序可以在这些出口点上写数据，包括客户端输入或来自不受信任的源（例如，共享数据库）的数据。
步骤4：威胁识别
在本步骤中，确定可能影响应用程序和危及安全目标的威胁和攻击。这
些威胁可能会对应用程序有不良影响。
可以使用两种基本方法：
1. 从常见的威胁和攻击入手。利用这种方法，您可以从一系列按应用
程序漏洞类别分组的常见威胁入手。接下来，将威胁列表应用到您自己的应用程序体系结构中。
2. 使用问题驱动的方法。问题驱动的方法确定相关的威胁和攻击。
STRIDE 类别包括各种类型的威胁，例如，欺骗、篡改、否认、信息泄漏和拒绝访问。使用 STRIDE 模型来提出与应用程序的体系结构和设计的各个方面有关的问题。这是一种基于目标的方法，您要考虑的是攻击者的目标。例如，攻击者能够以一个虚假身份来访问您的服务器或 Web 应用程序吗？他人能够在网络或数据存储中篡改数据吗？当您报告错误消息或者记录事件时会泄漏敏感信息吗？他人能拒绝服务吗？
确定威胁时，要逐级、逐层、逐功能地进行检查。通过关注漏洞类别，将注意力集中在那些最常发生安全错误的区域。
在本步骤中，您要完成下列任务：
⏹ 确定常见的威胁和攻击。
⏹ 根据用例来确定威胁。
⏹ 根据数据流来确定威胁。
⏹ 利用威胁/攻击树研究其他威胁.
下面几部分将对此逐一进行说明。
确定常见的威胁和攻击：
许多常见的威胁和攻击依赖于常见的漏洞，根据应用程序安全框架确定威胁、根据用例确定威胁、根据数据流确定威胁和利用威胁/攻击树研究其他威胁。
应用程序安全框架
下面的漏洞类别是由安全专家对应用程序中数量最多的安全问题进行调查和分析后提取出来的。本部分为每个类别都确定了一组主要问题。
1. 身份验证
通过提出下列问题，对身份验证进行检查：
⏹ 攻击者如何欺骗身份？
⏹ 攻击者如何访问凭据存储？
⏹ 攻击者如何发动字典攻击？您的用户凭据是如何存储的以及执行的
密码策略是什么？
⏹ 攻击者如何更改、截取或回避用户的凭据重置机制？
2. 授权
通过提出下列问题，对授权进行检查：
⏹ 攻击者如何影响授权检查来进行特权操作？
⏹ 攻击者如何提升特权？
3. 输入和数据验证
⏹ 通过提出下列问题，对输入和数据验证进行检查：
⏹ 攻击者如何注入 SQL 命令？
⏹ 攻击者如何进行跨站点脚本攻击？
⏹ 攻击者如何回避输入验证？
⏹ 攻击者如何发送无效的输入来影响服务器上的安全逻辑？
⏹ 攻击者如何发送异常输入来使应用程序崩溃？
4. 配置管理
通过提出下列问题，对配置管理进行检查：
⏹ 攻击者如何使用管理功能？
⏹ 攻击者如何访问应用程序的配置数据？
5. 敏感数据
通过提出下列问题，对敏感数据进行检查：
⏹ 您的应用程序将敏感数据存储在何处以及如何存储？
⏹ 敏感数据何时何地通过网络进行传递？
⏹ 攻击者如何查看敏感数据？
⏹ 攻击者如何使用敏感数据？
6. 会话管理
通过提出下列问题，对会话管理进行检查：
⏹ 您使用的是一种自定义加密算法并且信任这种算法吗？
⏹ 攻击者如何攻击会话？
⏹ 攻击者如何查看或操纵另一个用户的会话状态？
7. 加密
通过提出下列问题，对加密进行检查：
⏹ 攻击者需要获得什么才能破解您的密码？
⏹ 攻击者如何获得密钥？
⏹ 您使用的是哪一种加密标准？如果有，针对这些标准有哪些攻击？ ⏹ 您创建了自己的加密方法吗？
⏹ 您的部署拓扑如何潜在地影响您对加密方法的选择？
8. 参数管理
通过提出下列问题，对参数管理进行检查：
⏹ 攻击者如何通过管理参数来更改服务器上的安全逻辑？
⏹ 攻击者如何管理敏感参数数据？
9. 异常管理
通过提出下列问题，对异常管理进行检查：
⏹ 攻击者如何使应用程序崩溃？
⏹ 攻击者如何获得有用的异常细节？
10. 审核与记录
通过提出下列问题，对审核与记录进行检查：
⏹ 攻击者如何掩盖他或她的踪迹？
⏹ 您如何证明攻击者（或合法用户）执行了特定的动作？
根据用例确定威胁:
检查以前确定的每个应用程序的主要用例，并检查用户能够恶意或无意地强制应用程序执行某种未经授权的操作或者泄漏敏感数据或私人数据的方法。
提出问题并尝试从攻击者的角度进行思考。您提出的问题类型应该包括：
⏹ 客户端在这里如何注入恶意输入？
⏹ 写出的数据是基于用户输入还是未验证的用户输入？
⏹ 攻击者如何操纵会话数据？
⏹ 当敏感数据在网络上传递时，攻击者如何获得它？
⏹ 攻击者如何回避您的授权检查？
根据数据流确定威胁:
检查主要用例和方案，并分析数据流。分析体系结构中各个组件之间的数据流。跨信任边界的数据流尤其重要。一段代码应该假定该代码的信任边界之外的数据都是恶意的。该代码应当对数据进行彻底验证。
当确定与数据流相关的威胁时，提出如下问题：
数据是如何从应用程序的前端流到后端的？
⏹ 哪个组件调用哪个组件？
⏹ 有效数据的外部特征是什么？
⏹ 验证在何处进行？
⏹ 如何约束数据？
⏹ 如何根据预期的长度、范围、格式和类型来验证数据？
⏹ 在组件之间和网络上传递什么敏感数据，以及在传输过程中如何保
护这些数据？
利用威胁/攻击树研究其他威胁:
前面的活动已经确定了更加明显和普遍的安全问题。现在研究其他威胁和攻击。攻击树和攻击模式是许多安全专家使用的主要工具。它们允许您更深入地分析威胁，而不会停留在对确定其他威胁可能性的理解上。已知威胁的类别列表只显示了常见的已知威胁，其他方法（如使用攻击树和攻击模式）可以确定其他潜在威胁。
攻击树是一种以结构化和层次化的方式确定和记录系统上潜在攻击的方法。这种树结构为您提供了一张攻击者用来危及系统安全的各种攻击的详细图画。通过创建攻击树，创建了一种可重复使用的安全问题表示法，这有助于将注意力集中在威胁上并减轻工作量。攻击模式是一种捕获企业中攻击信息的正规化方法。这些模式可以帮助确定常见的攻击方法。
创建攻击树：在创建攻击树时，可以假定攻击者的角色。考虑要发起一次成功的攻击您必须要做什么，并确定攻击的目标和子目标。利用一个谱系图来表示攻击树表示。
要构建攻击树，首先要创建表示攻击者的目标的根节点。然后添加叶节点，它们是代表唯一攻击的攻击方法。
步骤5：漏洞分析
在本步骤中，检查应用程序的安全框架，并显式地查找漏洞。一种有效的方法是逐层检查应用程序，考虑每层中的各种漏洞类别。
身份验证
通过提出下列问题，确定身份验证漏洞：
⏹ 用户名和密码是以明文的形式在未受保护的信道上发送的吗？敏感
信息有专门的加密方法吗？
⏹ 存储证书了吗？如果存储了，是如何存储和保护它们的？ ⏹ 您执行强密码吗？执行什么样的其他密码策略？
⏹ 如何验证凭据？
⏹ 首次登录后，如何识别经过身份验证的用户？
通过查找这些常见的漏洞检查身份验证：
⏹ 在未加密的网络链接上传递身份验证凭据或身份验证 cookie ，这会
引起凭据捕获或会话攻击
⏹ 利用弱密码和帐户策略，这会引起未经授权的访问
⏹ 将个性化与身份验证混合起来
授权
通过提出下列问题，确定授权漏洞：
⏹ 在应用程序的入口点使用了什么样的访问控制？
⏹ 应用程序使用角色吗？如果它使用角色，那么对于访问控制和审核
目的来说它们的粒度足够细吗？
⏹ 您的授权代码是否安全地失效，并且是否只准许成功进行凭据确认
后才能进行访问？
⏹ 您是否限制访问系统资源？
⏹ 您是否限制数据库访问？
⏹ 对于数据库，如何进行授权？
通过查找这些常见漏洞检查授权：
⏹ 使用越权角色和帐户
⏹ 没有提供足够的角色粒度
⏹ 没有将系统资源限制于特定的应用程序身份
输入和数据验证
通过提出下列问题，确定输入和数据验证漏洞：
⏹ 验证所有输入数据了吗？
⏹ 您验证长度、范围、格式和类型了吗？
⏹ 您依赖于客户端验证吗？
⏹ 攻击者可以将命令或恶意数据注入应用程序吗？
⏹ 您信任您写出到 Web 页上的数据吗？或者您需要将它进行 HTML
编码以帮助防止跨站点脚本攻击吗？
⏹ 在 SQL 语句中使用输入之前，您验证过它以帮助防止 SQL 注入
吗？
⏹ 在不同的信任边界之间传递数据时，在接收入口点验证数据吗？ ⏹ 您信任数据库中的数据吗？
⏹ 您接受输入文件名、URL 或用户名吗？您是否已解决了规范化问
题？
通过查找这些常见漏洞检查输入验证：
⏹ 完全依赖于客户端验证
⏹ 使用 deny 方法而非 allow 来筛选输入
⏹ 将未经验证的数据写出到 Web 页
⏹ 利用未经验证的输入来生成 SQL 查询
⏹ 使用不安全的数据访问编码技术，这可能增加 SQL 注入引起的威胁 ⏹ 使用输入文件名、URL 或用户名进行安全决策
配置管理
通过提出下列问题，确定配置管理漏洞：
⏹ 您如何保护远程管理界面？
⏹ 您保护配置存储吗？
⏹ 您对敏感配置数据加密吗？
⏹ 您分离管理员特权吗？
⏹ 您使用具有最低特权的进程和服务帐户吗？
通过查找这些常见漏洞检查配置管理：
⏹ 以明文存储配置机密信息，例如，连接字符串和服务帐户证书 ⏹ 没有保护应用程序配置管理的外观，包括管理界面
⏹ 使用越权进程帐户和服务帐户
敏感数据
通过提出下列问题，确定敏感数据漏洞：
⏹ 您是否在永久性存储中存储机密信息？
⏹ 您如何存储敏感数据？
⏹ 您在内存中存储机密信息吗？
⏹ 您在网络上传递敏感数据吗？
⏹ 您记录敏感数据吗？
通过查找这些常见漏洞检查敏感数据：
⏹ 在不需要存储机密信息时保存它们
⏹ 在代码中存储机密信息
⏹ 以明文形式存储机密信息
⏹ 在网络上以明文形式传递敏感数据
会话管理
通过提出如下问题，确定会话管理漏洞：
⏹ 如何生成会话 cookie？
⏹ 如何交换会话标识符？
⏹ 在跨越网络时如何保护会话状态？
⏹ 如何保护会话状态以防止会话攻击？
⏹ 如何保护会话状态存储？
⏹ 您限制会话的生存期吗？
⏹ 应用程序如何用会话存储进行身份验证？
⏹ 凭据是通过网络传递并由应用程序维护的吗？如果是，如何保护它
们？
通过查找这些常见漏洞检查会话管理：
⏹ 在未加密信道上传递会话标识符
⏹ 延长会话的生存期
⏹ 不安全的会话状态存储
⏹ 会话标识符位于查询字符串中
加密
通过提出下列问题，确定加密漏洞：
⏹ 使用什么算法和加密技术？
⏹ 您使用自定义的加密算法吗？
⏹ 您为何使用特定算法？
⏹ 密钥有多长、如何保护它们？
⏹ 多长时间更换一次密钥？
⏹ 如何发布密钥？
通过查找这些常见漏洞检查加密：
⏹ 使用自定义加密方法
⏹ 使用错误的算法或者长度太短的密钥
⏹ 没有保护密钥
⏹ 对于延长的时间周期使用同一个密钥
参数管理
通过提出下列问题，确定参数管理漏洞：
⏹ 验证所有的输入参数吗？
⏹ 您验证表单域、视图状态、cookie 数据和 HTTP 标题中的所有参数
吗？
⏹ 您传递敏感数据参数吗？
⏹ 应用程序检测被篡改的参数吗？
通过查找这些常见漏洞检查参数管理：
⏹ 没有验证所有的输入参数这使您的应用程序容易受到拒绝服务攻击
和代码注入攻击，包括 SQL 注入和 XSS。
⏹ 未加密的 cookie 中包含敏感数据。攻击者可以在客户端更改 cookie
数据，或者当它在网络上传递时进行捕获和更改。
⏹ 查询字符串和表单域中包含敏感数据。很容易在客户端更改查询字
符串和表单域。
⏹ 信任 HTTP 标题信息。这种信息在客户端很容易更改。
异常管理
通过提出下列问题，确定异常管理漏洞：
⏹ 应用程序如何处理错误条件？
⏹ 允许异常传播回客户端吗？
⏹ 异常消息包含什么类型的数据？
⏹ 您是否显示给客户端太多的信息？
⏹ 您在哪里记录异常的详细资料？日志文件安全吗？
通过查找这些常见漏洞检查异常管理：
⏹ 没有验证所有的输入参数
⏹ 显示给客户端的信息太多
审核与记录
通过提出下列问题确定审核与记录漏洞：
⏹ 您确定进行审核的主要活动了吗？
⏹ 您的应用程序是跨所有层和服务器进行审核的吗？
⏹ 如何保护日志文件？
通过查找这些常见漏洞检查审核与记录：
⏹ 没有审核失败的登录
⏹ 没有保护审核文件
⏹ 没有跨应用程序层和服务器进行审核
通过弱点分析，输出应用系统漏洞列表。