中国石油天然气股份有限公司应用系统开发安全管理通则

1、中国石油信息安全标准编号:I PetroChina!中国石油中国石油天然气股份有限公司应用系统开发安全管理通则中国石油天然股份有限公司随着中国石油天然气股份有限公司（以下简称“ 中国石油”信息化 建设 的稳步推进，信息安全日益受到中国石油的广泛关 注，本规范是依据中国石油信息安全的现状，参照国际、国内和行业相关 技术标准及规范，结合中国石油自身的应用特点，制定的适合于中国石 油信息安全的标准与规范。目标在于通过在中国石油范围内建立信息安 全相关标准与规范，提高中国石油信息安全的技术和管理能力。信息技术安全总体框架如下：物理环境 安全管理硬件设备 安全管理网络女全 管理规范操作系统 安全管理数据

2、和文档 安全管理应用系统安 全管理1«信息安全技术标准«通用安全管理标准数据和文档安全 管理规范j 理We 规系 范统 女 全 管子 范商 务计 算防 机御 范犯恶 罪意管代 理码 规和通用安全管理标准概述+认证管理通用标准*授权管理通用标准f加密管理通用标准*加固管理通用标准1）整体信息技术安全架构从逻辑上共分为7个部分，分别为：物理环境、硬件设备、网络、操作系统、数据和文档、应用系统和通 用安全管理标准。图中带阴影的方框中带书名号的为单独成册的 部分，共有13本规范和1本通用标准。2）对于13个规范中具有一定共性的内容我们整理出了7个标准横向贯穿整个架构，这 7个标准的

3、组合也依据了信息安 全生命周期的理论模型。每个标准都会对所有的规范中 相关涉及到的内容产生指导作用，但每个标准应用在不同的 规范中又会有相应不同的具体的内容。我们在行文上将这 7 个标准组合成一本通用安全管理标准单独成册。3) 全文以信息安全生命周期的方法论作为基本指导， 规范和标 准的内容基本都根据预防保护检测跟踪响 应恢复的理论基础行文。本通则讨论了在企业内部自行开发一套应用系统或外包开发所必须 考虑到的几个步骤，开发应用系统的安全性考虑就好像建设楼房一样， 拥有越坚固的地基楼房越是稳定，因此应用系统在开发阶段打好坚实的 安全基础，那么以后的日常维护工作就会很轻松。以下我们主要从系统 开发

4、的各个阶段入手，考虑在标准的开发流程的各个阶段中要注意的安 全方面的考虑。本规范由中国石油天然气股份有限公司发布。本规范由中国石油天然气股份有限公司科技与信息管理部归口管理 解释。起草部门：中国石油制定信息安全政策与标准项目组。说明在中国石油信息安全标准中涉及以下概念：组织机构中国石油( PetroChina ) 指中国石油天然气股份有限公司有时也称 “股份公司”。集团公司( CNPC ) 指中国石油天然气集团公司有时也称“存续公 司”。为区分中国石油的地区公司和集团公司下属单位，担提及“存续部 分”时指集团公司下属的单位。如：辽河油田分公司存续部分指集团公 司下属的辽河石油管理局。计算机网络

5、中国石油信息网( PetroChinaNet ) 指中国石油范围内的计算机网 络系统。中国石油信息网是在中国石油天然气集团公司网络的基础上， 进行扩充与提高所形成的连接中国石油所属各个单位计算机局域网和园 区网。集团公司网络( CNPCNet ) 指集团公司所属范围内的网络。中国 石油的一些地区公司是和集团公司下属的单位共用一个计算机网络，当 提及“存续公司网络”时，指存续公司使用的网络部分。主干网 是从中国石油总部连接到各个下属各地区公司的网络部分，包括中国石油总部局域网、各个二级局域网（或园区网）和连接这些网 络的专线远程信道。有些单位通过拨号线路连接到中国石油总部，不是 利用专线，这样的

6、单位和所使用的远程信道不属于中国石油专用网主干 网组成部分。地区网 地区公司网络和所属单位网络的总和。 这些局域网或园区网 互相连接所使用的远程信道可以是专线，也可以是拨号线路。局域网与园区网 局域网通常指， 在一座建筑中利用局域网技术和设 备建设的高速网络。园区网是在一个园区（例如大学校园、管理局基地 等）内多座建筑内的多个局域网，利用高速信道互相连接起来所构成的 网络。园区网所利用的设备、运行的网络协议、网络传输速度基本相同 于局域网。局域网和园区网通常都是用户自己建设的。局域网和园区网 与广域网不同，广域网不仅覆盖范围广，所利用的设备、运行的协议、 传送速率都与局域网和园区网不同。传输信

7、息的信道通常都是电信部门 建设的。二级单位网络 指地区公司下属单位的网络的总和，可能是局域网， 也可能是园区网。专线与拨号线路 从连通性划分的两大类网络远程信道。专线，指数 字电路、帧中继、 DDN 和 ATM 等经常保持连通状态的信道；拨号线路， 指只在传送信息时才建立连接的信道，如电话拨号线路或 ISDN 拨号线 路。这些远程信道可能用来连接不同地区的局域网或园区网，也可能用 于连接单台计算机。石油专网与公网 石油专业电信网和公共电信网的简称最后一公里问题 建设广域网时，用户局域网或园区网连接附近电信 部门信道的最后一段距离的连接问题。这段距离通常小于一公里，但也 有大于一公里的情况。为简

8、便，同称为最后一公里问题。涉及计算机网络的术语和定义请参见中国石油局域网标准。1.1 概述 31.2 目标 31.3规范的使用范围 41.4规范引用的文件或标准 51.5术语和定义 61.6应用系统开发总体原则 71.7系统需求收集和分析阶段安全规范 81.7.1可行性研究分析 81.7.2 开发人员安全管理机制 101.7.3建立系统开发安全需求分析报告 111.8系统设计阶段的安全规范 121.8.1单点访问控制，无后门。121.8.2人员职责和权限的定义 121.8.3确保敏感系统的安全性 121.8.4确保访问层的安全性 121.8.5确保日志管理机制健全 121.8.6新系统的容量规

9、划 131.9系统开发阶段安全规范 141.9.1 系统开发语言安全规范 141.9.2系统开发安全相关工具管理规范 191.9.3 控制软件代码程序库 211.9.4在软件开发过程变更管理规范 231.9.5开发版本管理规范 241.9.6开发日志审核管理规范 251.9.7防御后门代码或隐藏通道相关规范 251.10系统测试阶段安全规范 271.10.1应用系统的安全性检测规范 271.10.2控制测试环境291.10.3为测试使用真实的数据 291.10.4 在软件转移至牛产环境前进行测试 291.10.5应用系统安全质量鉴定 301.11系统培训及文档阶段安全规范 311.11.1新系

10、统的培训311.11.2撰写新系统和系统改进的文档 311.12应用系统开发外包安全控制 32附录 1参考文献 33应用系统开发安全管理通则1.1 概述信息系统的许多的安全控制或者是安全性是通过系统的开发设 计予以实现的。因此如果在系统的开发设计阶段没有对系统的 安全性给予充分的考虑，那么系统本身一定会存在许多先天不 足，系统就会漏洞百出。为了确保应用系统的安全，在应用系 统开发之前就应当对系统的安全要求有所确认，并作为开发设 计的阶段的基础予以落实。本规范主要规定了在系统开发的各个阶段需要的各种安全规 范，从可行性分析需求分析阶段开始，到设计阶段，再到开发 阶段和维护阶段以及最后的文档阶段的

11、系统开发的各个阶段进 行阐述。将不同阶段下需要注意的安全问题和相关的安全规范 进一步进行描述和规定。1.2 目标本规范的目标为：保护应用系统开发过程中的安全。具体地说就是保护应用系统开发过程中免受未经授权的访问和更改，保护系统开发中系统软件和信息的安全，确保开发项目的顺利正确的实施并对开发环境进行严格的控制。同时确保应用系统开发外包中的各项安 全。从而进一步保障中国石油业务的持续运营，保护中国石油信息资产安全，即保护软件及信息的完整性，维护信息处理设备及通讯服务的完整性及可用性，确保设备中的信息及相关基础建设的安全，确保正确、安全操作信息处理设备，降低系统故障 风险。总而言之，要防止对中国石油

12、经营环境及信息的未经授权存取、 破坏或干扰；防止中国信息资产受损及企业运营受影响；防止 信息及信息处理设备泄露及被偷窃。1.3 规范的使用范围该套规范适用的范围包括了 整个应用系统开发过程中的安全 包括了系统开发可行性和需求分析阶段的安全，系统设计阶段 的安全，系统开发阶段的安全，系统测试阶段的安全，系统培 训和文档阶段的安全以及系统开发外包的安全规范。系统规业了需求系符合性过保证安感信息的安件的质统本要求 稳定性和兼容性问题。1.4 规范引用的文件或标准下列文件中的条款通过本标准的引用而成为本标准的条款凡是不注日期的引用文件，其最新版本适用于本标准。1. 建筑设计防火规范 ( GBJ16-8

13、7)2. 高层民用建筑设计防火规范 ( GB50045-97)3. 建筑内部装修设计防火规范 ( GB50222_95)4. 建筑防雷设计规范 ( GB50057)1.5 术语和定义1.6 应用系统开发总体原则应用系统的开发应当遵循一系列的总体原则，以确保开发过程 中的安全。其中包括：a) 系统开发需得到公司领导层的重视和参与。需要领导层组织 开发力量，协调各方关系并在开发的过程中提供决策性的意 见和建议。b) 系统开发应当从业务需求得角度出发，不得盲目追求系统先 进性而忽略了系统的实用性。系统的开发是为了更高的满足 业务上的需要，而不是技术上的需要。c) 开发的方法和管理必须规范化、合理化、

14、制度化。只有采用 了规范化合理化制度化的开发管理方法，才能确保开发的质 量和进度。d) 保证开发的进度和按时完成。确保开发工作及时、有效且高 质量的完成。e) 系统开发必须具有一定的前瞻性，符合主流系统的发展方 向。f) 开发人员安全意识的提高和加强。确保机密信息和关键技术 不会泄漏，特别是泄漏到竞争对手的手中，将会对公司的竞 争力产生极大的影响。g) 充分利用现有的资源。1.7 系统需求收集和分析阶段安全规范1.7.1 可行性研究分析对于应用系统开发项目需要进行一定的可行性分析， 确认在 开发工作具备了的相当资源和条件， 并且有能力满足业务上 的需求的情况下才能开展，切忌盲目开发。既浪费了资

15、源， 又浪费了时间。可行性研究可以从技术方面， 需求方面， 投入方面和影响方 面进行考虑：1.7.1.1 技术可行性分析的根技据业术手务上段和提技出的术能需力求，是从否可技以术达开发到业的角务上度要分求析的是否系现统有功能。通常可以从三个方面进行分析：a)b)c)人员技术能力分析，指公司内的系统开发队伍是否有 足够的软件开发的技术能力来完成系统开发的任务， 或第三方外包的开发公司是否具有开发应用系统的技 术能力。计算机软件和硬件分析，指公司现有的软件和硬件的 性能是否足够满足开发相应的系统的要求。管理能力分析，指现有的技术开发管理制度和管理流 程是否成熟且标准化，是否足够系统开发的要求。1.7

16、.1.2 需求可行性分析系统的开发来源于业务上的需求，因此需要对该需求进行可行性分析，以判断需求是否明确，是否符合实际而不是 天马行空式的空谈，是否是在一定的时间范围内可实现 的。1.7.1.3 投资可行性分析根术据手业段务需需要求多和少技的术投手资段才的可分以析实，现，确确认认根据投资业的务数需求额和是技不是在可控制和可承受的范围内。1.7.1.4 影响可行性分析所谓的影响是指社会影响，比如系统开发是否符合法律法规上的要求，是否和相关的管理制度或行业标准相抵触， 是否不符合人文或道德上的约束等等。1.7.2 开发人员安全管理机制1.7.2.1 系统开发人员职责分配管理规范在系统开发的过程中，

17、 应当明确不同的人员的身份、 职责。 我们建议在系统开发过程中具体分以下的三种角色：项目负责人员： 确保在整个系统开发的各个阶段都实施 了相关的安全措施， 同时在整个系统开发的过程中负责 整个项目的开发安全管理。系统开发人员： 根据业务需求确保开发的系统能够满足 业务上的需求和相应的安全上的需求， 同时满足系统质 量上和进度上的要求。系统审核人员：对整个开发的过程进行审核和监督，确保开发的质量和开发的安全。1.7.2.2 开发人员授权管理规范a) 根据该员工在整个开发项目中所负责的开发内容授予 其相应的权限和承担的责任。b) 开发人员必须负责其开发内容的保密性，不得私自将 开发的相关信息泄漏出

18、去，即使是家人或开发团队中 的其他开发人员也不得泄漏。但开发人员有责任将开 发的相关信息告诉项目的负责人员或开发小组的负责 人员。c)以本书人面。的必方须式严将格员规定工在的权为限企和业相工应作的期责间任的所提有交和给员工工作相关的开发成果的所属权都归企业所有。d) 根密员工权限和责任的大小确认是否需要签署相关的e) 在日常工作中记录员工的开发相关的日志信息。f) 权员工限一。旦离职或调动岗位应立即收回或调整其相应的1.7.2.3 开发人员必须训练开发安全代码的能力a) 开发人员应该有能力防止开发过程中的缓冲器溢出错误 “ buffer over flow attacks 。 ”b) 在整个开

19、发的过程中必须完整的持续的进行代码错误处 理所规定的流程。c) 错误问题报告应该越通俗越好，不应该在其中包含任何 系统细节问题。d) 应该对重要的敏感信息进行加密的保护。e) 应该使用一些相对复杂的加密和密钥生成机制。f) 应该单独编写安全性设计说明概要1.7.2.4 分离系统开发和运作维护管理层必须要确保应用系统开发和应用系统运作管理从 组织人事和权限职责上必须分开。尽管只有大型企业才有 独立的系统运行和系统开发部门，但是把这些功能分开毫 无疑问是非常必要的。职责的分开对于大多数信息安全保 护来说至关重要。b)a) 歸员件以现场修复或者更改偶然的或者是恶意的数主测试机系代统码的中往性能往负包

20、含担调试或者查错代码，大大加大了c) 生开很发人大员的常风常险具，有所很以高是的不权可限接，收这的在。运行系统中会产1.7.3 建立系统开发安全需求分析报告a) 安全需求计划应该能够达到期望的安全安全水平。其中 包括了成本的预估，完成各个安全相关流程所需的时间b) 所有的有关应用系统的更新或改进都必须是基于业务需 求的，并且是有业务事件支持的。这里的业务需求不仅 仅包括了系统的功能、性能、开发费用、开发周期等内 容，还要明确系统的安全要求。应用系统的任何一次改 进或更新都和该业务系统的所有者密切相关。c) 一个安全开发需求分析计划应该由开发项目经理和公司 内部安全小组共同商议决定。d) 确保每

21、一个应用系统的用户都意识到系统的更新或改进 都和他们本身密切相关，所有的更新或改动的建议都必 须是由业务需求出发的而不是从所谓的“信息技术的要 卜”求”。e) 系统的每一次更新或改进都必须认真的对待，必须进行 详细的需求定义、需求分析以及测试评估以保证不会对 业务造成任何的影响。f) 业务需求是系统更新和改动的基础，因此必须清晰明确 的定义业务的需求，绝对不允许在业务需求未经过业务 部门领导和主要负责人员的认可的情况下，盲目的进行 开发工作。1.8 系统设计阶段的安全规范1.8.1单点访问控制，无后门。任何用户如果希望访问应用系统中的某一个部分， 则必须通过统一的且唯一的认证授权方式以及流程。

22、1.8.2人员职责和权限的定义由于不是所有的人员对于某一个应用系统都具有同样的访 问或使用的权限， 因此系统必须具有基于人员职责的用户授 权管理以确保每个用户可以访问到其权利范围内的应用系 统部分。 同样的，也要确保每个用户无法访问其权限范围以 外的应用系统部分。1.8.3确保敏感系统的安全性通过将应用系统中敏感的信息保存在服务器端以进行集中 的加密的安全管理， 确保客户端系统本身并不能存储任何信 息敏感的数据。1.8.4确保访问层的安全性应用系统不仅仅要确保系统模块本身的安全性， 同时也要考 虑模块与模块之间的通讯的安全性。 这种模块与模块之间的 安全性不仅仅包括了应用系统内部模块之间的安全

23、， 也包括 了应用系统内部模块和外部模块之间的安全性， 如主机和客 户端之间通讯的安全性。服务器和服务器间通讯的安全性， 本地系统和异地系统之间通讯的安全性。1.8.5 确保日志管理机制健全要求建立可以根据情况自由设置的日志管理机制，也就是 说日志纪录的范围和详细程度可以根据需求自行定制，且 可以实现在应用系统使用过程中进行日志的定制和记录。 保留所有系统开发相关的程序库的更新审核纪录。1.8.6 新系统的容量规划容量规划是指确定系统的总体规模， 性能和系统弹性。 容量 规划的具体内容可能有所不同，但一般需要考虑以下方面：a) 系统的预期存储容量和在给定的周期里面获取生成和 存储的数据量。b)

24、 在线进程的数量和估计可能的占用资料c) 对于系统和网络的相应时间和性能，即端对端系统d) 系统弹性要求和设计使用率 -峰值，槽值和平均值等e) 安全措施例如加密解密数据对系统的影响。f) 24x7 运作要求和可接受的系统宕机次数(维护或者设 备更新导致的必须性宕机)规划容量的时候关于系统使用的信息了解得越多越好。近 来，由于互联网站得使用以指数形式增长， 容量规划变动效 果不是非常显著， 有时甚至毫无用处。 原因在于很难估计实 际的负载。在容量估计的时候需要尽量将情况设想得复杂一 些。二 O1.9 系统开发阶段安全规范1.9.1 系统开发语言安全规范程序员可以使用很多指导规范来防止应用程序中

25、的普通的 安全问题。 其中许多可以应用于任何一个编程语言， 但某些 是针对特定的语言的。特定语言的指导规范主要集中在 Perl, Java和C/C+语言。大多数情况下，一般的错误可以 通过下功夫或者对基本的问题有很好的理解来避免。 这些本 可以避免的错误常常会导致很多安全漏洞， 从而威胁信息的 保密性、完整性和可用性。1.9.1.1 通用规范1.9.1.1.1 输入验证在客户机 /服务器环境下，进行服务端的验证而不是客 户端的验证（例如基于 Javascript的验证）。通过在客 户端和服务器之间放置一个代理服务器， 可以很容易绕 过客户端验证。 有了代理服务器， 攻击者可以在数据被 客户端“

26、验证”后修改数据（与“ man-in-the-middle” 攻击类似）。在实际的校验中， 输入校验首先定义一个有效 （可接受） 的字符集，然后检查每个数据的字符是否在有效范围 内。如果输入中包含无效的字符， 应用程序应该返回错 误页面并说明输入中包含无效字符。 这样进行验证的原 因是定义无效的字符集比较困难， 并且一些不应该有效 的字符通常不会被指出。另外， 边界检查 （例如字符串的最大长度） 应该在字符 有效性检查以前进行。 边界分析可以防止大多数缓冲区 溢出漏洞。必须提到的是从环境变量获得的数据也需要进行验证。 同时避免在环境变量中存放敏感数据 （例如密码） 。某 些Unix系统（例如F

27、reeBSD）包含ps命令，可以让用 户看到任何当前进程的环境变量， 这常常会暴露保密性 信息。1.9.1.1.2 SQL 语句如果应用程序需要连接后端数据库， 使用存储过程而不 要在代码中使用 SQL 语句。使用程序以外的嵌入在代 码中的 SQL 语句调用特别危险。难以防止攻击者使用输入域或者配置文件 （由应用程序载入） 来执行嵌入式 的 SQL 攻击。当然，输入验证有助于缓解这种风险。1.9.1.1.3 注释代码 （commented code） 当应用程序在实际环境中开始应用时， 应该删除所有的 注释代码。 注释代码是用来调试或者测试的， 它们不是 最终应用程序的一部分。 无论如何应该在

28、实际的环境中 删除它们来避免意外的执行 （一般注释标识被删除后就 无法激活休眠的代码， 但还是存在可能性的， 所以强烈 建议执行这项工作）。1.9.1.1.4 错误消息 所有为用户显示的错误信息都不应该暴露任何关于系统、网络或应用程序的敏感信息。 如果可能的话， 最好 使用包含编号的一般的错误信息， 这种信息只有开发者 和 /或支持小组才能理解。 一般的错误信息的例子是 “发 生了错误（代码 1234），请您与系统维护部门联系。 ”1.9.1.1.5 URL 内容对于 web 应用，不要在 URL 上暴露任何重要信息，例 如密码、服务器名称、 IP 地址或者文件系统路径（暴露了 web服务器的

29、目录结构）。这些信息可以在攻击时使用。例如下面就是一个不安全的URL ： rname=USER&password=PASSWORD&file=/home/USER/expenses.tx191.1.6设置PATH变量设置 PATH 为一个已知的值，而不是仅仅使用启动时的缺省值。攻击者可以在攻击应用程序时使用 PATH 变量，例如试图执行一个任意的程序。这些也可以应用于大多 数其他的语言。1.9.1.2 Perl 语言安全规范多年以来，Perl已经成为用于系统管理和 Web CGI开发的 功能最强的编程语言之一 （几乎可以使用 Perl 做任何功能 的程序）。但其扩展应用，即作为

30、In ternet上CGI的开发工具，使得它经常成为 web 服务器上的攻击目标。另外， 大多数 CGI 脚本有着比一般用户更高的权限， 导致它更容 易受攻击。下面列举了一些开发者（特别是 CGI 程序员） 可以使用的主动的预防性的措施来增强Perl代码的整体安全性（请注意：这不是web服务器CGI脚本安全性的指导 原则）。1.9.1.2.1 Taint 验证Perl 版本 5.x 包含一个叫做 Taint Checking 的数据验证 措施。 如果起用该功能， 它就不允许通过用户输入 （任 何程序外的输入） 来操纵其他的外部程序 （例如通过管 道将数据导入另一个程序执行）。一般而言，程序员

31、不能信任输入脚本和程序的数据 （叫做 Tainted 数据）， 因为无法保证它不会产生危害（有意或者无意的）。 Tai nt验证可以通过在命令行参数加入“-T”来开启。例如你可以在 Perl 脚本的第一行这样加入“ -T”： #!usr/bin/perl5 -TTainted 数据包括命令行参数、环境变量和来自文件的 数据。引用 tainted 数据的变量也成为 tainted 数据。如 果脚本试图通过不安全的方式来使用 tainted 数据会产 生一个致命错误（对这种情况称为“不安全的依赖” （In secure depe ndenqy或者其他的说法）。启用 tai nted 验证在有些情况

32、下会导致脚本停止运行，常常是由于 Perl 解释器要求所有脚本引用的外部程序的完全路径 必须在 PATH 环境变量中列出，同时 PATH 中包含的 每个目录除了目录的所有者及相应的所有者用户组外 无法修改。 Taint 验证对于环境比较敏感，这就可能会 导致大多数程序员不愿使用它， 但是只要可能的话， 应 该使用 taint 验证，特别是代码执行其他程序功能时 （例 如在 CGI 脚本的情况下）。1.9.1.2.2 安全模块 如果不但输入数据不可信而且实际的代码也不可信会 产生什么情况？例如用户从网站上下载了一个 ActiveX 控件，而它实际是一个特洛伊木马 仃rojan horse）。这种

33、 情况下 taint 验证就不起作用。安全模块让程序员可以在 Perl 脚本中将不同的代码模块与安全对象联系。每 个安全对象对于运行的每块代码建立了一个限制的环境。这与 chroot 在一个进程中只能在整体目录结构的一 个子目录中运行类似。而saft对象限制perl代码只能在 perl 包结构的某些特定包中运行。 如何使用安全模式超 出了本文的范围， 但是程序员应该在任何时候尽量使用 这一功能。1.9.1.2.3 警告参数 (-w)使用 -w 参数可以在 Perl 解释脚本时显示所有的警告信 息。警告可以对以下情况产生： 只使用了一次的变量或 者完全没有使用过得变量， 未定义的文件句柄， 未关

34、闭 的文件句柄， 或者将非数值变量传递到数据变量。 该功 能不是针对安全处理的， 但是可以有助于调试直接或者 间接对安全有危害的错误。 一般推荐总是使用 -w 参数。 可以在 taint 验证时在第一行这样使用 -w 参数：#!usr/bin/perl5 -Tw1.9.1.3 Java 语言安全规范自从1995年发布以来，Java成为简单或者复杂网络应用的有效编程语言。它在设计时充分考虑了安全问题，因此 它具有的限制特征有：收集不再使用的内存碎片的垃圾收 集器，严格的“ sandbox”安全模型，以及在特定主机上限 制应用程序的活动的安全管理器。下面的使用中相关的规 范：1.9.1.3.1 不

35、要在标准输出上打印消息在实际的In ternet系统中避免使用 System.out.pri ntl n()或 者System.err.println()打印日志和错误消息，原因是当消 息打印到标准输出时，无法立即确定消息发生的地点。 而且它有可能将敏感信息透露给攻击者。1.9.1.3.2 封装类、起作用。恶意的用户可以加入他们自己的类，从而对于 包中的所有类、方法和属性都有完全的访问权限。Java中，如果没有使用访问标识符(access modifier(private、protected或者 public)来声明类、方法 和属性，那么它的默认访问范围是包，并且同一包中的 所有类都能访问它。

36、必须记住虽然包有封装功能，但它 只有在每部分加载到包的代码都由授权用户控制时才Java的政策文件支持两种控制包访问权限的前缀。accessClassInPackagedefineClassInPackage所有标准库中的类都默认是可以公共访问的(除了由“ sun”开头的类)。为了保证一个包的安全性，必须修改 $JAVA HOME/jre/lib/security文件夹中的java.security 文件。该文件中的重要行是：package.access=sun.虽然该方法有作用，但是也有问题。例如程序员在 java.security 文件中定义包的安全时必须十分小心。在 package.acc

37、esS中的值是字符型的，“ sun将保护“ sun .tools”等包，但是不会对“ sun” 或者“ sunshine” 等包进行保护。另一个方法是使用 JAR 密封 (sealing) 。 JAR(Java ARchive)文件是一些类的打包压缩格式的文件，与常用 的ZIP格式类似。如果从一个密封(sealing)的JAR文件 中加载一个类时， 随后同一个包的类只能从该 JAR 文件 加载。为了起用密封(sealing)，必须在建立JAR文件时 这样设置密圭寸(seal)参数：Sealed: true使用密圭寸(sealing)的JAR文件比权限(permission)设置 更好，因为它不

38、需要安装安全管理器 (security manager)。1.9.1.3.3 政策文件Java内建的安全管理器是对应用程序进行限制的一个方 便的工具。很多情况下需要编制一个定制的安全管理 器， JDK1.2 及以后的版本提供了 描述设置的方法而不是 实施它们。这是通过 Java 政策文件实现的。 可以用政策 文件以相对模块化的方式控制文件系统和网络的访问。 例如可以限制应用程序只能修改名字是 foo 的文件。推荐使用Java政策文件和安全管理器而不是重新创建 一个类或者系统来限制对主机和网络的访问。1.9.1.4C/C+ 语言安全规范C 本质上是不安全的编程语言。 例如如果不谨慎使用的话， 其

39、大多数标准的字符串库函数有可能被用来进行缓冲区 攻击或者格式字符串攻击。但是，由于其灵活性、快速和 相对容易掌握，它是一个广泛使用的编程语言。下面是针 对开发安全的 C 语言程序的一些规范。1.9.1.4.11.9.1.4.21.9.1.4.3缓冲区溢出 避免使用不执行边界检查的字符串函数， 因为它们可能 被用来进行缓冲区溢出攻击。 下面是应该避免使用的函 数。同时，也列出了每个函数相应的比较安全的替换方 式。不使用 strcpy() ，使用 strncpy()不使用 strcat(),使用 strncat()不使用 sprintf() ，使用 snprintf()不使用gets(),使用fg

40、ets()在上面的前三个中函数中，每个替代函数的“n”表示了使用的缓冲区的大小。最后一个函数的“f”，表示格式，它允许用户指定期望的输入的格式。 这些替换方 程强制程序员定义使用的缓冲区的尺寸以及确定输入 的类型。格式化字符串攻击( Format String Attack )该类攻击往往与缓冲区溢出相关， 因为它们往往主要利 用了某些函数的假设，例如sprintf()和vsprintf()假设缓冲区的长度是无限的。然而即使使用snprintf()替换sprintf() 也无法完全保护程序不受格式化字符串的攻 击。这些攻击通过直接将格式说明符 (format specifiers)例如：以下的

41、代 等就是不安全函数接收缓冲区来进行。snprintf(buffer,sizeof(buffer),string)这种情况下， 可以在字符串中插入格式说明符来操纵内 存的栈， 来写入攻击者的数据 (这些数据中包含小的程 序代码，并可由处理器接着执行)。 更多关于这些攻 击的具体内容请见资源章节。 对以上的例子建议使用下 面的代码。snprintf(buffer, sizeof(buffer),“ %s” ,string)进行格式字符串攻击不太容易。 首先攻击者必须能获得 内存栈的内容情况 (或者从应用导出或者使用调试器) 然好必须知道如何精确访问特定的内存空间来操纵栈 中的变量。执行外部程序推

42、荐使用exec()函数而不是system()函数来执行外部程 序。这是因为system()接收整个命令行的随机的缓冲区 来执行程序。snprintf(buffer, sizeof(buffer), "emacs %s", filename); system(buffer);在以上的例子中，可以通过使用分号利用文件名变量在 sehll中插入额外的命令(例如文件名可以是/etc/hosts; rm *，这将在显示/etc/hosts目录文件的同时，删除目录中而exec()函数只保证第一个参数被执行：execl("usr/bin/emacs", "u

43、sr/bin/emacs", filename, NULL);上面的例子保证文件名仅仅作为一个参数输入Emacs工1.9.1.4.4具，。同样它在Emacs命令中使用完全的路径而不是使 用可以被攻击者利用的 PATH 环境变量。竞争条件( race condition ) 进程需要访问资源时 (无论是磁盘、 内存或是文件) 通 常需要执行两个步骤：(1) 首先测试资源是否空闲可用(2) 如果可用，就访问该资源，否则它等到资源不再使 用为止再去访问它当另一个进程在步骤 1和 2之间想要访问同一个资源时 就出现问题了。 这会导致不可预测的结果。 进程可能会 被锁定，或者一个进程籍此获得了

44、另一个进程的较大的 权限而导致安全问题。 攻击主要集中在有较大权限的程 序上(称为 setuid 程序)。竞争条件攻击通常利用程序 执行时可以访问到的资源。 另外权限低的程序也存在安 全风险，因为攻击者可能会等待有较高权限的用户执行 那个程序(例如root)，然后进行攻击。下面的建议有助于缓解竞争条件(race con ditio n)攻击：在进行文件操作时， 利用那些使用文件描述符的函数而 不要使用那些使用文件路径的函数(例如使用 fdopen() 而不要使用fopen()。文件描述符使得恶意的用户在 文件打开时或是在原始的进程对文件进行操作前， 无法 使用文件连接(符号式的或是物理的)来改

45、变文件。在写文件甚至在读文件时使用 fcntl() 和 flock() 函数来对 文件加锁， 这样它们就不能被其他进程访问。 它几乎可 以建立原子级的操作。谨慎操纵零时文件，因为它往往会导致竞争条件。1.9.1.4.5 检验有效的返回值检验有效的返回值非常重要。 一个例子是旧的 /bin/login 的实现中不检验错误的返回值，导致当它找不到 /etc/passwd 文件时返回 root 的访问权限。如果该文件损 坏了，那么这种情况是合理的， 但如果该文件存在只是 无法访问，那么这就是一个大问题。1.9.2 系统开发安全相关工具管理规范有许多方法来确保代码符合一定的安全级别。 正如前面指出 的

46、，最好的方法之一是让尽可能多的人来检查代码 （而不是 在 QA 环境中实际进行白箱或者黑箱测试）。然而，有时代 码在开始实际环境的应用前往往没有足够的时间， 并且即使 检查代码也会漏掉一些不容易发现的错误。 这些错误可能会 对整个系统导致重大的安全问题。 因此（以及其他的原因） ， 动进行某些检查过程很有帮助。 本文介绍了一些这方面的工c每个工具都代同样的而试工代勰存在潜在些测全工具包比较了每个工具的测试结果， 并且仔细检查了以下的属具含我。a）灵活性 有多种选项并能扫描多种类型的代码的工 具得分会较高c)b）正确性 主要目标是发现正确的安全问题，并且不 会出现大量的误报信息，或者更糟的是没有

47、发现真正 的错误信息。序”员。只除需非要特将别工需具要指，定容到易特使定用的代码大上多然数后情选况择下“，扫程 制程序。员一般只做抽样检查，而无需开发复杂的测试机d） 示报，表并且最扫好描同结时果提应示该修以改一每种个容问易题理的解方的法格，式并来附显加 理由。每个工具在解析代码上的速度可以忽略不计， 所以没有进 这方面相对于其他工具需要更多的时间）。 另外， 这些工 具都可以免费获得， 甚至可以获得它们的源代码， 所以不 需考虑它们的成本。1.9.2.1 工具一： PScanPscan是一个有针对性的扫描程序，主要用于发现C程序中的缓冲区溢出和格式化字符串攻击。该程序检查所有用 到标准C程序

48、库中的printf() 函数。sprintf(buffer, variable);printf(buffer, variable);关于这些语句在缓冲区溢出和格式化字符串攻击中怎样 被利用可以查阅相关的 C和C+文档。Pscan的一个不足 是不能发现由于越界检查不充分而引起的常规性缓冲区 溢出。不过 Pscan 对于缓冲区溢出和格式化字符串攻击的 定位还是相当精准和快速的。 Pscan 程序相对简单，它只 将结果返回都标准输出，当然也可以将其输出到文件，并 且除了说明程序员应该怎样修正错误以外不给出语句为 什么出错等类似的信息。该工具一个显著的特点是可以同 时扫描多个文件。总体而言 Pscan

49、 程序相对简单，易于使用，同时针对性很 强，但是由于它能够适用的范围过于狭窄因此一般不推荐 其在大型商业应用中使用，而只是检查一些相对简单的程 序片断。1.9.2.2 工具二： FlawfinderFlawfinder 是一个分析 C 程序安全隐患的静态分析工具。和Pscan类似，该程序可以发现很多种类型的错误，除了 printf() 和标准的字符串函数，它还可以发现竞争条件和系统调用。Flawfinder相比较Pscan,它返回的错误信息要丰 富很多，并且也更加详细。 而这对于程序员来说非常重要。 Flawfinder 甚至可以对程序中的弱点进行分类， 例如 buffer 弱点、格式弱点、

50、shell 弱点等。总之， Flawofinder 是一个相当出色的 C 程序检查工具， 速 度会，界面友好，返回信息丰富，安装使用相对简单。该 工具是检查不同规模的应用程序的首选，唯一不足的是它 只能用于 C 程序的检查。1.9.3 控制软件代码程序库1.9.3.1 管理运作程序库我们通常将用于系统开发的开发软件工具和开发平台称之为运作程序，因此为了降低计算机程序被破坏的可能 性，应对运作程序库的访问进行严格的控制：a) 严格的管理在开发设备上的存放开发运作程序的目 录。如果开发运作程序没有很好的保护，会造成系统 及其设置会遭到未经授权的访问并造成系统的安全性 可靠性大大下降。b) 只有指定

51、的人员如程序库管理员经过适当的管理授权 后才可以访问运作程序库，对运作程序库的访问必须 结合进行严格的访问控制技术手段和双重访问控制机 制。1.9.3.1.1 严格的访问控制可以通过以下规定实现：a) 严格管理开发部门所在区域的安全保安管理，防止未 经授权的人进入开发区域。b) 严格管理开发用途的计算机使用，只有指定的人员才 可以访问开发用的计算机设备。c) 严格管理开发运作系统的认证管理，建立严格的基于 人员职责的授权等级制度，用口令或其他身份识别技 术确认访问者身份。1.9.3.1.2 建立双重访问控制机制双重访问控制机制就是对运作程序库的管理需要两个 人同时进行认证才可以通过的方式。比如

52、对运作程序库 进行更改或删除需要两个人进行口令认证系统才允许 进行以上操作。其总需要进行认证的两个人彼此不知道 对方的认证口令或步骤。因此该认证过程必须两个人同 时在场进行操作才可以。1.9.3.2 管理源程序库我们通常将直接由程序设计语言编制而成的程序称之为 源程序。源程序的语言需要通过相应的语言处理程序翻译 成机器语言程序后才可以在计算机上运行。因此源程序包 含了系统及其控制如何实现的细节，为未授修改系统提供 了很好的切入点，例如设置逻辑炸弹。且如果缺少源程序 代码会使得今后应用系统的维护工作十分困难甚至无法 完成。因此为了降低计算机程序被破坏的可能性，应对源 程序库的访问进行严格的控制：

53、a) 严格的管理在开发设备上的存放源程序的目录。如果 源程序没有很好的保护，会造成系统及其设置会遭到 未经授权的访问并造成系统的安全性可靠性大大下 降。b) 只有指定的人员如程序库管理员经过适当的管理授权 后才可以访问源程序库，对源程序库的访问必须结合 进行严格的访问控制技术手段和双重访问控制机制。c) 各项应用均应当指定相应的管理员。d) 信息技术支持人员 ( 非开发人员 ) 不应当自由的访问源 程序库。e) 源程序库和运作程序库尽量分开存放并且分开管理。f) 源程序库和运行的应用系统尽量分开存放且分开管 理。g) 源程序库的更新和向程序员发布的源程序应当由指定 的管理员根据一定的授权进行，

54、不得私自自行更新或/x发放。h) 应当保存所有对源程序库进行访问读取或修改的日志 纪录，以便于日后审核。1.9.4 在软件开发过程变更管理规范b)对了于有敏效感的的进应行用控系制统，的组更织改应应当建由另立更一改人员控进制审行批检程查，序为，对更改的申请、评审、测试、批准、更改的计划的提出a) 系统容易受到更改的攻击，即使是完全授权的更改也可 能存在破坏性的影响，存在数据完整性的损失、应用系 统的不可用以及机密信息的泄漏的风险。为了使信息系 统的损失降至最小，组织应对更改进行严格的控制，就 是在系统开发的每一个阶段(可行性研究、需求分析、 设计、编码、测试、培训等)的每一个更改实施前经过 组织

55、的评审与授权 和程实序施不提被出损明害确，要程求序并设严计格人的员只实施能访，问确保他安们工全作性所与控必制需的部分，确保任何的改动都是经过审批的。c) 更改的程序建议如下：清晰确认所有的需要更改的应用系统、信息、数据 库和相关的硬件设备。的清需晰的求确或认开发更上改的的原需因求 )(业务上的具体流程和具体由授权的用户提交更改的申请。保留相关的授权登记记录。过在正正式式的的实批准施。之前评，审更的改的方案必须经过评审并通 确容保。授权的用户在实施之前确认并接受更改的内确保在实施的过程中，尽量的减少对现行的商务运 作系统的影响。确保建立的文件系统在完成各项更改时得到修改， 旧文件被很好的归档或处

56、置。保证所有的应用系统升级的版本的控制。确保所有的更改情求的审核跟踪。确保用户使用手册作相应的必要的更改。 确保更改的实施选择了适当的时机以确保更改的实 施不会干扰正常的商务运作。1.9.5 开发版本管理规范1.9.5.1 控制程序清单a) 在任何时候对于程序清单必须进行严格的控制并且及 时地进行更新。c)b) 对应用系统开发源程序的打印的资料、电子版本或者 是相关的报告都必须进行控制，纸质的文件应当保存 在一个安全的环境下，如保险柜等。电子文档则应当 进行一定的加密。源程序相关信息可以帮助我们确认系统问题的根源， 并且一旦掌握了系统源程序相关信息可以清楚地了解 系统的运行逻辑和可能的薄弱点。对系统的安全有很 大的影响。1.9.5.2 版本升级控制规范a) 应用系统软件开发版本升级申请，当软件的版本由于 更新，修改等操作需要升级时必须先向相关负责人员 提交申请。b) 应用系统软件版本升级测试，对升级的应用系统进行 测试，确认系统的各种安全特性。c) 应用系统软件版本审批，确认对应用系统的版本的升 级，此时需确认当前的版本为最新的版本，旧的版本 需进行归档，不得随意丢弃或删除。d) 应用系统软件版本升级计划，制定相关的升级计划， 确保将