业务系统(暨应用系统)安全评估指南.doc

密 级:秘密文档编号:项目代号:业务系统（暨应用系统）安全评估指南Ver 0.4二零零五年二月安氏互联网安全系统（中国）有限公司版本控制版本日期参与人员更新说明0.42005-2-11崔天强文档框架开始建立分发控制编号读者文档权限与文档的主要关系1编写，修改文档作者2读取目 录1概述71.1评估的范围与概念澄清71。1。1业务系统评估71。1。2应用系统评估81。2评估手段91。3评估实施环境102软件工程模型对安全评估的借鉴102。1软件工程对信息安全评估工作的借鉴意义102.2以业务为核心的全面风险评估102。3组织结构与功能112。3。1组织结构图112。3.2组织/业务关系图122.3。3业务功能表132.3。4组织结构与功能分析对安全评估的借鉴132。4业务流程分析132。4.1软件工程中的业务流程分析132。4。2安氏现有的业务流程评估142。4.3业务流程分析对安全评估的借鉴152.5数据流程分析172。5.1软件工程中的数据流程分析172。5。2数据流程分析对安全评估的借鉴192。6威胁模型233应用系统的安全开发过程243.1教育243。2设计阶段243.2。1面试时进行安全性考核243.2。2设定产品的安全目标253.2.3建立威胁模型253。2。4设置Bug阀值253.2。5安全小组检查253。3开发阶段263。3.1定义安全的编码准则263。3。2审查旧的安全问题263。3.3外部安全审查263.3.4安全推动活动263。4测试阶段263。5发行和维护阶段273。5。1响应过程274评估前的准备274。1.1确定用户配合人员274.1。2确定评估的范围274。1.3获得应用系统组件的清单284。1.4业务系统介绍会和相关文档284.1。5建立数据流程图和威胁模型284.1.6签署应用系统安全评估申请295常见应用系统的架构295。1C/S架构295.2N-tier架构295.3应用系统架构和安全性的关系306通用应用系统的评估306.1认证和鉴别306。1.1是否启用了PKI316。1。2是否启用了组织统一要求的PKI316。1.3是否识别错误的证书316。1.4认证进程是否适当316.1。5是否支持客户端对服务器的认证326。2用户帐户管理326。2。1用户ID不唯一326。2。2不活动用户是否禁用326。2。3不必要的内置用户是否禁用326。2。4用户ID是否有默认的或者弱口令326.3数据保护336.3.1敏感数据不适当地存储336.3.2敏感数据传输中没有适当的保护336.3.3使用未经验证的加密算法346.4审核346。4.1没有适当纪录安全相关的事件346.4.2日志将满没有警告346.4.3日志存在未授权删除、修改、泄露等漏洞346.5应用操作356.5。1基于角色的访问控制没有加强责任分离356.5。2应用在执行操作之前没有进行授权356.5。3进程运行的权限过高356。5.4应用没有对session的限制356。5.5应用修改在应用的范围之外的文件366.5。6用户绕过用户界面直接修改资源366.6生产环境下应用配置366。6。1应用和支持库中包含从未激活的代码366.6。2应用代码和数据在相同的目录中366。6。3安装源代码保存在服务器中366.6.4应用的环境中同时使用了不必要的软件或者服务366.7影响控制376。7.1网络架构不适当376.7.2没有灾难恢复计划376.7。3备份或者备份程序不完备376。7。4没有确保应用日志可以长时间保存的流程376。7.5敏感数据未经修改地直接导入测试环境376。8应用配置和授权376。8.1应用未恰当设置Banner信息376。8.2会话结束后应用在客户端保存认证凭证376.8.3普通用户可以执行超级用户权限386.8。4应用没有明显的logout的办法386。8。5认证凭证或者敏感数据在代码中保存386.8.6应用代码包含无效的网络资源引用386。9基于代码的因素386.9。1应用的进程在终止前没有从内存或者磁盘中删除临时对象386。9。2应用没有充分验证用户输入396。9。3应用直接暴露出错信息396。9.4应用失败能够导致不安全的状态397基于WEB应用系统的评估397。1认证机制407。1。1验证代码可下载407。1。2HTTP认证407。1.3表单认证407。2授权417.2。1攻击种类417。2.2角色矩阵417。2.3常见攻击手段427。3会话状态管理427.3。1URL直接绕过427。3.2hidden字段427.3。3HTTP Referer头标437.3。4Cookie或者session ID437。4输入验证437.4。1输入验证攻击的种类437。4。2缓冲区溢出攻击447。4。3shell injection攻击447.4。4文件上传漏洞447.4。5数值边界校验447.5客户端验证447.5。1脚本验证447.5。2hidden字段457。5.3HTTP头标457。6SQL injection测试457.6。1测试前准备457.6。2系统是否进行了基本的过滤457。6。3常用的其他测试方法467。7跨站脚本测试467。7。1跨站脚本攻击多发点477。7。2测试方法477。8其他问题477。8.1源代码在站点中可以下载477。8.2站点目录可以浏览477.8.3源代码泄漏477.8。4ODBC连接问题487。8.5错误消息泄漏487.8。6同时开放其他服务48附录 参考文献481 概述本文是一个“业务系统”安全评估指南,但其主要关注“应用系统”安全评估（Application Security Readiness Review）的过程,是在DISA（Defense Information Systems Agency）的Application Security Checklist基础上,增加或者修改了部分内容形成的。关于“业务系统”安全评估和“应用系统”安全评估之间的关系，将在本文第1。1节进行澄清。1.1 评估的范围与概念澄清1.1.1 业务系统评估业务系统安全评估应该包含业务系统的所有服务器端组件、以及需要安装或者配置的客户端组件,包含但不限于以下部分:一个全面的业务系统安全评估，应该包含该业务相关的以上各个方面.1.1.2 应用系统评估一般在评估项目中，会同时进行网络架构安全性评估、主机系统安全性评估、安全策略评估等;在这样的情况下，对业务系统的评估，就不必再进行这些部分的评估，侧重于“应用代码或程序”评估即可。所以本文对业务系统安全性评估的论述，侧重于对应用系统安全性评估。1.2 评估手段在应用系统安全评估中,应该综合采取以下方式，进行全面的应用系统安全评估：l 应用系统文档审核；u 包括应用系统开发、维护文档等，尤其关注其中的和安全性相关的部分;l 顾问访谈;u 询问应用系统开发者、系统管理员、普通用户等；u 一般若用户回答否,则结果为否；若回答是，则应尽可能实际上机验证；l 系统配置状况检查;u 实际登陆系统，检查其安全状况;l 源代码审核；u 可以针对具体的checklist检查项，在应用系统开发者的配合下，查看相关的源代码实现方式;l 渗透测试；u 可以部分采取渗透测试的方式，来检验系统的安全性，比如SQL injection攻击、跨站脚本测试、口令的暴力破解等;u sniffer也是一个好工具；在实际评估工作中，以上有些方式可能无法实现,比如源代码审核、配置文件检查等；这时候可以考虑通过其他方式来进行验证其现状，比如渗透测试。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 软件工程中的业务流程分析在软件工程中,业务流程分析有助于了解某项业务的具体处理过程，发现和处理系统调查工作中的错误和疏漏,修改和删除原系统的不合理部分,在新系统基础上优化业务处理流程.业务流程图（Transaction Flow Diagram ,简称 TFD ）就是用一些尽可能少的规定的符号及连线来表示某个具体业务处理过程.业务流程图易于阅读和理解，是分析业务流程的重要步骤.2.4.2 安氏现有的业务流程评估安氏现有的或者以前的业务系统流程分析，从部分售前文档中看，侧重于以下方面:1、详细的业务流程2、业务相关性分析是因为用户的维护部门的岗位职责设置通常是根据业务来设置的，用户关心业务系统和业务系统之间的、业务系统各组件（部分）间的安全问题,包括数据交换、权限、包括业务管理上安全要注意的问题等。3、数据流和数据存储方式4、业务流程和拓扑结构的关系2.4.3 业务流程分析对安全评估的借鉴2.4.3.1 从软件工程中的业务流程分析中借鉴可以看到,在软件工程中的业务流程分析，是准确意义上的业务流程分析.它描述的是纯粹的业务处理过程,是要在应用系统中实现的东西,和计算机系统本身没有直接关系。业务流程分析，对于用户业务的安全性，也有着重要的意义.最明显的例子,比如在银行存取款业务中,只有流程合理才能有效保证资金的安全.在银行存取款业务中，有部分流程可能在应用系统中实现了；而有部分流程未在应用系统中实现。对银行业务安全角度而言，可能这两部分都很重要。比如,银行用户是否会考虑委托专业的会计咨询顾问来做这个工作?在毕马威的ppt中看到，它们宣称有银行业务流程分析这个业务。本文建议我们的业务流程评估，只考虑“在应用系统中实现的部分流程”,即和计算机相关的部分,而不考虑“未在应用系统中实现的部分流程.因此，在安全评估过程中，有必要对用户应用系统开发过程中产生的业务流程图等业务流程分析结果进行再分析，有以下益处：l 分析用户业务流程中是否存在逻辑上的安全弱点；l 有助于了解用户业务流程，为建立应用系统相关的威胁模型打下良好基础；2.4.3.2 从安氏现有的业务流程评估借鉴分析售前文档中提到的安氏现有的业务流程评估,可以从两个方面看：l 一方面，这个“业务流程评估并非是准确意义上的业务流程分析；它涉及到应用系统架构、数据流程、网络拓扑结构、甚至应用系统开发等等各个方面.l 另一方面，这个“业务流程评估”较多关注用户的实际需求，应该充分借鉴.安氏现有的业务流程评估中,所提到的某些需要关注的问题,比如对数据流、数据存储等因素的考虑，可以在数据流程分析、应用系统安全评估中实现。除此之外，安氏现有的业务流程评估基本可以使用如下的业务系统结构图来表述：该结构图对于业务流程和网络拓扑的相关性分析、数据流程分析、应用系统架构分析都有所帮助。建议在这个业务系统结构图中,要充分表述以下方面：l 应用系统架构；l 和其他业务系统的访问关系，需要具体到端口号;l 外部访问用户的位置;l 业务功能的实体实现；可以看到,这个业务系统结构图中,包含了应用系统架构图。2.5 数据流程分析2.5.1 软件工程中的数据流程分析数据流程分析是把数据在组织（或原系统)内部的流动情况抽象地独立出来,舍去了具体组织机构、信息载体、处理工作、物资、材料等,单从数据流动过程来考查实际业务的数据处理模式.主要包括对信息的流动、传递、处理、存储等的分析.数据流程分析的目的是要发现和解决数据流通中的问题，如：数据流程不畅、前后数据不匹配、数据处理过程不合理等等。数据流程分析可以通过采用分层的数据流程图（Data Flow Diagram ， 简称 DFD ）来简单表示。把待解决的问题当作一个整体系统,找出其输入、输出和处理（即:外部项、处理功能、存储数据、数据流向），不考虑其中细节部分，画出第一层数据流图。遵循由上至下、逐步求精的原则，根据业务范围和处理功能,在第一层数据流图的处理框中进一步细划，找出其内部的业务处理关系和数据传输关系，画出第二层数据流图。根据问题的复杂程度按照上述方法逐步分层,直到所需表达的数据都显露出来。如图所示，是一个分层的数据流程图：以下以一个汽车配件厂为例，分析其数据流程图。第一层数据流层图,表述了其和外部实体之间的数据流关系。第二层、第三层数据流程图,对汽车配件厂内部的数据流程，进行了更细致的表述。2.5.2 数据流程分析对安全评估的借鉴在业务系统安全评估过程中，可以通过对数据流程的分析，发现数据流在产生、传输、存储、处理、输出等过程中所经过的各个环节所可能存在的安全隐患.这种安全隐患,可能是应用系统设计上的问题,也可能是业务系统部署上的问题.一方面，在评估中，软件工程中的数据流程分析及其数据流程图，是一个非常重要、高效的信息来源，应该细致分析。另一方面，软件工程中的数据流程分析及其数据流程图，不能很好满足为安全评估目的的数据流程分析.它比较注重于软件各组件之间的逻辑关系,而安全评估中的数据流程分析,不仅仅要关注各组件之间的逻辑关系，也要关注实现各组件功能的实体.根据评估对象和目的的不同,所绘制的数据流程图可能有所不同。这里，建议可以考虑以下三种粒度的数据流程图：l 网络架构评估之数据流程图；l 业务系统评估之数据流程图;l 应用系统评估之数据流程图;2.5.2.1 网络架构评估之数据流程图在网络架构安全性评估中，尤其是在大型网络中，网络架构是否合理、网络架构该如何调整、如何实施访问控制，都和网络中的数据流程密切相关,可以考虑采用数据流程图的方式来作为网络架构评估的参考依据。下表是某广域网的数据流分析：可以看到，由于目前该网络上跨全网的应用系统较少，除DNS、电子邮件、WWW等基本网络应用外，只有办公自动化系统、财务系统等几个应用系统运行,所以广域网(城域网）上的流量较少，流向主要是全国中心与各省公司的双向传送，各省公司之间数据传输很少.流量较大的是本部局域网及对Internet的访问。也可以参照软件工程中分层次数据流程图的方式，以分层次的方式,来表述不同层次安全域中数据流程,比如,在第一级安全域中：在第二级安全域中：在第三级安全域中：调查各业务系统之间的数据流所用表格如图所示：在这样的网络架构评估中的数据流程图，一般具体到“业务系统、“终端”这样的较小的“网段单位即可满足需求。在这样的评估中，要特别关注外部网络边界、不同维护单位之间网络边界的数据流向，一般这是用户关注的重点。、2.5.2.2 业务系统评估之数据流程图业务系统评估所使用的数据流程图,可以使用软件工程中的数据流程图.这应该是目前我们在安全评估工作中的重点。2.5.2.3 应用系统评估之数据流程图在应用系统评估中,尤其是接近于源代码审核的层次，需要使用更细致的数据流程图，包括环境变量、配置数据等。2.6 威胁模型在建立了业务流程图、应用结构图、数据流程图以后，可以建立应用系统安全威胁模型，以对应用系统进行全面的、系统的安全性评估分析。3 应用系统的安全开发过程本章介绍一个软件开发生命周期模型中在安全方面增加责任制和结构性的方法,以供评估用户应用系统开发过程中对安全性的考虑作为参考。3.1 教育开发团队应该不断进行安全培训，提高安全意识和安全技能，安全应该是开发团队技术基础的一部分。由于新技术、新的安全威胁不断出现，安全教育也必须不断更新.3.2 设计阶段3.2.1 面试时进行安全性考核开发团队在面试的时候应该进行部分安全问题的考核,确定面试人选的安全技术基础。可以优先考虑雇佣具有技术思维倾向的人，他们能够发现不良的设计，了解如何修复它们,并指出如何在设计阶段就解决这些问题.3.2.2 设定产品的安全目标在产品的设计阶段，开发团队应该在需求分析中,综合考虑产品的安全需求,设定产品的安全目标，在需求分析中详细说明。3.2.3 建立威胁模型开发团队应该分解应用程序,绘制完整的数据流程图,确定系统面临的各种安全威胁,并形成相应的解决方案.3.2.4 设置Bug阀值应用程序很难做到完全杜绝Bug,所以应该设立一个较高标准的Bug阀值，只有达到这个阀值才能达到验收标准.3.2.5 安全小组检查在软件工程中，项目成功的重要因素之一在于坚持阶段性评审和复审。在开发过程中，对安全工作，也要坚持进行安全小组检查.3.3 开发阶段3.3.1 定义安全的编码准则开发团队应该定义最基本的安全编码准则，包括如何处理缓冲区、如何对待不可靠的数据、如何加密数据等.3.3.2 审查旧的安全问题开发团队在开发过程中,应该不断从过去的错误中吸取教训，防止发生同样的问题.3.3.3 外部安全审查开发团队在开发过程中，可以考虑雇佣专门的外部安全顾问公司来审查代码和计划。3.3.4 安全推动活动开发团队应该定期进行安全推广活动，以提高安全意识、去除编写程序中的坏习惯等.3.4 测试阶段在产品的测试阶段，除了对产品功能的测试以外，应该包含对安全性的测试。对于安全性的测试中，不仅仅要对已经设定的安全功能目标进行测试，也要尝试以一个攻击者的各种方式和角度进行攻击测试,确保产品在系统设计和编码上都能够承受攻击。3.5 发行和维护阶段3.5.1 响应过程在产品运行以后，有可能不断发现系统的安全缺陷。需要建立适当的响应策略和机制.一旦发现缺陷，就通过标准的修复机制，确定缺陷的严重程度，可以修复到何种程度，以及如何发行修复后的版本。4 评估前的准备为保证在用户评估现场的工作效率,有些工作应该在到达用户现场前就准备好,包括以下内容：4.1.1 确定用户配合人员和用户确定能够配合评估工作的人员，需要具有以下能力:l 了解应用系统，能够有效回答评估者的询问;l 能够提供对源代码的访问，并协助分析源代码；l 能够提供应用系统相关的开发、维护文档；l 能够提供超级用户权限的访问界面；l 能够提供普通用户权限的访问界面；l 最终确定的配合人员，一般包括:程序经理、应用开发人员、系统管理员、普通用户、或者其他有足够的知识和权限能够配合评估工作的人员。4.1.2 确定评估的范围和用户确定本次应用系统评估的范围，包括哪些应用、哪些软件、哪些方面等。如前文所述,如果以前在其他工作中进行了主机系统、网络架构等评估，那么这部分工作可以不再进行，但是在最终报告中要涵盖所有的内容。4.1.3 获得应用系统组件的清单获得应用系统架构范围内的所有组件清单，包括网络拓扑图、IP地址信息、OS版本、数据库或者Web版本、第三方中间件版本、库文件或者其他组件等。4.1.4 业务系统介绍会和相关文档可以考虑召开应用系统介绍会，由开发人员、系统管理员介绍应用系统的基本情况，包括应用系统的基本功能、组件架构、部署情况、使用对象、安全设计思想、业务流程等：组织结构图组织/业务关系表业务功能表业务流程图数据流程图业务系统结构图(应用系统架构图）角色/权限矩阵表也应尽可能获得应用系统相关的开发文档、维护文档，比如：开发任务书需求说明书概要设计文档用户界面设计文档用户手册验收报告测试报告源代码4.1.5 建立数据流程图和威胁模型数据流程图一般根据目的的不同，有三种粒度:网络架构评估之数据流程图业务系统评估之数据流程图业务系统评估之数据流程图4.1.6 签署应用系统安全评估申请在应用系统安全评估实施之前，应该向用户提交并签署应用系统安全评估申请,以确保用户认可以下问题:l 接受评估的范围;l 接受评估过程中可能带来的操作风险;l 对物理、逻辑访问用户应用系统的授权;5 常见应用系统的架构本部分介绍主要的应用系统架构，以及其对于安全性的影响。5.1 C/S架构在较早的网络应用系统中，一般采用Client/Server结构，需要在客户端安装客户端程序，直接访问Server。5.2 Ntier架构随着Web应用的发展,越来越多的应用系统采用B/S结构，并象Ntier结构发展.5.3 应用系统架构和安全性的关系C/S架构中，客户端直接访问数据库，有暴露数据库服务器的弱点.而在Ntier架构中，对数据库的访问可以集中在中间层，中间件向用户屏蔽了数据库服务器.此时可以在网络层限制,只有中间件服务器才能访问数据库服务器,大大提高了安全性.6 通用应用系统的评估本部分主要介绍通用应用系统（General Application system）的评估。6.1 认证和鉴别这部分主要测试用户或者进程如何进行身份认证。首先应该识别出应用系统中所有涉及认证和鉴别的行为，然后对它们逐个进行测试。本文主要介绍基于PKI的认证和鉴别测试,如果应用系统使用其他的认证和鉴别方式，可以比照执行。6.1.1 是否启用了PKI对于重要的系统，是否启用了PKI?如果配合人员说“否”,则纪录之。如果说“是,那么对使用了PKI的组件进行实际验证.6.1.2 是否启用了组织统一要求的PKI如果配合人员说“是”,那么进行实际验证。6.1.3 是否识别错误的证书如果系统是基于Web方式的应用,那么可以直接使用revoked、过期的、错误的证书分别尝试登陆.如果系统是非Web方式的应用,那么和配合人员协商,安装相应的客户端，并安装revoked、过期的、错误的证书分别尝试登陆。6.1.4 认证进程是否适当列出应用系统中所有客户认证进程的清单，包括application server与数据库服务器也构成client/sever关系。认证方式一般有:操作系统、数据库、目录服务、认证设备等。在认证过程中，是否存在以下问题：l 只使用用户名，不需要口令；l 是否有口令复杂性的策略要求；l 是否有帐户锁定的策略；l 用户口令不能更改；以上问题，可以通过查看配置文件、手工测试等方式来验证。6.1.5 是否支持客户端对服务器的认证进行测试。有些认证过程不是用户端触发的，比如后台设备之间的认证。那么可以查看配置文件，或者使用sniffer分析。6.2 用户帐户管理这部分主要检查保存的用户帐户可能存在的安全弱点。首先识别应用系统中用户ID保存在哪里。有些应用系统的用户ID可能保存在多个地方.如果应用系统使用操作系统、数据库的内置帐户，那么这部分应该在主机或者数据库安全性评估中已经进行，这里可以标记为NA。6.2.1 用户ID不唯一把用户按ID排序，检查是否存在ID重复的情况。把用户按姓名排序,检查是否存在一个姓名多ID的情况.6.2.2 不活动用户是否禁用超过90天没有登陆的用户,是否禁用？6.2.3 不必要的内置用户是否禁用如果common commercial off-theshelf （COTS）的软件，使用的内置用户,在其他评估中，已经进行了评估，那么这部分可以忽略。需要注意这些不必要的内置用户是否必要？尤其当它们是超级用户的时候。6.2.4 用户ID是否有默认的或者弱口令应该尝试应用系统广为人知的默认口令。或者使用brute force进行弱口令暴力破解。6.3 数据保护本部分主要检查数据在存贮、传输过程中的安全性，主要是读写权限、加密算法的问题。这部分依赖于数据流程图。6.3.1 敏感数据不适当地存储敏感数据需要有适当的权限保护，只有管理员、应用或者操作系统进程有权限进行读写。对于帐户数据库的本地备份，也应该检查其权限设置。其他用户对敏感数据、尤其是用户帐户数据文件的读或者写,都是危险的.可以参考passwdshadow的权限设置。口令需要被加密，可以查看配置文件是否启用了加密功能。如果认证数据是可读的，看看它是否明文，或者脆弱的加密方式。也可以审核源代码，检查对加密函数的过程调用，启用了什么样的加密功能.如果应用系统中使用key进行认证，列出server中key的清单,并抽样检查。注意key文件的权限，一般用户或者进程不应该有写的权限。识别是否有不必要的用户或者应用进程(它在用户的背后读）对keys有读的权限.对于非公开的用户数据，询问配合人员它们存储在何处,及如何保护。用户的权限不应该超过最小授权的原则。注意全局权限，或者非管理员的组权限。6.3.2 敏感数据传输中没有适当的保护数据可以分成可以分成IA和非I&A数据.所有的I&A数据在存储、传输过程中必须进行加密。检查系统是否使用telnet、ftp、basic http等协议进行明文验证。如果是,那么是否在低层次的协议中进行了加密？比如IPSEC、L2TP、PPTP或者链路层加密.如果应用和数据库在同一台机器上，那么传输过程中无需加密。对于非IA数据，也应该根据重要性、是在内网还是internet传输，来考虑其安全性。6.3.3 使用未经验证的加密算法列出应用系统中所有使用加密组件的清单，比如文件加密、VPN、SSH等.检查是否使用了未经验证的加密算法。这样的加密算法，安全性无法保证。6.4 审核6.4.1 没有适当纪录安全相关的事件至少，以下事件应该被纪录：启动和关闭；认证事件；授权用户对数据的受控访问;不成功的访问企图;删除数据；应用配置更改；授权事件要保存请求的原始信息，比如IP地址等；删写事件，应纪录删或者写的数据对象的名称；纪录机制可以和操作系统、web、database、应用结合在一起；但是，要注意是否易读的问题,不能只有开发者可读。日志的备份问题？6.4.2 日志将满没有警告检查应用文档或者询问用户是否有此功能？通过配置文件确认之.6.4.3 日志存在未授权删除、修改、泄露等漏洞检查日志文件的权限,是否存在以上问题。6.5 应用操作6.5.1 基于角色的访问控制没有加强责任分离应该考虑以下分离：l 日志管理者其他管理者；l 设置访问控制规则的人员访问数据、编写程序的人员；如果应用中实施了分开,则可能使用的安全配置界面不同，或者使用不同的账号登陆.6.5.2 应用在执行操作之前没有进行授权授权机制可能包括文件权限、数据库、应用代码等。如果是在应用代码中，让开发者locate to相关代码，细细检查.如果使用文件权限、数据库的方式，注意Everyone、 world、 public、guest等用户或者组。6.5.3 进程运行的权限过高识别应用运行使用的账户。l Windows中可以在“服务”中查看；l Unix在ps ef；l ntier结构，可能看连接数据库所使用的账户。如果使用administrator、uid=0、sa或者system等权限，都是安全隐患.搜索文件系统，看看有没有以运行进程所使用的用户为所有者的文件或者目录。若有，则它能改写这些文件了。6.5.4 应用没有对session的限制询问配合人员每个用户或者进程ID会话数目的限制；以及会话空闲的最大时间。可以检查配置文件、源代码进行验证。许多时候，配置文件、源代码可能都看不到。这些和DoS攻击有关.有时候测试会比较困难，比如idle limits太长；这也可以作为一个结果记录下来.6.5.5 应用修改在应用的范围之外的文件搜索最近一周、一天内修改过的文件.看看有没有在应用的范围之外的文件。6.5.6 用户绕过用户界面直接修改资源检查系统开放的服务、防火墙或者路由器的访问控制措施，从而确定“威胁界面”的大小.如果是Web应用，可以尝试是否存在授权机制绕过的问题.可以询问管理员是否存在直接修改数据库的问题。6.6 生产环境下应用配置6.6.1 应用和支持库中包含从未激活的代码询问是否存在删除从未执行的代码的记录在案的过程。对于web应用，应包括asp、html等。对于数据库，应该包含存储过程.对于C/S结构或者分布式的应用，应该包含VB、C等开发语言模块.或者可以直接通过文件被浏览的时间来发现这个问题。6.6.2 应用代码和数据在相同的目录中它们不应该相同的目录中。6.6.3 安装源代码保存在服务器中这很危险，有可能被攻击者下载。6.6.4 应用的环境中同时使用了不必要的软件或者服务应该专机专用。6.7 影响控制6.7.1 网络架构不适当应该通过DMZ、内部访问控制等措施，减小应用中一台服务器被攻击对其他系统的影响。6.7.2 没有灾难恢复计划如果该应用是整个灾难恢复计划中的一部分，确保计划中包含详细的指导。6.7.3 备份或者备份程序不完备确保对应用数据、底层OS和应用组件都进行了备份。6.7.4 没有确保应用日志可以长时间保存的流程建议保存至少半年以上。6.7.5 敏感数据未经修改地直接导入测试环境6.8 应用配置和授权6.8.1 应用未恰当设置Banner信息6.8.2 会话结束后应用在客户端保存认证凭证可以搜索文件系统查找最新的文件。比如使用cookie作为凭证。检查cookie中是否包含用户名或者口令等敏感信息.其他的手段保存用户信息，也要注意。6.8.3 普通用户可以执行超级用户权限使用普通用户登陆，看看用户界面(图形的、web或者命令行）是否包含超级用户功能,比如:创建、删除用户帐号或者组；配置帐户锁定策略;更改其他用户的口令或者证书；设定应用如何应对错误请求；6.8.4 应用没有明显的logout的办法即使有,不明确或者不好找，也是一个问题。6.8.5 认证凭证或者敏感数据在代码中保存审核源代码(包括global.asa)、脚本（注意数据库的备份角本）、HTML表单等，检查包含口令、证书、敏感数据的代码。如果找到了，注意文件的权限。即使编译在可执行文件中也不安全.6.8.6 应用代码包含无效的网络资源引用6.9 基于代码的因素这部分检查都需要审视应用代码，并且最好在测试系统上进行验证.6.9.1 应用的进程在终止前没有从内存或者磁盘中删除临时对象应该从内存中释放临时对象，也应该保证数据库的连接被关闭。可以进入程序进行选定的动作，然后退出,搜索最新创建的文件.在windows下，可以使用搜索.在unix下:# touch t 200301211020 /tmp/testdatefile# find / newer /tmp/testdatefile6.9.2 应用没有充分验证用户输入询问配合人员应用的测试计划。检查测试计划中包含对无效输入的检查，包括脚本标签、查询字串、SQL命令、无效的数据类型和大小等。可以进行查询字串伪造、脚本嵌入、SQL injection、无效的输入大小或者类型等等攻击。划中是否包含了对缓冲区溢出的测试.可以输入大量的数据进行测试:l 在数字字段输入非常巨大的数字;l 正数、负数测试；l 对文本字段进行超过1M数据的输入;l 对于web的查询字符串，至少输入500个字符；如果出错，说明没有进行边界检查。6.9.3 应用直接暴露出错信息应用应该有出错处理进程，不能仅仅依赖内部系统的错误处理功能.如果应用不处理错误,而仅仅被底层系统处理,这是一个问题。尤其是，错误信息中不能包含变量名、变量类型、SQL字串、或者源代码等。这会导致进一步的攻击.6.9.4 应用失败能够导致不安全的状态检查测试计划中是否包含了对应用失效的测试。7 基于Web应用系统的评估本部分主要介绍基于Web的应用系统的评估，它仍然遵从第6章“通用应用系统评估的要求，但是有Web应用系统的一些特点.本部分主要针对这些特点进行评估.7.1 认证机制认证机置是Web应用安全的第一步。一般会要求登陆用户输入用户名和口令等。7.1.1 验证代码可下载个别比较简单的Web应用程序使用的身份验证机制,会把验证代码、甚至用户名和口令直接下载到客户端执行。包括Java Applet、可下载的Java Class，或者其他下载到本地执行的验证代码，比如exe文件、flash文件等。这样的验证机制，都很容易被攻击者在本地进行破解.