项目应用系统开发安全管理规范标准

1、WORD 专业资料. WORD 专业资料. 文档编号：项目应用开发等级保护规密级：项目部项目应用系统开发安全管理规（信息系统等级保护三级）DATE EEEE年O月 * MERGEFORMAT二二一年一月编 号 应用开发等级保护规密 级项目部 阶 段项目设计阶段 页 数代号 名称建设单位承建单位会 签编 写校 对审 核标 审批 准关于本文档说明：类型创建（C）、修改（U）、删除（D）、增加（A）；目 录TOC o 1-3 h z uHYPERLINK l _Toc331408056第1章 概述 PAGEREF _Toc331408056 h 1HYPERLINK l _Toc3314080571

2、.1目标 PAGEREF _Toc331408057 h 1HYPERLINK l _Toc3314080581.2适用围 PAGEREF _Toc331408058 h 1HYPERLINK l _Toc3314080591.3规引用的文件或标准 PAGEREF _Toc331408059 h 2HYPERLINK l _Toc3314080601.4术语和定义 PAGEREF _Toc331408060 h 2HYPERLINK l _Toc3314080611.5应用系统开发总体原则 PAGEREF _Toc331408061 h 3HYPERLINK l _Toc331408062第2

3、章 系统需求收集和分析阶段 PAGEREF _Toc331408062 h 5HYPERLINK l _Toc3314080632.1可行性研究分析 PAGEREF _Toc331408063 h 5HYPERLINK l _Toc3314080642.1.1技术可行性分析 PAGEREF _Toc331408064 h 5HYPERLINK l _Toc3314080652.1.2需求可行性分析 PAGEREF _Toc331408065 h 5HYPERLINK l _Toc3314080662.1.3投资可行性分析 PAGEREF _Toc331408066 h 5HYPERLINK l

4、 _Toc3314080672.1.4影响可行性分析 PAGEREF _Toc331408067 h 5HYPERLINK l _Toc3314080682.2开发人员安全管理 PAGEREF _Toc331408068 h 6HYPERLINK l _Toc3314080692.2.1系统开发人员职责分配 PAGEREF _Toc331408069 h 6HYPERLINK l _Toc3314080702.2.2开发人员授权 PAGEREF _Toc331408070 h 6HYPERLINK l _Toc3314080712.2.3开发人员必须训练开发安全代码的能力 PAGEREF _T

5、oc331408071 h 6HYPERLINK l _Toc3314080722.2.4分离系统开发和运作维护 PAGEREF _Toc331408072 h 7HYPERLINK l _Toc3314080732.3建立系统开发安全需求分析报告 PAGEREF _Toc331408073 h 7HYPERLINK l _Toc331408074第3章 系统设计阶段的安全规 PAGEREF _Toc331408074 h 8HYPERLINK l _Toc3314080753.1单点访问控制且无后门 PAGEREF _Toc331408075 h 8HYPERLINK l _Toc33140

6、80763.2人员职责和权限的定义 PAGEREF _Toc331408076 h 8HYPERLINK l _Toc3314080773.3确保敏感系统的安全性 PAGEREF _Toc331408077 h 8HYPERLINK l _Toc3314080783.4确保访问层的安全性 PAGEREF _Toc331408078 h 8HYPERLINK l _Toc3314080793.5确保日志管理机制健全 PAGEREF _Toc331408079 h 8HYPERLINK l _Toc3314080803.6新系统的容量规划 PAGEREF _Toc331408080 h 9HYPE

7、RLINK l _Toc331408081第4章 系统开发阶段安全规 PAGEREF _Toc331408081 h 10HYPERLINK l _Toc3314080824.1系统开发语言 PAGEREF _Toc331408082 h 10HYPERLINK l _Toc3314080834.1.1通用规 PAGEREF _Toc331408083 h 10HYPERLINK l _Toc3314080844.1.2Perl语言 PAGEREF _Toc331408084 h 11HYPERLINK l _Toc3314080854.1.3Java语言 PAGEREF _Toc331408

8、085 h 13HYPERLINK l _Toc3314080864.1.4C/C+语言 PAGEREF _Toc331408086 h 14HYPERLINK l _Toc3314080874.2系统开发安全相关工具管理 PAGEREF _Toc331408087 h 17HYPERLINK l _Toc3314080884.2.1工具一：Pscan PAGEREF _Toc331408088 h 18HYPERLINK l _Toc3314080894.2.2工具二：Flawfinder PAGEREF _Toc331408089 h 18HYPERLINK l _Toc331408090

9、4.3控制软件代码程序库 PAGEREF _Toc331408090 h 19HYPERLINK l _Toc3314080914.3.1管理运作程序库 PAGEREF _Toc331408091 h 19HYPERLINK l _Toc3314080924.3.2管理源程序库 PAGEREF _Toc331408092 h 19HYPERLINK l _Toc3314080934.4在软件开发过程变更管理 PAGEREF _Toc331408093 h 20HYPERLINK l _Toc3314080944.5开发版本管理 PAGEREF _Toc331408094 h 21HYPERLI

10、NK l _Toc3314080954.5.1控制程序清单 PAGEREF _Toc331408095 h 21HYPERLINK l _Toc3314080964.5.2版本升级控制 PAGEREF _Toc331408096 h 21HYPERLINK l _Toc3314080974.5.3版本变更控制 PAGEREF _Toc331408097 h 22HYPERLINK l _Toc3314080984.6开发日志审核管理 PAGEREF _Toc331408098 h 22HYPERLINK l _Toc3314080994.6.1开发日志定期审计 PAGEREF _Toc3314

11、08099 h 22HYPERLINK l _Toc3314081004.6.2开发人员权限定期审计 PAGEREF _Toc331408100 h 22HYPERLINK l _Toc3314081014.7防御后门代码或隐藏通道 PAGEREF _Toc331408101 h 22HYPERLINK l _Toc3314081024.7.1后门代码和隐藏通道介绍 PAGEREF _Toc331408102 h 22HYPERLINK l _Toc3314081034.7.2防御后门代码和隐藏通道的相关办法 PAGEREF _Toc331408103 h 23HYPERLINK l _Toc

12、331408104第5章 系统测试阶段安全规 PAGEREF _Toc331408104 h 24HYPERLINK l _Toc3314081055.1应用系统的安全性检测 PAGEREF _Toc331408105 h 24HYPERLINK l _Toc3314081065.1.1设计详细的测试计划、测试围、测试方法和测试工具 PAGEREF _Toc331408106 h 24HYPERLINK l _Toc3314081075.1.2测试种类 PAGEREF _Toc331408107 h 24HYPERLINK l _Toc3314081085.1.3在测试的过程中详细描述每个和测

13、试方案相关的测试步骤和测试数据 PAGEREF _Toc331408108 h 26HYPERLINK l _Toc3314081095.2控制测试环境 PAGEREF _Toc331408109 h 26HYPERLINK l _Toc3314081105.3为测试使用真实的数据 PAGEREF _Toc331408110 h 26HYPERLINK l _Toc3314081115.4在软件转移至生产环境前进行测试 PAGEREF _Toc331408111 h 27HYPERLINK l _Toc3314081125.5应用系统安全质量鉴定 PAGEREF _Toc331408112 h

14、 27HYPERLINK l _Toc331408113第6章 系统培训与文档阶段安全规 PAGEREF _Toc331408113 h 28HYPERLINK l _Toc3314081146.1新系统的培训 PAGEREF _Toc331408114 h 28HYPERLINK l _Toc3314081156.2撰写新系统和系统改进的文档 PAGEREF _Toc331408115 h 28HYPERLINK l _Toc331408116第7章 应用系统开发外包安全控制 PAGEREF _Toc331408116 h 29HYPERLINK l _Toc331408117第8章 附录

15、PAGEREF _Toc331408117 h 30HYPERLINK l _Toc3314081188.1参考文献 PAGEREF _Toc331408118 h 30HYPERLINK l _Toc3314081198.2本规用词说明 PAGEREF _Toc331408119 h 32HYPERLINK l _Toc3314081208.2.1为便于在执行本规条文时区别对待，对要求严格程度不同的用词说明如下： PAGEREF _Toc331408120 h 32HYPERLINK l _Toc3314081218.2.2条文中指定应按其它有关标准、规执行时，写法为“应符合的规定”或“应按

16、要求（或规定）执行”。 PAGEREF _Toc331408121 h 32概述信息系统的许多的安全控制或其他安全性保证是通过系统的开发设计予以实现的。因此如果在系统的开发设计阶段没有对系统的安全性给予充分的考虑，那么系统本身一定会存在许多先天不足，系统就会漏洞百出。为确保应用系统的安全，在应用系统开发之前就应确认系统的安全需求，并以此作为开发设计的阶段的基础。本规主要规定了在系统开发的各个阶段所应遵守的各种安全规，从需求分析开始，到设计，再到开发和维护以与最后的文档等系统开发的各个阶段分别进行阐述，并将在不同阶段中所需要注意的安全问题和相关的安全规进行进一步的描述和规定。目标保护应用系统开发

17、过程的安全。具体地说就是保护应用系统开发过程免受未经授权的访问和更改，保护系统开发中系统软件和信息的安全，确保开发项目顺利正确的实施并对开发环境进行严格的控制。同时确保应用系统开发外包中的各项安全。适用围本套规适用的围包括了整个应用系统开发过程中的安全。包括了系统开发可行性和需求分析阶段的安全，系统设计阶段的安全，系统开发阶段的安全，系统测试阶段的安全，系统培训和文档阶段的安全以与系统开发外包的安全规。主要规定了应用系统开发过程的安全，软件的质量的要求，系统和业务需求的符合性，保证敏感信息的安全，系统本身的稳定性和兼容性问题。规引用的文件或标准下列文件中的条款通过本标准的引用而成为本标准的条款

18、。凡是不注日期的引用文件，其最新版本适用于本标准。GB17859-1999 计算机信息系统安全保护等级划分准则GB/T 9387-1995 信息处理系统 开放系统互连基本参考模型（ISO7498 :1989）GA/T 391-2002 计算机信息系统安全等级保护管理要求ISO/IEC TR 13355 信息技术安全管理指南NIST信息安全系列美国国家标准技术院英国国家信息安全标准BS7799信息安全基础保护IT Baseline Protection Manual (Germany)BearingPoint Consulting 部信息安全标准RU Secure安全技术标准信息系统安全专家丛书

19、Certificate Information Systems Security Professional术语和定义访问控制access control 一种安全保证手段，即信息系统的资源只能由被授权实体按授权方式进行访问，防止对资源的未授权使用。应用系统 application system认证 authentication a. 验证用户、设备和其他实体的身份； b. 验证数据的完整性。授权authorization 给予权利，包括信息资源访问权的授予。可用性availability 数据或资源的特性，被授权实体按要求能与时访问和使用数据或资源。缓冲器溢出 buffer overflow指

20、通过往程序的缓冲区写超出其长度的容，造成缓冲区的溢出，从而破坏程序的堆栈，使程序转而执行其它指令，以达到攻击的目的。性confidentiality 数据所具有的特性，即表示数据所达到的未提供或未泄露给未授权的个人、过程或其他实体的程度。隐藏通道 covert channel 可用来按照违反安全策略的方式传送!数据的传输信道。完整性integrity在防止非授权用户修改或使用资源和防止授权用户不正确地修改或使用资源的情况下,信息系统中的数据与在原文档中的一样，并未遭受偶然或恶意的修改或破坏时所具的性质。敏感信息 sensitive information 由权威机构确定的必须受保护的信息，因为

21、该信息的泄露、修改、破坏或丢失都会对人或事产生可预知的损害。系统测试 system testing用于确定系统的安全特征按设计要现的过程。这一过程包括现场功能测试、渗透测试和验证。后门代码 trapdoor 通常为测试或查找故障而设置的一种隐藏的软件或硬件机制，它能避开计算机安全。而且它能在非常规时间点或无需常规检查的情况下进入程序。特洛伊木马Trojan horse一种表面无害的程序，它包含恶性逻辑程序，导致未授权地收集、伪造或破坏数据，以此破坏计算机安全与完整性的进程。验证 verification 将某一活动、处理过程或产品与相应的要求或规相比较。例：将某一规与安全策略模型相比较，或者将

22、目标代码与源代码相比较。压力测试 于确定系统的薄弱环节，确定系统在非正常条件下能够迅速恢复到正常的运行状态的能力。应用系统开发总体原则应用系统的开发应遵循一系列的总体原则，以确保开发过程中的安全。其中包括：系统开发应从业务需求的角度出发，不得盲目追求系统的先进性而忽略了系统的实用性。系统的开发是为了更好地满足业务上的需要，而不是技术上的需要。开发的方法和管理必须规化、合理化、制度化，从而确保开发的质量和进度。应保证开发的进度并按时完成。确保开发工作与时、有效且高质量的完成。系统开发必须具有一定的前瞻性，符合主流系统的发展方向。提高和加强开发人员的安全意识。确保信息和关键技术不会泄漏，特别是不可

23、泄漏到竞争对手的手中，否则将会对公司的竞争力产生极大的影响。应充分利用现有的资源。系统需求收集和分析阶段可行性研究分析对于应用系统开发项目应进行一定的可行性分析，以保证只有在确认具备了相当的资源和条件，并且有能力满足业务上的需求的情况下才能开展开发工作。切忌盲目开发，否则既浪费资源，又浪费时间。可行性研究宜从技术、需求面、投入和影响四个方面进行考虑：技术可行性分析根据业务上提出的需求，从技术开发的角度分析现有的技术手段和技术能力是否能够实现业务上所要求的系统功能。通常可从以下三个方面进行分析：人员技术能力分析，指公司的系统开发队伍或外包的第三方开发公司是否具有足够技术和管理能力来完成系统开发的

24、任务。计算机软件和硬件分析，指公司现有的软件和硬件的性能是否足够满足开发相应的系统的要求。管理能力分析，指现有的技术开发管理制度和管理流程是否成熟且标准化，是否满足系统开发的要求。需求可行性分析系统的开发来源于业务上的需求，因此需要对该需求进行可行性分析，以判断需否明确，是否符合实际，是否在一定的时间围可以实现。投资可行性分析根据业务需求和技术手段的分析，确认实现系统开发所需的投资，并确认投资的数额是否在可控制和可承受的围。影响可行性分析所谓的影响是指社会影响，比如系统开发是否符合法律法规上的要求，是否和相关的管理制度或行业标准相抵触，是否符合人文或道德上的约束等。开发人员安全管理系统开发人员

25、职责分配在系统开发的过程中，应明确不同人员的身份和职责。在系统开发过程中具体可分以下三种角色：项目负责人员：确保在整个系统开发的各个阶段都实施了相关的安全措施，同时在整个系统开发的过程中负责整个项目的开发安全管理。系统开发人员：根据业务需求确保开发的系统能够满足业务上的需求和相应的安全上的需求，同时满足系统质量上和进度上的要求。系统审核人员：对整个开发的过程进行审核和监督，确保开发的质量和开发的安全。开发人员授权应根据该员工在整个开发项目中所负责的开发容授予其相应的权限和所应承担的责任。开发人员必须负责其开发容的性，不得私自将开发的相关信息泄漏出去，即使对家人或开发团队中的其他开发人员也不得泄

26、漏。但开发人员有责任将开发的相关信息告诉项目的负责人员或开发小组的负责人员。以书面的方式将员工的权限和相应的责任提交给员工本人。必须严格规定在为企业工作期间，所有和工作相关的开发成果的所属权都归企业所有。应根据员工权限和责任的大小确认是否需要签署相关的协议。应在日常工作中记录员工与开发相关的日志信息。员工一旦离职或调动岗位应立即收回或调整其相应的权限。开发人员必须训练开发安全代码的能力在整个开发的过程中必须完整持续地进行代码错误处理所规定的流程。错误问题报告应力求通俗易懂，不应在其中包含任何系统细节问题。应对重要的敏感信息进行加密保护。应使用一些相对复杂的加密和密钥生成机制。应单独编写安全性设

27、计说明概要分离系统开发和运作维护管理层必须确保应用系统的开发和运作管理从组织人事和权限职责上分开。信息技术人员可以现场修复或更改偶然或恶意的数据和软件问题。测试代码中往往包含调试或者查错代码，大大增加了主机系统的性能负担。开发人员不应具有很高的权限，否则将在系统运行中产生很大的风险。建立系统开发安全需求分析报告安全需求计划应能够达到期望的安全水平。其中包括了成本的预估，完成各个安全相关流程所需的时间。所有关于应用系统的更新或改进都必须基于业务需求，并有业务事件支持。这里的业务需求不仅仅包括了系统的功能、性能、开发费用、开发周期等容，应明确系统的安全要求。应用系统的任何一次改进或更新都应和该业务

28、系统的所有者密切相关。开发安全需求分析计划应由开发项目经理和公司部的安全小组共同商议决定。应确保每一个应用系统的用户都意识到系统的更新或改进都与其自身密切相关，所有的更新或改动建议都必须基于业务需求，而不是基于所谓的“信息技术的要求”。系统的每一次更新或改进都必须认真对待，必须进行详细的需求定义、需求分析以与测试评估，以保证不会对业务造成任何不良影响。业务需系统更新和改动的基础，因此必须清晰明确地定义业务的需求，禁止在业务需求未经业务部门领导和主要负责人员认可的情况下，盲目地进行开发工作。系统设计阶段的安全规单点访问控制且无后门任何用户如果希望访问应用系统中的某一部分，则必须通过统一且唯一的认

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

30、主机和客户端之间通讯的安全性、服务器和服务器间通讯的安全性，以与本地系统和异地系统之间通讯的安全性。确保日志管理机制健全应建立可根据情况自由设置的日志管理机制，也就是说日志记录的围和详细程度可以根据需求自行定制，且可以实现在应用系统的使用过程中进行日志的定制和记录。保留所有与系统开发相关的程序库的更新审核记录。新系统的容量规划容量规划是指确定系统的总体规模、性能和系统弹性。容量规划的具体容可能有所不同，但一般应考虑以下方面：系统的预期存储容量和在给定的周期中获取生成和存储的数据量。在线进程的数量和估计可能的占用资料系统和网络的响应时间和性能，即端对端系统系统弹性要求和设计使用率（峰值，槽值和平

31、均值等）安全措施如加密解密数据对系统的影响。24x7运作要求和可接受的系统宕机次数（维护或者设备更新导致的必须性宕机）规划容量的时候关于系统使用的信息了解的越多越好。近来，由于互联的使用以指数形式增长，容量规划的变动效果不是非常显著，有时甚至毫无用处。原因在于很难估计实际的负载。在容量估计的时候应尽量将情况设想得复杂一些。系统开发阶段安全规系统开发语言程序员可使用很多指导规来防止应用程序中的普通安全问题。其中许多可以应用于任何一种编程语言，但某些是针对特定的语言的。特定语言的指导规主要集中在Perl，Java和C/C+语言。大多数情况下，一般的错误可以避免。而这些本可以避免的错误常常会导致很多

32、安全漏洞，从而威胁信息的性、完整性和可用性。通用规输入验证在客户机/服务器环境下，进行服务端的验证而不是客户端的验证（例如基于Javascript的验证）。通过在客户端和服务器之间放置一个代理服务器，可以很容易绕过客户端验证。有了代理服务器，攻击者可以在数据被客户端“验证”后修改数据（与“man-in-the-middle”攻击类似）。在实际的校验中，输入校验首先定义一个有效（可接受）的字符集，然后检查每个数据的字符是否在有效围。如果输入中包含无效的字符，应用程序应返回错误页面并说明输入中包含无效字符。这样进行验证的原因是定义无效的字符集比较困难，并且一些不应有效的字符通常不会被指出。边界检查

33、（例如字符串的最大长度）应在字符有效性检查以前进行。边界分析可以防止大多数缓冲区溢出漏洞。从环境变量获得的数据也需要进行验证。同时避免在环境变量中存放敏感数据（例如密码）。某些Unix系统（例如FreeBSD）包含ps命令，可以让用户看到任何当前进程的环境变量，这常常会暴露性信息。SQL语句如果应用程序需要连接后端数据库，不得在代码中使用SQL语句。使用程序以外的嵌入在代码中的SQL语句调用特别危险，难以防止攻击者使用输入域或者配置文件（由应用程序载入）来执行嵌入式的SQL攻击。而输入验证有助于缓解这种风险。注释代码(commented code)当应用程序在实际环境中开始应用时，应删除所有的

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

35、）。这些信息可以在攻击时使用。例如下面就是一个不安全的URL：.xyzcompany./index.cgi?username=USER&password=PASSWORD&file=/home/USER/expenses.txt设置PATH变量设置PATH为一个已知的值，而不仅仅是使用启动时的缺省值。攻击者可以在攻击应用程序时使用PATH变量，例如试图执行一个任意的程序。这些也可以应用于大多数其他的语言。Perl语言多年以来，Perl已经成为用于系统管理和Web CGI开发的功能最强的编程语言之一（几乎可以使用Perl实现任何功能）。但其扩展应用，即作为Internet上CGI的开发工具，使得

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

37、证可以通过在命令行参数加入“-T”来开启。例如可以Perl脚本的第一行这样加入“-T”：#!usr/bin/perl5 -T Tainted数据包括命令行参数、环境变量和来自文件的数据。引用tainted数据的变量也成为tainted数据。如果脚本试图通过不安全的方式来使用tainted数据会产生一个致命错误（对这种情况称为“不安全的依赖”(Insecure dependency)或者其他的说法）。启用tainted验证在有些情况下会导致脚本停止运行，常常是由于Perl解释器要求所有脚本引用的外部程序的完全路径必须在PATH环境变量中列出，同时PATH中包含的每个目录除了目录的所有者与相应的所

38、有者用户组外无法修改。Taint验证对于环境比较敏感，这就可能会导致大多数程序员不愿使用它，但是只要可能就应使用taint验证，特别是代码执行其他程序功能时（例如在CGI脚本的情况下）。安全模块如果不但输入数据不可信而且实际的代码也不可信会产生什么情况？例如用户从上下载了一个ActiveX控件，而它实际是一个特洛伊木马(Trojan horse)。这种情况下taint验证就不起作用。安全模块让程序员可以在Perl脚本中将不同的代码模块与安全对象相联系。每个安全对象对于运行的每块代码建立了一个限制的环境。这与chroot在一个进程中只能在整体目录结构的一个子目录中运行类似。而saft对象限制pe

39、rl代码只能在perl包结构的某些特定包中运行。如何使用安全模式超出了本文的围，但程序员应在任何时候使用这一功能。警告参数(-w)使用-w参数可以在Perl解释脚本时显示所有的警告信息。警告可以对以下情况产生：只使用了一次的变量或者完全没有使用过的变量，未定义的文件句柄，未关闭的文件句柄，或将非数值变量传递到数据变量。该功能不是针对安全处理的，但是有助于调试直接或者间接对安全有危害的错误。一般推荐总是使用-w参数。可在taint验证时在第一行这样使用-w参数：#!usr/bin/perl5 TwJava语言自从1995年发布以来，Java成为简单或者复杂网络应用的有效编程语言。它在设计时充分考

40、虑了安全问题，因此它具有的限制特征有：收集不再使用的存碎片的垃圾收集器，严格的“sandbox”安全模型，以与在特定主机上限制应用程序的活动的安全管理器。以下为使用中的相关的规：不应在标准输出上打印消息在实际的Internet系统中避免使用System.out.println()或者System.err.println()打印日志和错误消息，原因是当消息打印到标准输出时，无法立即确定消息发生的地点，且有可能将敏感信息透露给攻击者。封装Java中，如果没有使用访问标识符(access modifier(private、protected或public)来声明类、方法和属性，那么它的默认访问围是包

41、，并且同一包中的所有类都能访问它。必须记住虽然包有封装功能，但它只有在每部分加载到包的代码都由授权用户控制时才起作用。恶意的用户可以加入他们自己的类，从而对于包中的所有类、方法和属性都有完全的访问权限。Java的政策文件支持两种控制包访问权限的前缀。accessClassInPackage defineClassInPackage 所有标准库中的类都默认是可以公共访问的（除了由“sun”开头的类）。为了保证一个包的安全性，必须修改$JAVA HOME/jre/lib/security文件夹中的java.security文件。该文件中的重要行是：package.access=sun.虽然该方法有

42、作用，但仍存在问题。例如程序员在java.security文件中定义包的安全时必须十分小心。在package.access中的值是字符型的，“sun.”将保护“sun.tools”等包，但是不会对“sun”或者“sunshine”等包进行保护。另一个方法是使用JAR密封(sealing) 。JAR(Java ARchive)文件是一些类的打包压缩格式的文件，与常用的ZIP格式类似。如果从一个密封(sealing)的JAR文件中加载一个类，随后同一个包的类只能从该JAR文件加载。为了起用密封(sealing)，必须在建立JAR文件时这样设置密封(seal)参数：Sealed: true 使用密封

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

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

45、”，表示格式，它允许用户指定期望的输入的格式。这些替换方程强制程序员定义使用的缓冲区的尺寸以与确定输入的类型。格式化字符串攻击（Format String Attack）该类攻击往往与缓冲区溢出相关，因为它们往往主要利用了某些函数的假设，例如sprintf()和vsprintf()假设缓冲区的长度是无限的。然而即使使用snprintf()替换sprintf()也无法完全保护程序不受格式化字符串的攻击。这些攻击通过直接将格式说明符（format specifiers）(%d，%s，%n等)传递到输出函数接收缓冲区来进行。例如，以下的代码就是不安全的：snprintf(buffer, sizeof

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

47、区来执行程序。snprintf(buffer, sizeof(buffer), emacs %s, filename); system(buffer);在以上的例子中，可以通过使用分号利用文件名变量在sehll中插入额外的命令（例如文件名可以是/etc/hosts; rm *，这将在显示/etc/hosts目录文件的同时，删除目录中的所有文件）。而exec()函数只保证第一个参数被执行：execl(usr/bin/emacs, usr/bin/emacs, filename, NULL);上面的例子保证文件名仅仅作为一个参数输入Emacs工具，同样它在Emacs命令中使用完全的路径而不是使用可

48、以被攻击者利用的PATH环境变量。竞争条件（race condition）进程需要访问资源时（无论是磁盘、存或是文件）通常需要执行两个步骤：首先测试资源是否空闲可用如果可用，就访问该资源，否则它等到资源不再使用为止再去访问它当另一个进程在步骤1和2之间想要访问同一个资源时将出现问题，导致不可预测的结果。进程可能会被锁定，或者一个进程籍此获得了另一个进程的较大的权限而导致安全问题。攻击主要集中在有较大权限的程序上（称为setuid程序）。竞争条件攻击通常利用程序执行时可以访问到的资源。另外权限低的程序也存在安全风险，因为攻击者可能会等待有较高权限的用户执行那个程序(例如root)，然后进行攻击。

49、下面的建议有助于缓解竞争条件(race condition)攻击：在进行文件操作时，利用那些使用文件描述符的函数而不使用那些使用文件路径的函数（例如使用fdopen()而不要使用fopen()）。文件描述符使得恶意的用户在文件打开时或是在原始的进程对文件进行操作前，无法使用文件连接（符号式的或是物理的）来改变文件。在写文件甚至在读文件时宜使用fcntl()和flock()函数来对文件加锁，这样它们就不能被其他进程访问。它几乎可以建立原子级的操作。应谨慎操纵临时文件，因为它往往会导致竞争条件攻击。检验有效的返回值检验有效的返回值非常重要。一个例子是旧的/bin/login的实现中不检验错误的返回

50、值，导致当它找不到/etc/passwd文件时返回root的访问权限。如果该文件损坏了则这种情况是合理的；但如果该文件存在只是无法访问，那么这就是一个大问题。系统开发安全相关工具管理有许多方法来确保代码符合一定的安全级别。正如前面指出的，最好的方法之一是让尽可能多的人来检查代码（而不是在QA环境中实际进行白箱或者黑箱测试）。然而，有时代码在开始实际环境的应用前往往没有足够的时间，并且即使检查代码也会漏掉一些不易发现的错误。这些错误可能会对整个系统导致重大的安全问题。因此（以与其他的原因），使用源码分析工具(Source Code Analysis Tool(SCAT)来自动进行某些检查过程很有

51、帮助。本文介绍了一些这方面的工具。每个工具都用同样的测试工具来检验，这些测试工具包含C和Java的代码段，而这些代码段存在潜在的安全错误。我们比较了每个工具的测试结果，并且仔细检查了以下的属性：灵活性 有多种选项并能扫描多种类型的代码的工具得分会较高。正确性 主要目标是发现正确的安全问题，并且不会出现大量的误报信息，或者更糟的是没有发现真正的错误信息。容易使用 大多数情况下，程序员只需将工具指定到特定的代码上然后选择“扫描”。除非特别需要，程序员一般只做抽样检查，而无需开发复杂的测试机制。报表 扫描结果应以一种容易理解的格式来显示，并且最好同时提示修改每个问题的方法，并附加理由。每个工具在解析

52、代码上的速度可以忽略不计，所以没有进行比较（虽然这并不包括配置扫描的时间，而MOPS在这方面相对于其它工具需要更多的时间）。另外，这些工具都可以免费获得，甚至可以获得它们的源代码，所以不需考虑它们的成本。工具一：PscanPscan是一个有针对性的扫描程序，主要用于发现C程序中的缓冲区溢出和格式化字符串攻击。该程序检查所有用到标准C程序库中的printf()函数。sprintf(buffer, variable); printf(buffer, variable); 关于这些语句在缓冲区溢出和格式化字符串攻击中怎样被利用可以查阅相关的C和C+文档。Pscan的一个不足是不能发现由于越界检查不充

53、分而引起的常规性缓冲区溢出。但Pscan对于缓冲区溢出和格式化字符串攻击的定位还是相当精准和快速的。Pscan程序相对简单，它只将结果返回标准输出，当然也可以将其输出到文件，并且除了说明程序员应怎样修正错误以外，不给出语句为什么出错等类似信息。该工具一个显著的特点是可以同时扫描多个文件。总体而言Pscan程序相对简单，易于使用，同时针对性很强，但是由于它能够适用的围过于狭窄因此一般不推荐其在大型商业应用中使用，而只是检查一些相对简单的程序片断。工具二：FlawfinderFlawfinder是一个分析C程序安全隐患的静态分析工具。和Pscan类似，该程序可以发现很多种类型的错误，除了print

54、f()和标准的字符串函数，它还可以发现竞争条件和系统调用。Flawfinder相比较Pscan，它返回的错误信息要丰富很多，并且也更加详细。而这对于程序员来说非常重要。Flawfinder甚至可以对程序中的弱点进行分类，例如buffer弱点、格式弱点、shell弱点等。 Flawofinder是一个相当出色的C程序检查工具，速度会，界面友好，返回信息丰富，安装使用相对简单。该工具是检查不同规模的应用程序的首选，唯一不足的是它只能用于C程序的检查。控制软件代码程序库管理运作程序库我们通常将用于系统开发的软件工具和开发平台称之为运作程序，因此为了降低计算机程序被破坏的可能性，应对运作程序库的访问进

55、行严格的控制：严格的管理在开发设备上的存放开发运作程序的目录。如果开发运作程序没有很好的保护，则系统与其设置可能遭到未经授权的访问，并造成系统的安全性可靠性大大下降。只有指定的人员如程序库管理员经过适当的管理授权后，才可以访问运作程序库，对运作程序库的访问必须结合严格的访问控制技术手段和双重访问控制机制。严格的访问控制可以通过以下规定实现严格管理开发部门所在区域的保安管理，防止未经授权的人进入开发区域。严格管理开发用途的计算机使用，只有指定的人员才可以访问开发用的计算机设备。严格管理开发运作系统的认证管理，建立严格的基于人员职责的授权等级制度，用口令或其它身份识别技术确认访问者身份。建立双重访

56、问控制机制双重访问控制机制就是对运作程序库的管理需经两个人同时进行认证后才可通过的方式。比如对运作程序库进行更改或删除需要两个人进行口令认证，系统才允许进行以上操作。需要进行认证的两个人彼此不知道对方的认证口令或步骤。因此该认证过程必须两个人同时在场才可进行操作。管理源程序库源程序包含了系统与其控制如何实现的细节，为修改系统提供了很好的切入点，例如设置逻辑炸弹。且如果缺少源程序代码会使得今后应用系统的维护工作十分困难甚至无法完成。因此为了降低计算机程序被破坏的可能性，应对源程序库的访问进行严格的控制：严格管理在开发设备上的存放源程序的目录。如果源程序没有很好的保护，则系统与其设置可能会遭到未经

57、授权的访问，并造成系统的安全性可靠性大大下降。只有指定的人员如程序库管理员经过适当的管理授权后才可以访问源程序库，对源程序库的访问必须结合进行严格的访问控制技术手段和双重访问控制机制。各项应用均应指定相应的管理员。信息技术支持人员(非开发人员)不应自由访问源程序库。源程序库和运作程序库宜分开存放并且分开管理。源程序库和运行的应用系统宜分开存放且分开管理。源程序库的更新和向程序员发布的源程序应由指定的管理员根据一定的授权进行，不得私自进行更新或发放。应保存所有对源程序库进行访问读取或修改的日志记录，以便日后审核。在软件开发过程变更管理a)系统容易受到未经授权的变更的影响，即使是完全授权的更改也可

58、能存在破坏性的影响，存在数据完整性的损失、应用系统的不可用以与信息的泄漏的风险。为了使信息系统的损失降至最小，组织应对更改进行严格的控制，即在系统开发的每一个阶段（可行性研究、需求分析、设计、编码、测试、培训等）的每一个更改实施前必须经过组织的评审与授权。b)对于敏感的应用系统的更改应由另一人员进行检查，为了有效的进行控制，组织应建立更改控制审批程序，对更改的申请、评审、测试、批准、更改的计划的提出和实施提出明确要求并严格的实施，确保安全性与控制程序不被损害，程序设计人员应只能访问他们工作所必需的部分，确保任何的改动都应经过审批的。c)更改的程序宜如下：清晰确认所有需要更改的应用系统、信息、数

59、据库和相关的硬件设备。清晰确认更改的原因(业务上的具体流程和具体的需求或开发上的需求)。由授权的用户提交更改申请。保留相关的授权登记记录。在正式实施之前，更改的方案必须经过评审并通过正式的批准。确保授权的用户在实施之前确认并接受更改的容。确保在实施的过程中，尽量减少对现行的业务运作系统的影响。确保建立的文件系统在完成各项更改时得到修改，旧文件被很好的归档或处置。保证所有的应用系统升级的版本控制。确保对所有的更改请求进行审核跟踪。确保用户使用手册作相应的必要的更改。确保更改的实施选择了适当的时机，以确保更改的实施不会干扰正常的业务运作。开发版本管理控制程序清单源程序相关信息可以帮助确认系统问题的

60、根源，并且一旦掌握了系统源程序相关信息可以清楚地了解系统的运行逻辑和可能的薄弱点，对系统的安全有很大的影响。在任何时候对于程序清单必须进行严格的控制并且与时地进行更新。对应用系统开发源程序的打印资料、电子版本或者是相关的报告都必须进行控制，纸质的文件应保存在一个安全的环境下，如保险柜等。电子文档则应进行一定的加密。版本升级控制应用系统软件开发版本升级申请。当软件的版本由于更新、修改等操作需要升级时必须先向相关负责人员提交申请。应用系统软件版本升级测试。对升级的应用系统进行测试，确认系统的各种安全特性。应用系统软件版本审批。对应用系统的版本的升级，应确认当前的版本为最新的版本，旧的版本应进行归档