业务系统暨应用系统安全评估指南Word格式.doc

业务系统暨应用系统安全评估指南Word格式.doc

《业务系统暨应用系统安全评估指南Word格式.doc》由会员分享，可在线阅读，更多相关《业务系统暨应用系统安全评估指南Word格式.doc（48页珍藏版）》请在冰豆网上搜索。

1

编写，修改

文档作者

2

读取

目录

1 概述 7

1.1 评估的范围与概念澄清 7

1.1.1 业务系统评估 7

1.1.2 应用系统评估 8

1.2 评估手段 9

1.3 评估实施环境 10

2 软件工程模型对安全评估的借鉴 10

2.1 软件工程对信息安全评估工作的借鉴意义 10

2.2 以业务为核心的全面风险评估 10

2.3 组织结构与功能 11

2.3.1 组织结构图 11

2.3.2 组织/业务关系图 12

2.3.3 业务功能表 13

2.3.4 组织结构与功能分析对安全评估的借鉴 13

2.4 业务流程分析 13

2.4.1 软件工程中的业务流程分析 13

2.4.2 安氏现有的业务流程评估 14

2.4.3 业务流程分析对安全评估的借鉴 15

2.5 数据流程分析 17

2.5.1 软件工程中的数据流程分析 17

2.5.2 数据流程分析对安全评估的借鉴 19

2.6 威胁模型 23

3 应用系统的安全开发过程 24

3.1 教育 24

3.2 设计阶段 24

3.2.1 面试时进行安全性考核 24

3.2.2 设定产品的安全目标 25

3.2.3 建立威胁模型 25

3.2.4 设置Bug阀值 25

3.2.5 安全小组检查 25

3.3 开发阶段 26

3.3.1 定义安全的编码准则 26

3.3.2 审查旧的安全问题 26

3.3.3 外部安全审查 26

3.3.4 安全推动活动 26

3.4 测试阶段 26

3.5 发行和维护阶段 27

3.5.1 响应过程 27

4 评估前的准备 27

4.1.1 确定用户配合人员 27

4.1.2 确定评估的范围 27

4.1.3 获得应用系统组件的清单 28

4.1.4 业务系统介绍会和相关文档 28

4.1.5 建立数据流程图和威胁模型 28

4.1.6 签署应用系统安全评估申请 29

5 常见应用系统的架构 29

5.1 C/S架构 29

5.2 N-tier架构 29

5.3 应用系统架构和安全性的关系 30

6 通用应用系统的评估 30

6.1 认证和鉴别 30

6.1.1 是否启用了PKI 31

6.1.2 是否启用了组织统一要求的PKI 31

6.1.3 是否识别错误的证书 31

6.1.4 认证进程是否适当 31

6.1.5 是否支持客户端对服务器的认证 32

6.2 用户帐户管理 32

6.2.1 用户ID不唯一 32

6.2.2 不活动用户是否禁用 32

6.2.3 不必要的内置用户是否禁用 32

6.2.4 用户ID是否有默认的或者弱口令 32

6.3 数据保护 33

6.3.1 敏感数据不适当地存储 33

6.3.2 敏感数据传输中没有适当的保护 33

6.3.3 使用未经验证的加密算法 34

6.4 审核 34

6.4.1 没有适当纪录安全相关的事件 34

6.4.2 日志将满没有警告 34

6.4.3 日志存在未授权删除、修改、泄露等漏洞 34

6.5 应用操作 35

6.5.1 基于角色的访问控制没有加强责任分离 35

6.5.2 应用在执行操作之前没有进行授权 35

6.5.3 进程运行的权限过高 35

6.5.4 应用没有对session的限制 35

6.5.5 应用修改在应用的范围之外的文件 36

6.5.6 用户绕过用户界面直接修改资源 36

6.6 生产环境下应用配置 36

6.6.1 应用和支持库中包含从未激活的代码 36

6.6.2 应用代码和数据在相同的目录中 36

6.6.3 安装源代码保存在服务器中 36

6.6.4 应用的环境中同时使用了不必要的软件或者服务 36

6.7 影响控制 37

6.7.1 网络架构不适当 37

6.7.2 没有灾难恢复计划 37

6.7.3 备份或者备份程序不完备 37

6.7.4 没有确保应用日志可以长时间保存的流程 37

6.7.5 敏感数据未经修改地直接导入测试环境 37

6.8 应用配置和授权 37

6.8.1 应用未恰当设置Banner信息 37

6.8.2 会话结束后应用在客户端保存认证凭证 37

6.8.3 普通用户可以执行超级用户权限 38

6.8.4 应用没有明显的logout的办法 38

6.8.5 认证凭证或者敏感数据在代码中保存 38

6.8.6 应用代码包含无效的网络资源引用 38

6.9 基于代码的因素 38

6.9.1 应用的进程在终止前没有从内存或者磁盘中删除临时对象 38

6.9.2 应用没有充分验证用户输入 39

6.9.3 应用直接暴露出错信息 39

6.9.4 应用失败能够导致不安全的状态 39

7 基于WEB应用系统的评估 39

7.1 认证机制 40

7.1.1 验证代码可下载 40

7.1.2 HTTP认证 40

7.1.3 表单认证 40

7.2 授权 41

7.2.1 攻击种类 41

7.2.2 角色矩阵 41

7.2.3 常见攻击手段 42

7.3 会话状态管理 42

7.3.1 URL直接绕过 42

7.3.2 hidden字段 42

7.3.3 HTTPReferer头标 43

7.3.4 Cookie或者sessionID 43

7.4 输入验证 43

7.4.1 输入验证攻击的种类 43

7.4.2 缓冲区溢出攻击 44

7.4.3 shellinjection攻击 44

7.4.4 文件上传漏洞 44

7.4.5 数值边界校验 44

7.5 客户端验证 44

7.5.1 脚本验证 44

7.5.2 hidden字段 45

7.5.3 HTTP头标 45

7.6 SQLinjection测试 45

7.6.1 测试前准备 45

7.6.2 系统是否进行了基本的过滤 45

7.6.3 常用的其他测试方法 46

7.7 跨站脚本测试 46

7.7.1 跨站脚本攻击多发点 47

7.7.2 测试方法 47

7.8 其他问题 47

7.8.1 源代码在站点中可以下载 47

7.8.2 站点目录可以浏览 47

7.8.3 源代码泄漏 47

7.8.4 ODBC连接问题 48

7.8.5 错误消息泄漏 48

7.8.6 同时开放其他服务 48

附录参考文献 48

1概述

本文是一个“业务系统”安全评估指南，但其主要关注“应用系统”安全评估（ApplicationSecurityReadinessReview）的过程，是在DISA（DefenseInformationSystemsAgency）的ApplicationSecurityChecklist基础上，增加或者修改了部分内容形成的。

关于“业务系统”安全评估和“应用系统”安全评估之间的关系，将在本文第1.1节进行澄清。

1.1评估的范围与概念澄清

1.1.1业务系统评估

业务系统安全评估应该包含业务系统的所有服务器端组件、以及需要安装或者配置的客户端组件，包含但不限于以下部分：

一个全面的业务系统安全评估，应该包含该业务相关的以上各个方面。

1.1.2应用系统评估

一般在评估项目中，会同时进行网络架构安全性评估、主机系统安全性评估、安全策略评估等；

在这样的情况下，对业务系统的评估，就不必再进行这些部分的评估，侧重于“应用代码或程序”评估即可。

所以本文对业务系统安全性评估的论述，侧重于对应用系统安全性评估。

1.2评估手段

在应用系统安全评估中，应该综合采取以下方式，进行全面的应用系统安全评估：

l应用系统文档审核；

u包括应用系统开发、维护文档等，尤其关注其中的和安全性相关的部分；

l顾问访谈；

u询问应用系统开发者、系统管理员、普通用户等；

u一般若用户回答否，则结果为否；

若回答是，则应尽可能实际上机验证；

l系统配置状况检查；

u实际登陆系统，检查其安全状况；

l源代码审核；

u可以针对具体的checklist检查项，在应用系统开发者的配合下，查看相关的源代码实现方式；

l渗透测试；

u可以部分采取渗透测试的方式，来检验系统的安全性，比如SQLinjection攻击、跨站脚本测试、口令的暴力破解等；

usniffer也是一个好工具；

在实际评估工作中，以上有些方式可能无法实现，比如源代码审核、配置文件检查等；

这时候可以考虑通过其他方式来进行验证其现状，比如渗透测试。

1.3评估实施环境

在应用系统安全评估工作中，评估环境一般可以分为测试环境和生产环境。

有些评估工作只能在测试环境下面做，否则会对生产有影响，比如缓冲区溢出测试、脚本注入测试等等，不然有可能影响生产系统的正常运行。

前提是测试环境下的代码要和生产环境下一致。

有些测试要在生产环境下面做，因为有些情况下，具体的配置会产生巨大的影响。

2软件工程模型对安全评估的借鉴

2.1软件工程对信息安全评估工作的借鉴意义

在计算机发展史上，在六七十年代，由于“软件危机”的产生，导致了软件工程科学的发展。

在信息安全评估工作中，应该分析、借鉴软件工程的相关思想和模型，来提高信息安全评估工作的质量，原因如下：

l软件发展史上曾经遭遇从个体劳动、作坊劳动向大规模协作劳动的瓶颈，信息安全评估工作可以借鉴软件工程中克服该瓶颈的思想；

l分析软件工程中的过程和思想，有助于理解改善软件开发过程中安全水平；

2.2以业务为核心的全面风险评估

对用户要求没有准确完整的认识，就匆忙着手编写程序是许多软件开发失败的主要原因之一。

同样，对于信息安全评估工作，对于用户要求、用户现状的全面调查和分析，也是决定信息安全评估工作成败的重要原因。

在软件开发过程中，代码编写所占的比例应该相对较小，而前期调研、系统设计应该花较多精力。

同样，在信息安全评估工作中，应该有大量的时间是花在前期调研上。

用户业务，应该是一切安全评估的基础。

2.3组织结构与功能

2.3.1组织结构图

在软件工程的开发前期，需要调研企业的组织架构图，比如：

2.3.2组织/业务关系图

在软件工程的调研、设计阶段，也需要调研企业的组织架构和业务关系，比如：

2.3.3业务功能表

对于企业的应用系统，一般在开发过程中会有相应的业务功能表，比如：

2.3.4组织结构与功能分析对安全评估的借鉴

在应用系统安全评估工作中，应该获得以上组织结构图、组织/业务关系图、业务功能表，以获得对用户现状的全面认识。

2.4业务流程分析

2.4.1软件工程中的业务流程分析

在软件工程中，业务流程分析有助于了解某项业务的具体处理过程，发现和处理系统调查工作中的错误和疏漏，修改和删除原系统的不合理部分，在新系统基础上优化业务处理流程。

业务流程图（TransactionFlowDiagram,简称TFD）就是用一些尽可能少的规定的符号及连线来表示某个具体业务处理过程。

业务流程图易于阅读和理解，是分析业务流程的重要步骤。

2.4.2安氏现有的业务流程评估

安氏现有的或者以前的业务系统流程分析，从部分售前文