应用系统开发安全管理通则030326v3fd.docx

应用系统开发安全管理通则030326v3fd编号:PetrOChina中国石油天然气股份有限公司应用系统开发安全管理通则G比阅稿）BearinsPointfr7豪名单马威咨»牛将版本号：V3批阅人：王巍中国石油天然股份有F艮公司随着中国石油天然气股份有限公司（下列简称“中国石油”）信息化建设的稳步推进，信息安全日益受到中国石油的广泛关注，加强信息安全的管理与制度无疑成为信息化建设得以顺利实施的重要保障。中国石油需要建立统一的信息安全管理政策与标准，并在集团内统一推广、实施。本规范是根据中国石油信息安全的现状，参照国际、国内与行业有关技术标准及规范，结合中国石油自身的应用特点，制定的适合于中国石油信息安全的标准与规范。目标在于通过在中国石油范围内建立信息安全有关标准与规范，提高中国石油信息安全的技术与管理能力。信息技术安全总体框架如下：物理环境 安全谛用(f¾J应用系统安金谛理网络安仝管理概述os,一 (e<l W 全丐 一 s* - 外郃MlI安至管理督J内郡冏I安宅管理- 如lJ通用网络安全l理一 规范电子晶安全W叠成胃蜃用安全 *iamEJK晶专卷电IHI委全«S1）整体信息技术安全架构从逻辑上共分为7个部分，分别为：物理环境、硬件设备、网络、操作系统、数据与文档、应用系统与通用安全管理标准。图中带阴影的方框中带书名号的为单独成册的部分，共有13本规范与1本通用标准。2）关于13个规范中具有一定共性的内容我们整理出了7个标准横向贯穿整个架构，这7个标准的组合也根据了信息安全生命周期的理论模型。每个标准都会对所有的规范中有关涉及到的内容产生指导作用，但每个标准应用在不一致的规范中又会有相应不一致的具体的内容。我们在行文上将这7个标准组合成一本通用安全管理标准单独成册。3）全文以信息安全生命周期的方法论作为基本指导，规范与标准的内容基本都根据预防保护一一检测跟踪一一响应恢复的理论基础行文。木通则讨论了在企业内部自行开发一套应用系统或者外包开发所务必考虑到的安全问题。开发应用系统的安全性考虑就好像建设楼房一样，拥有越牢固的地基楼房越是稳固，因此假如在应用系统的开发阶段打好坚实的安全基础，那么以后的日常保护工作就会很轻松。下列我们要紧从系统开发的各个阶段入手，阐述在标准的开发流程的各个阶段中所应注意的安全性考虑。本规范由中国石油天然气股份有限公司公布。本规范由中国石油天然气股份有限公司科技与信息管理部归口管懂得释。起草部门：中国石油制定信息安全政策与标准项目组。在中国石油信息安全标准中涉及下列概念：组织机构中国石油（PetroChina）指中国石油天然气股份有限公司有的时候也称“股份公司二集团公司（CNPC）指中国石油天然气集团公司有的时候也称“存续公司”。为区分中国石油的地区公司与集团公司下属单位，担提及“存续部分”时指集团公司下属的单位。如：辽河油田分公司存续部分指集团公司下属的辽河石油管理局。计算机网络中国石油信息网（PetrOChinaNet）指中国石油范围内的计算机网络系统。中国石油信息网是在中国石油天然气集团公司网络的基础上,进行扩充与提高所形成的连接中国石油所属各个单位计算机局域网与园区网。集团公司网络（CNPCNet）指集团公司所属范围内的网络。中国石油的一些地区公司是与集团公司下属的单位共用一个计算机网络，当提及“存续公司网络”时，指存续公司使用的网络部分。主干网是从中国石油总部连接到各个下属各地区公司的网络部分，包含中国石油总部局域网、各个二级局域网（或者园区网）与连接这些网络的专线远程信道。有些单位通过拨号线路连接到中国石油总部，不是利用专线，这样的单位与所使用的远程信道不属于中国石油专用网主干网构成部分。地区网地区公司网络与所属单位网络的总与。这些局域网或者园区网互相连接所使用的远程信道能够是专线，也能够是拨号线路。局域网与园区网局域网通常指，在一座建筑中利用局域网技术与设备建设的高速网络。园区网是在一个园区（比如大学校园、管理局基地等）内多座建筑内的多个局域网，利用高速信道互相连接起来所构成的网络。园区网所利用的设备、运行的网络协议、网络传输速度基本相同于局域网。局域网与园区网通常都是用户自己建设的。局域网与园区网与广域网不一致，广域网不仅覆盖范围广，所利用的设备、运行的协议、传送速率都与局域网与园区网不一致。传输信息的信道通常都是电信部门建设的。二级单位网络指地区公司下属单位的网络的总与，可能是局域网，也可能是园区网。专线与拨号线路从连通性划分的两大类网络远程信道。专线，指数字电路、帧中继、DDN与ATM等经常保持连通状态的信道；拨号线路，指只在传送信息时才建立连接的信道，如电话拨号线路或者ISDN拨号线路。这些远程信道可能用来连接不一致地区的局域网或者园区网，也可能川于连接单台计算机。石油专网与公网石油专业电信网与公共电信网的简称。最后一公里问题建设广域网时，用户局域网或者园区网连接邻近电信部门信道的最后一段距离的连接问题。这段距离通常小于一公里，但也有大于一公里的情况。为简便，同称之最后一公里问题。涉及计算机网络的术语与定义请参见中国石油局域网标准。1 概述72 目标73 适用范围74 规范引用的文件或者标准85 术语与定义96 应用系统开发总体原则117 系统需求收集与分析阶段127.1 可行性研究分析127.2 开发人员安全管理147.3 建立系统开发安全需求分析报告158 系统设计阶段的安全规范178.1 单点访问操纵且无后门178.2 人员职责与权限的定义178.3 确保敏感系统的安全性178.4 确保访问层的安全性178.5 确保日志管理机制健全188.6 新系统的容量规划189 系统开发阶段安全规范199.1 系统开发语言199.2 系统开发安全有关工具管理规范279.3 操纵软件代码程序库299.4 在软件开发过程变更管理319.5 开发版本管理329.6 开发日志审核管理349.7 防御后门代码或者隐藏通道3410 系统测试阶段安全规范3610.1 应用系统的安全性检测3610.2 操纵测试环境3810.3 为测试使用真实的数据3910.4 在软件转移至生产环境前进行测试3910.5 应用系统安全质量鉴定39H系统培训及文档阶段安全规范4011.1 新系统的培训4011.2 撰写新系统与系统改进的文档4012应用系统开发外包安全操纵41附录1参考文献42附录2本规范用词说明421 概述信息系统的许多的安全操纵或者其他安全性保证是通过系统的开发设计予以实现的。因此假如在系统的开发设计阶段没有对系统的安全性给予充分的考虑，那么系统本身一定会存在许多先天不足，系统就会漏洞百出。为确保应用系统的安全，在应用系统开发之前就应确认系统的安全需求，并以此作为开发设计的阶段的基础。本规范要紧规定了在系统开发的各个阶段所应遵守的各类安全规范，从需求分析开始，到设计，再到开发与保护与最后的文档等系统开发的各个阶段分别进行阐述，并将在不一致阶段中所需要注意的安全问题与有关的安全规范进行进一步的描述与规定。2 目标本规范的目标为：保护应用系统开发过程的安全。具体地说就是保护应用系统开发过程免受未经授权的访问与更换，保护系统开发中系统软件与信息的安全，确保开发项目顺利正确的实施并对开发环境进行严格的操纵。同时确保应用系统开发外包中的各项安全。3 适用范围本套规范适用的范围包含了整个应用系统开发过程中的安全包含了系统开发可行性与需求分析阶段的安全，系统设计阶段的安全，系统开发阶段的安全，系统测试阶段的安全，系统培训与文档阶段的安全与系统开发外包的安全规范。要紧规定了应用系统开发过程的安全保密，软件的质量的要求，系统与业务需求的符合性,保证敏感信息的安全，系统本身的稳固性与兼容性问题。4 规范引用的文件或者标准下列文件中的条款通过本标准的引用而成为本标准的条款。凡是不注日期的引用文件,其最新版本适用于本标准。1. GB17859-1999计算机信息系统安全保护等级划分准则2. GB/T9387-1995信息处理系统开放系统互连基本参考模型(ISO7498:1989)3. GA11'391-2002计算机信息系统安全等级保护管理要求4. ISO/IECTR13355信息技术安全管理指南5. NIST信息安全系列美国国家标准技术院6. 英国国家信息安全标准BS77997. 信息安全基础保护ITBaselineProtectionManual(Germany)8. BearingPointConsulting内部信息安全标准9. RUSeCUre安全技术标准10. 信息系统安全专家丛书CertificateInformationSystemsSecurityProfessional5术语与定义访问操纵accesscontrol一种安全保证手段，即信息系统的资源只能由被授权实体按授权方式进行访问，防止对资源的未授权使用。应用系统applicationsystem认证authenticationa.验证用户、设备与其他实体的身份；b.验证数据的完整性。授权authorization给予权利，包含信息资源访问权的授予。可用性availability数据或者资源的特性，被授权实体按要求能及时访问与使用数据或者资源。缓冲器溢出bufferoverflow指通过往程序的缓冲区写超出其长度的内容，造成缓冲区的溢出，从而破坏程序的堆栈，使程序转而执行其它指令，以达到攻击的目的。保密性ConfidentiaIity数据所具有的特性，即表示数据所达到的未提供或者未泄露给未授权的个人、过程或者其他实体的程度。隐藏通道covertchannel可用来按照违反安全策略的方式传送!数据的传输信道。完整性integrity在防止非授权用户修改或者使用资源与防止授权用户不正确地修改或者使用资源的情况下,信息系统中的数据与在原文档中的相同，并未遭受偶然或者恶意的修改或者破坏时所具的性质。敏感信息sensitiveinformation由权威机构确定的务必受保护的信息，由于该信息的泄露、修改、破坏或者丢失都会对人或者事产生可预知的损害。系统测试SyStemteSting用于确定系统的安全特征按设计要求实现的过程。这一过程包含现场功能测试、渗透测试与验证。后门代码trapdoor通常为测试或者查找故障而设置的一种隐藏的软件或者硬件机制，它能躲开计算机安全。而且它能在非常规时间点或者无需常规检查的情况下进入程序。特洛伊木马TrOjanhorSe一种表面无害的程序，它包含恶性逻辑程序，导致未授权地收集、伪造或者破坏数据，以此破坏计算机安全与完整性的进程。验证verification将某一活动、处理过程或者产品与相应的要求或者规范相比较。例：将某一规范与安全策略模型相比较，或者者将目标代码与源代码相比较。压力测试于确定系统的薄弱环节，确定系统在非正常条件下能够迅速恢复到正常的运行状态的能力。应用系统开发总体原则应用系统的开发应遵循一系列的总体原则，以确保开发过程中的安全。其中包含：a）系统开发应从业务需求的角度出发，不得盲目追求系统的先进性而忽略了系统的有用性。系统的开发是为了更好地满足业务上的需要，而不是技术上的需要。b）开发的方法与管理务必规范化、合理化、制度化，从而确保开发的质量与进度。c）应保证开发的进度并按时完成。确保开发工作及时、有效且高质量的完成。d）系统开发务必具有一定的前瞻性，符合主流系统的进展方向。e）提高与加强开发人员的安全意识。确保机密信息与关键技术不可能泄漏，特别是不可泄漏到竞争对手的手中，否则将会对公司的竞争力产生极大的影响。D应充分利用现有的资源。系统需求收集与分析阶段1.1 可行性研究分析关于应用系统开发项目应进行一定的可行性分析，以保证只有在确认具备了相当的资源与条件，同时有能力满足业务上的需求的情况下才能开展开发工作。切忌盲目开发，否则既浪费资源，又浪费时间。可行性研究宜从技术、需求面、投入与影响四个方面进行考虑：1.1.1 技术可行性分析根据业务上提出的需求，从技术开发的角度分析现有的技术手段与技术能力是否能够实现业务上所要求的系统功能。通常可从下列三个方面进行分析：a）人员技术能力分析，指公司内的系统开发队伍或者外包的第三方开发公司是否具有足够技术与管理能力来完成系统开发的任务。b）计算机软件与硬件分析，指公司现有的软件与硬件的性能是否足够满足开发相应的系统的要求。c）管理能力分析，指现有的技术开发管理制度与管理流程是否成熟且标准化，是否满足系统开发的要求。1.1.2 需求可行性分析系统的开发来源于业务上的需求，因此需要对该需求进行可行性分析，以推断需求是否明确，是否符合实际，是否在一定的时间范围内能够实现。1.1.3 投资可行性分析根据业务需求与技术手段的分析，确认实现系统开发所需的投资，并确认投资的数额是否在可操纵与可承受的范围内。1.1.4 影响可行性分析所谓的影响是指社会影响，比如系统开发是否符合法律法规上的要求，是否与有关的管理制度或者行业标准相抵触，是否符合人文或者道德上的约束等。1.2 开发人员安全管理1.2.1 系统开发人员职责分配在系统开发的过程中，应明确不一致人员的身份与职责。在系统开发过程中具体可分下列三种角色：项目负责人员：确保在整个系统开发的各个阶段都实施了有关的安全措施，同时在整个系统开发的过程中负责整个项目的开发安全管理。系统开发人员：根据业务需求确保开发的系统能够满足业务上的需求与相应的安全上的需求，同时满足系统质量上与进度上的要求。系统审核人员：对整个开发的过程进行审核与监督，确保开发的质量与开发的安全。1.2.2 开发人员授权a）应根据该员工在整个开发项目中所负责的开发内容授予其相应的权限与所应承担的责任。b）开发人员务必负责其开发内容的保密性，不得私自将开发的有关信息泄漏出去，即使对家人或者开发团队中的其他开发人员也不得泄漏。但开发人员有责任将开发的有关信息告诉项目的负责人员或者开发小组的负责人员。c）以书面的方式将员工的权限与相应的责任提交给员工本人。务必严格规定在为企业工作期间，所有与工作有关的开发成果的所属权都归企业所有。d）应根据员工权限与责任的大小确认是否需要签署有关的保密协议。e）应在日常工作中记录员工与开发有关的日志信息。f）员工一旦离职或者调动岗位应立即收回或者调整其相应的权限。1.2.3 开发人员务必训练开发安全代码的能力a）在整个开发的过程中务必完整持续地进行代码错误处理所规定的流程。b）错误问题报告应力求通俗易懂，不应在其中包含任何系统细节问题。c）应对重要的敏感信息进行加密保护。d）应使用一些相对复杂的加密与密钥生成机制。e）应单独编写安全性设计说明概要1.2.4 分离系统开发与运作保护管理层务必确保应用系统的开发与运作管理从组织人事与权限职责上分开。a）信息技术人员能够现场修复或者更换偶然或者恶意的数据与软件问题。b）测试代码中往往包含调试或者者查错代码，大大增加了主机系统的性能负担。c）开发人员不应具有很高的权限，否则将在系统运行中产生很大的风险。1.3 建立系统开发安全需求分析报告a）安全需求计划应能够达到期望的安全水平。其中包含了成本的预估，完成各个安全有关流程所需的时间。b）所有关于应用系统的更新或者改进都务必基于业务需求，并有业务事件支持。这里的业务需求不仅仅包含了系统的功能、性能、开发费用、开发周期等内容,应明确系统的安全要求。应用系统的任何一次改进或者更新都应与该业务系统的所有者密切有关。c）开发安全需求分析计划应由开发项目经理与公司内部的安全小组共同商议决定。d）应确保每一个应用系统的用户都意识到系统的更新或者改进都与其自身密切有关，所有的更新或者改动建议都务必基于业务需求，而不是基于所谓的“信息技术的要求”。e）系统的每一次更新或者改进都务必认真对待，务必进行全面的需求定义、需求分析与测试评估，以保证不可能对业务造成任何不良影响。f）业务需求是系统更新与改动的基础，因此务必清晰明确地定义业务的需求，禁止在业务需求未经业务部门领导与要紧负责人员认可的情况下，盲目地进行开发工作。8 系统设计阶段的安全规范8.1 单点访问操纵且无后门任何用户假如希望访问应用系统中的某一部分，则务必通过统一且唯一的认证授权方式及流程。8.2 人员职责与权限的定义由于不是所有的人员关于某一个应用系统都具有同样的访问或者使用权限，因此系统务必具有基于人员职责的用户授权管理，以确保每个用户能够访问到其权限范围内的应用系统部分。同时应确保每个用户无法访问其权限范围以外的应用系统部分。8.3 确保敏感系统的安全性将应用系统中敏感的信息储存在服务器端以进行集中的加密的安全管理，确保客户端系统本身并不能存储任何敏感的数据。8.4 确保访问层的安全性应用系统不仅仅要确保系统模块本身的安全性，同时还应考虑模块与模块之间通讯的安全性。这种模块与模块之间通讯的安全性不仅仅包含了应用系统内部模块之间通讯的安全，也包含了应用系统内部模块与外部模块之间的通讯安全性，如主机与客户端之间通讯的安全性、服务器与服务器间通讯的安全性，与本地系统与异地系统之间通讯的安全性。8.5 确保日志管理机制健全应建立可根据情况自由设置的日志管理机制，也就是说日志记录的范围与全面程度能够根据需求自行定制，且能够实现在应用系统的使用过程中进行日志的定制与记录。保留所有与系统开发有关的程序库的更新审核记录。8.6 新系统的容量规划容量规划是指确定系统的总体规模、性能与系统弹性。容量规划的具体内容可能是完全不一致的，但通常应考虑下列方面：a）系统的预期存储容量与在给定的周期中获取生成与存储的数据量。b）在线进程的数量与估计可能的占用资料c）系统与网络的响应时间与性能，即端对端系统d）系统弹性要求与设计使用率（峰值，槽值与平均值等）e）安全措施如加密解密数据对系统的影响。f）24x7运作要求与可同意的系统宕机次数（保护或者者设备更新导致的务必性宕机）规划容量的时候关于系统使用的信息熟悉的越多越好。近来，由于互联网站的使用以指数形式增长，容量规划的变动效果不是非常显著，有的时候甚至亳无用处。原因在于很难估计实际的负载。在容量估计的时候应尽量将情况设想得复杂一些。9 系统开发阶段安全规范9.1 系统开发语言程序员可使用很多指导规范来防止应用程序中的普通安全问题。其中许多能够应用于任何一种编程语言，但某些是针对特定的语言的。特定语言的指导规范要紧集中在PerLJaVa与C/C+语言。大多数情况下，通常的错误能够避免。而这些本能够避免的错误常常会导致很多安全漏洞，从而威胁信息的保密性、完整性与可用性。1 .1.1通用规范9 .1.1.1输入验证在客户机/服务器环境下，进行服务端的验证而不是客户端的验证（比如基于JaVaSCriPt的验证）。通过在客户端与服务器之间放置一个代理服务器，能够很容易绕过客户端验证。有了代理服务器，攻击者能够在数据被客户端“验证”后修改数据（与“maninthemiddle”攻击类似）。在实际的校验中，输入校验首先定义一个有效（可同意）的字符集，然后检查每个数据的字符是否在有效范围内。假如输入中包含无效的字符，应用程序应返回错误页面并说明输入中包含无效字符。这样进行验证的原因是定义无效的字符集比较困难，同时一些不应有效的字符通常不可能被指出。边界检查（比如字符串的最大长度）应在字符有效性检查往常进行。边界分析能够防止大多数缓冲区溢出漏洞。从环境变量获得的数据也需要进行验证。同时避免在环境变量中存放敏感数据（比如密码）。某些UniX系统（比如FreeBSD）包含PS命令，能够让用户看到任何当前进程的环境变量，这常常会暴露保密性信息。9.1.1.2SQL语句假如应用程序需要连接后端数据库，不得在代码中使用SQL语句。使用程序以外的嵌入在代码中的SQL语句调用特别危险，难以防止攻击者使用输入域或者者配置文件（由应用程序载入）来执行嵌入式的SQL攻击。而输入验证有助于缓解这种风险。9.1.1.3注释代码（COnmentedcode）当应用程序在实际环境中开始应用时，应删除所有的注释代码。注释代码是用来调试或者者测试的，它们不是最终应用程序的一部分。不管如何应在实际的环境中删除它们来避免意外的执行（通常注释标识被删除后就无法激活休眠的代码，但还是存在可能性的，因此应执行这项工作）。9.1.1.4错误消息所有对用户显示的错误信息都不应暴露任何关于系统、网络或者应用程序的敏感信息。假如可能的话，应使用包含编号的通常的错误信息，这种信息只有开发者与/或者支持小组才能懂得。通常的错误信息的例子是“发生了错误（代码1234）,请您与系统保护部门联系J9.1.1.5统一资源定位（URL）内容关于Web应用，不要在URL上暴露任何重要信息，比如密码、服务器名称、IP地址或者者文件系统路径（暴露了web服务器的目录结构）。这些信息能够在攻击时使用。比如下面就是一个不安全的URL：9.1.1.6设置PATH变量设置PATH为一个已知的值，而不仅仅是使用启动时的缺省值。攻击者能够在攻击应用程序时使用PATH变量，比如试图执行一个任意的程序。这些也能够应用于大多数其他的语言。9.1.2Perl语言多年以来，Perl已经成为用于系统管理与WebCGI开发的功能最强的编程语言之一（几乎能够使用PerI实现任何功能）。但其扩展应用，即作为Intemet上CGl的开发工具，使得它经常成为Web服务器上的攻击目标。另外，大多数CGl脚本有着比通常用户更高的权限，导致它更容易受攻击。下面列举了一些开发者（特别是CGI程序员）能够使用的主动的预防性的措施来增强PeH代码的整体安全性（请注意：这不是Web服务器CGl脚本安全性的指导原则）。9.1.2.1Taint验证Perl版本5.x包含一个叫做TaintChecking的数据验证措施。假如起用该功能，它就不同意通过用户输入（任何程序外的输入）来操纵其他的外部程序（比如通过管道将数据导入另一个程序执行）。通常而言，程序员不能信任输入脚本与程序的数据（叫做数据），由于无法保证它不可能产生危害（有意或者者无意的）。Taim验证能够通过在命令行参数加入“T”来开启。比如能够PCH脚本的第一行这样加入“T”：#!usr/bin/perl5-TTainted数据包含命令行参数、环境变量与来自文件的数据。引用tainted数据的变量也成为tainted数据。假如脚本试图通过不安全的方式来使用tainted数据会产生一个致命错误（对这种情况称之“不安全的依靠,（Insecuredependency）或者者其他的说法）。启用tainted验证在有些情况下会导致脚本停止运行，常常是由于Perl解释器要求所有脚本引用的外部程序的完全路径务必在PATH环境变量中列出，同时PATH中包含的每个目录除了目录的所有者及相应的所有者用户组外无法修改。Taint验证关于环境比较敏感，这就可能会导致大多数程序员不愿使用它，但是只要可能就应使用taint验证，特别是代码执行其他程序功能时（比如在CGl脚本的情况下）。9.1.2.2安全模块假如不但输入数据不可信而且实际的代码也不可信会产生什么情况？比如用户从网站上下载了一个ActiveX控件，而它实际是一个特洛伊木马（TrOjanhorse）o这种情况下taint验证就不起作用。安全模块让程序员能够在Perl脚本中将不一致的代码模块与安全对象相联系。每个安全对象关于运行的每块代码建立了一个限制的环境。这与Chroot在一个进程中只能在整体目录结构的一个子目录中运行类似。而saft对象限制perl代码只能在perl包结构的某些特定包中运行。如何使用安全模式超出了本文的范围，但程序员应在任何时候使用这一功能。9. 1.2.3警告参数Qw)使用w参数能够在Perl解释脚本时显示所有的警告信息。警告能够对下列情况产生：只使用了一次的变量或者者完全没有使用过的变量，未定义的文件句柄，未关闭的文件句柄，或者将非数值变量传递到数据变量。该功能不是针对安全处理的，但是有助于调试直接或者者间接对安全有危害的错误。通常推荐总是使用-W参数。可在taint验证时在第一行这样使用-W参数：#!usrbinerl5-Tw9.1.3JaVa语言自从1995年公布以来，JaVa成为简单或者者复杂网络应用的有效编程语言。它在设计时充分考虑了安全问题，因此它具有的限制特征有：收集不再使用的内存碎片的垃圾收集器，严格的“sandbox”安全模型，与在特定主机上限制应用程序的活动的安全管理器。下列为使用中的有关的规范：9.1.3.1不应在标准输出上打印消息在实际的Internet系统中避免使用SyStem.out.println()或者者System.err.println()打印日志与错误消息，原因是当消息打印到标准输出时，无法立即确定消息发生的地点，且有可能将敏感信息透露给攻击者。9. 1.3.2封装Java中,假如没有使用访问标识符(accessmodifier(privateprotected或者public)来声明类、方法与属性，那么它的默认访问范围是包，同时同一包中的所有类都能访问它。务必记住尽管包有封装功能，但它只有在每部分加载到包的代码都由授权用户操纵时才起作用。恶意的用户能够加入他们自己的类，从而关于包中的所有类、方法与属性都有完全的访问权限。Java的政策文件支持两种操纵包访问权限的前缀。accessClassInPackagedefIneciassInPackage所有标准库中的类都默认是能够公共访问的(除了由“sun”开头的类)。为了保证个包的安全性，务必修改$JAVAHOME/jrelib/security文件夹中的java.security文件。该文件中的重要行是：package.access=sun.尽管该方法有作用，但仍存在问题。比如程序员在java.security文件中定义包的安全时务必十分小心。在PaCkage.access中的值是字符型的，“sun.”将保护“sun.tools”等包，但是不可能对“sun”或者者asunshine"等包进行保护。另一个方法是使用JAR密封(SeaIing)。JAR(JavaARChiVe)文件是一些类的打包压缩格式的文件，与常用的ZIP格式类似。假如从一个密封(Sealing)的JAR文件中加载一个类，随后同一个包的类只能从该JAR文件加载。为了起用密封(sealing),务必在建立JAR文件时这样设置密封(Seal)参数：Sealed:true使用密封(SeaIing)的JAR文件比权限(permission)设置更好，由于它不需要安装安全管理器(SeCUritymanager)o9.1. 3.3政策文件Java内建的安全管理器是对应用程序进行限制的一个方便的工具。很多情况下需要编制一个定制的安全管理器，JDK1.2及以后的版本提供了雌设置的方法而不是实藤之夕九这是通过JaVa政策文件实现的。能够用政策文件以相对模块化的方式操纵文件系统与网络的访问。比如能够限制应用程序只能修改名字是foo的文件。宜使用Java政策文件与安全管理器而不是重新创建一个类或者者系统来限制对主机与网络的访问。9.1.4C/C+语言C本质上是不安全的编程语言。比如假如不慎重使用的话，其大多数标准的字符串库函数有可能被用来进行缓冲区攻击或者者格式字符串攻击。但是，由于其灵活性、快速与相对容易掌握，它是一个广泛使用的编程语言。下面是针对开发安全的C语言程序的一些规范。9. 1.4.1缓冲区溢出避免使用不执行边界检查的字符串函数，由于它们可能被用来进行缓冲区溢出攻击。下面是应避免使用的函数。同时，也列出了每个函数相应的比较安全的替换方式。> 不使用strcpy(),使用stmcpy()> 不使用StrCat(),使用strncat()> 不使用SPriInf(),使用snprintf()> 不使用gets(),使用fgets()在上面的前三个中函数中，每个替代函数的“n”表示了使用的缓冲区的大小。最后一个函数的“f”，表示格式，它同意用户指定期望的输入的格式。这些替换方程强制程序员定义使用的缓冲区的尺寸与确定输入的类型。9.1.4,2格式化字符串攻击(FormatStringAttack)该类攻击往往与缓冲区溢出有关，由于它们往往要紧利用了某些函数的假设,比如SPrintfO与VSPrintf()假设缓冲区的长度是无限的。然而即使使用snprintf()替换SPrintf()也无法完全保护程序不受格式化字符串的攻击。这些攻击通过直接将格式说明符(fbrmatspecifiers)(%d,%s,%n等)传递到输出函数接收缓冲区来进行。比如，下列的代码就是不安全的：snrintf(buffer,sizeof(buffer)zstring)这种情况下，能够在字符串中插入格式说明符来操纵内存的栈，来写入攻击者的数据(这些数据中包含小的程序代码，并可由处理器接着执行)。更多关于这些攻击的具体内容请见资源章节。对以上的例子建议使用下面的代码。snprintf(buffer,sizeof(buffer),''%s,fstring)进行格式字符串攻击不太容易。首先攻击者务必能获得内存栈的内容情况(从应用导出或者者使用调试器)，然后务必明白如何精确访问特定的内存空间来操纵栈中的变量。9.1.4.3执行外部程序推荐使用exec()函数而不是SyStem()函数来执行外部程序。这是由于system()接收整个命令行的随机的缓冲区来执行程序。snprintf(buffer,sizeof(buffer),emacs%s",filename);systcm(buffer);在以上的例子中，能够通过使用分号利用文件名变量在sehll中插入额外的命令(比如文件名能够是etchosts;rm*,这将在显示etchosts目录文件的同时，删除目录中的所有文件)。而exec()函数只保证第一个参数被执行：execl(,usr/bin/emacs,»,usrbinemacs,',filename,NULL);上面的例子保证文件名仅仅作为一个参数输入Emacs工具，同样它在Emacs命令中使用完全的路径而不是使用能够被攻击者利用的PATH环境变量。9.1.4.4竞争条件(racecondition)进程需要访问资源时(不管是磁盘、内存或者是文件)通常需要执行两个步骤：(1)首先测试资源是否空闲可用(2)假如可用，就访问该资源，否则它等到资源不再使用为止再去访问它当另一个进程在步骤1与2之间想要访问同个资源时将出现问题，导致不可预测的结果。进程可能会被锁定，或者者一个进程籍此获得了另一个进程的较大的权限而导致安全问题。攻击要紧集中在有较大权限的程序上(称之SetUid程序)。竞争条件攻击通常利用程序执行时能够访问到的资源。另外权限低的程序也存在安全风险，由于攻击者可能会等待有较高权限的用户执行那个程序(比如root),然后进行攻击。下面的建议有助于缓解竞争条件(raceCOnditiOn)攻击：在进行文件操作时，利用那些使用文件描述符的函数而不使用那些使用文件路径的函数(比如使用fdopen()而不要使用fopen(),文件描述符使得恶意的用户在文件打开时或者是在原始的进程对文件进行操作前,无法使用文件连接(符号式的或者是物理的)来改变文件。在写文件甚至在读文件时宜使用fcntl()与flock()函数来对文件加锁，这样它们就不能被其他进程访问。它几乎能够建立原子级的操作。应慎重操纵临时文件，由于它往往会导致竞争条件攻击。9. 1.4.5检验有效的返回值检验有效的返回值非常重要。一个例子是旧的bink>gin的实现中不检验错误的返回值，导致当它找不到etcpasswd文件时返回root的访问权限。假如该文件损坏了则这种情况是合理的；但假如该文件存在只是无法访问，那么这就是一个大问题。9.2 系统开发安全有关工具管理有许多方法来确保代码符合一定的安全级别。正如前面指出的，最好的方法之一是让尽可能多的人来检查代码（而不是在QA环境中实际进行白箱或者者黑箱测试）。然而，有的时候代码在开始实际环境的应用前往往没有足够的时间，同时即使检查代码也会漏掉些不易发现的错误。这些错误可能会对整个系统导致重大的安全问题。因此（与其他的原因），使用源码分析工具（SOUrCeCodeAnalySiSTool（SCAT）来自动进行某些检查过程很有帮助。本文介绍了一些这方面的工具。每个工具都用同样的测试工具来检验，这些测试工具包含C与JaVa的代码段，而这些代码段存在潜在的安全错误。我们比较了每个工具的测试结果，同时认真检查了下列的属性：a）灵活性-有多种选项并能扫描多种类型的代码的工具得分会较高。b）正确性一要紧目标是发现正确的安全问题，同时不可能出现大量的误报信息，或者者更糟的是没有发现真正的错误信息。c）容易使用一大多数情况下，程序员只需将工具指定到特定的代码上然后选择“扫描”。除非特别需要，程序员通常只做抽样检查，而无需开发复杂的测试机制。d）投表一扫描结果应以一种容易懂得的格式来显示，同时最好同时提示修改每个问题的方法，并附加理由。每个工具在解析代码上的速度能够忽略不计，因此没有进行比较（尽管这并不包含配置扫描的时间，而MoPS在这方面相关于其它工具需要更多的时间）。另外，这些工具都能够免费获得，甚至能够获得它们的源代码，因此不需考虑它们的成本。9.2.1 工具一：PScanPscan是一个有针对性的扫描程序，要紧用于发现C程序中的缓冲区溢出与格式化字符串攻击。该程序检查所有用到标准C程序库中的printf（）函数。sprintf（buffer,variable）;printf(buffer,variable);关于这些语句在缓冲区溢出与格式化字符串攻击中如何被利用能够查阅有关的C与C+文档。Pscan的一个不足是不能发现由于越界检查不充分而引起的常规性缓冲区溢出。但PSCan关于缓冲区溢出与格式化字符串攻击的定位还是相当精准与快速的。PSCan程序相对简单，它只将结果返回标准输出，当然也能够将其输出到文件，同时除了说明程序员应如何修正错误以外，不给出语句为什么出错等类似信息。该工具一个显著的特点是能够同时扫描多个文件。总体而言PSCan程序相对简单，易于使用，同时针对性很强，但是由于它能够适用的范围过于狭窄因此通常不推荐其在大型商