湖南项目应用与开发专业.docx
《湖南项目应用与开发专业.docx》由会员分享，可在线阅读，更多相关《湖南项目应用与开发专业.docx（20页珍藏版）》请在冰豆网上搜索。
湖南项目应用与开发专业
湖南项目应用与开发专业
（湖南信息职业技术学院教务处，湖南长沙410200）
概述
信息系统的许多的安全控制或其他安全性保证是通过系统的开发设计予以实现的。
因此如果在系统的开发设计阶段没有对系统的安全性给予充分的考虑，那么系统本身一定会存在许多先天不足，系统就会漏洞百出。
为确保应用系统的安全，在应用系统开发之前就应确认系统的安全需求，并以此作为开发设计的阶段的基础。
本规范主要规定了在系统开发的各个阶段所应遵守的各种安全规范，从需求分析开始，到设计，再到开发和维护以及最后的文档等系统开发的各个阶段分别进行阐述，并将在不同阶段中所需要注意的安全问题和相关的安全规范进行进一步的描述和规定。
目标
保护应用系统开发过程的安全。
具体地说就是保护应用系统开发过程免受XX的访问和更改，保护系统开发中系统软件和信息的安全，确保开发项目顺利正确的实施并对开发环境进行严格的控制。
同时确保应用系统开发外包中的各项安全。
适用范围
本套规范适用的范围包括了整个应用系统开发过程中的安全。
包括了系统开发可行性和需求分析阶段的安全，系统设计阶段的安全，系统开发阶段的安全，系统测试阶段的安全，系统培训和文档阶段的安全以及系统开发外包的安全规范。
主要规定了应用系统开发过程的安全保密，软件的质量的要求，系统和业务需求的符合性，保证敏感信息的安全，系统本身的稳定性和兼容性问题。
规范引用的文件或标准
下列文件中的条款通过本标准的引用而成为本标准的条款。
凡是不注日期的引用文件，其最新版本适用于本标准。
ØGB17859-1999计算机信息系统安全保护等级划分准则
ØGB/T9387-1995信息处理系统开放系统互连基本参考模型（ISO7498:
1989）
ØGA/T391-2002计算机信息系统安全等级保护管理要求
ØISO/IECTR13355信息技术安全管理指南
ØNIST信息安全系列——美国国家标准技术院
Ø英国国家信息安全标准BS7799
Ø信息安全基础保护ITBaselineProtectionManual（Germany）
ØBearingPointConsulting内部信息安全标准
ØRUSecure安全技术标准
Ø信息系统安全专家丛书CertificateInformationSystemsSecurityProfessional
术语和定义
Ø访问控制accesscontrol一种安全保证手段，即信息系统的资源只能由被授权实体按授权方式进行访问，防止对资源的未授权使用。
Ø应用系统applicationsystem
Ø认证authenticationa.验证用户、设备和其他实体的身份；b.验证数据的完整性。
Ø授权authorization给予权利，包括信息资源访问权的授予。
Ø可用性availability数据或资源的特性，被授权实体按要求能及时访问和使用数据或资源。
Ø缓冲器溢出bufferoverflow指通过往程序的缓冲区写超出其长度的内容，造成缓冲区的溢出，从而破坏程序的堆栈，使程序转而执行其它指令，以达到攻击的目的。
Ø保密性confidentiality数据所具有的特性，即表示数据所达到的未提供或未泄露给未授权的个人、过程或其他实体的程度。
Ø隐藏通道covertchannel可用来按照违反安全策略的方式传送!
数据的传输信道。
Ø完整性integrity在防止非授权用户修改或使用资源和防止授权用户不正确地修改或使用资源的情况下,信息系统中的数据与在原文档中的相同，并未遭受偶然或恶意的修改或破坏时所具的性质。
Ø敏感信息sensitiveinformation由权威机构确定的必须受保护的信息，因为该信息的泄露、修改、破坏或丢失都会对人或事产生可预知的损害。
Ø系统测试systemtesting用于确定系统的安全特征按设计要求实现的过程。
这一过程包括现场功能测试、渗透测试和验证。
Ø后门代码trapdoor通常为测试或查找故障而设置的一种隐藏的软件或硬件机制，它能避开计算机安全。
而且它能在非常规时间点或无需常规检查的情况下进入程序。
Ø特洛伊木马Trojanhorse一种表面无害的程序，它包含恶性逻辑程序，导致未授权地收集、伪造或破坏数据，以此破坏计算机安全与完整性的进程。
Ø验证verification将某一活动、处理过程或产品与相应的要求或规范相比较。
Ø例：
将某一规范与安全策略模型相比较，或者将目标代码与源代码相比较。
Ø压力测试于确定系统的薄弱环节，确定系统在非正常条件下能够迅速恢复到正常的运行状态的能力。
应用系统开发总体原则
应用系统的开发应遵循一系列的总体原则，以确保开发过程中的安全。
其中包括：
Ø系统开发应从业务需求的角度出发，不得盲目追求系统的先进性而忽略了系统的实用性。
系统的开发是为了更好地满足业务上的需要，而不是技术上的需要。
Ø开发的方法和管理必须规范化、合理化、制度化，从而确保开发的质量和进度。
Ø应保证开发的进度并按时完成。
确保开发工作及时、有效且高质量的完成。
Ø系统开发必须具有一定的前瞻性，符合主流系统的发展方向。
Ø提高和加强开发人员的安全意识。
确保机密信息和关键技术不会泄漏，特别是不可泄漏到竞争对手的手中，否则将会对公司的竞争力产生极大的影响。
Ø应充分利用现有的资源。
系统需求收集和分析阶段
可行性研究分析
对于应用系统开发项目应进行一定的可行性分析，以保证只有在确认具备了相当的资源和条件，并且有能力满足业务上的需求的情况下才能开展开发工作。
切忌盲目开发，否则既浪费资源，又浪费时间。
可行性研究宜从技术、需求面、投入和影响四个方面进行考虑：
技术可行性分析
根据业务上提出的需求，从技术开发的角度分析现有的技术手段和技术能力是否能够实现业务上所要求的系统功能。
通常可从以下三个方面进行分析：
Ø人员技术能力分析，指公司内的系统开发队伍或外包的第三方开发公司是否具有足够技术和管理能力来完成系统开发的任务。
Ø计算机软件和硬件分析，指公司现有的软件和硬件的性能是否足够满足开发相应的系统的要求。
Ø管理能力分析，指现有的技术开发管理制度和管理流程是否成熟且标准化，是否满足系统开发的要求。
需求可行性分析
系统的开发来源于业务上的需求，因此需要对该需求进行可行性分析，以判断需求是否明确，是否符合实际，是否在一定的时间范围内可以实现。
投资可行性分析
根据业务需求和技术手段的分析，确认实现系统开发所需的投资，并确认投资的数额是否在可控制和可承受的范围内。
影响可行性分析
所谓的影响是指社会影响，比如系统开发是否符合法律法规上的要求，是否和相关的管理制度或行业标准相抵触，是否符合人文或道德上的约束等。
开发人员安全管理
系统开发人员职责分配
在系统开发的过程中，应明确不同人员的身份和职责。
在系统开发过程中具体可分以下三种角色：
Ø项目负责人员：
确保在整个系统开发的各个阶段都实施了相关的安全措施，同时在整个系统开发的过程中负责整个项目的开发安全管理。
Ø系统开发人员：
根据业务需求确保开发的系统能够满足业务上的需求和相应的安全上的需求，同时满足系统质量上和进度上的要求。
Ø系统审核人员：
对整个开发的过程进行审核和监督，确保开发的质量和开发的安全。
开发人员授权
Ø应根据该员工在整个开发项目中所负责的开发内容授予其相应的权限和所应承担的责任。
Ø开发人员必须负责其开发内容的保密性，不得私自将开发的相关信息泄漏出去，即使对家人或开发团队中的其他开发人员也不得泄漏。
但开发人员有责任将开发的相关信息告诉项目的负责人员或开发小组的负责人员。
Ø以书面的方式将员工的权限和相应的责任提交给员工本人。
必须严格规定在为企业工作期间，所有和工作相关的开发成果的所属权都归企业所有。
Ø应根据员工权限和责任的大小确认是否需要签署相关的保密协议。
Ø应在日常工作中记录员工与开发相关的日志信息。
Ø员工一旦离职或调动岗位应立即收回或调整其相应的权限。
开发人员必须训练开发安全代码的能力
Ø在整个开发的过程中必须完整持续地进行代码错误处理所规定的流程。
Ø错误问题报告应力求通俗易懂，不应在其中包含任何系统细节问题。
Ø应对重要的敏感信息进行加密保护。
Ø应使用一些相对复杂的加密和密钥生成机制。
Ø应单独编写安全性设计说明概要
分离系统开发和运作维护
管理层必须确保应用系统的开发和运作管理从组织人事和权限职责上分开。
Ø信息技术人员可以现场修复或更改偶然或恶意的数据和软件问题。
Ø测试代码中往往包含调试或者查错代码，大大增加了主机系统的性能负担。
Ø开发人员不应具有很高的权限，否则将在系统运行中产生很大的风险。
建立系统开发安全需求分析报告
Ø安全需求计划应能够达到期望的安全水平。
其中包括了成本的预估，完成各个安全相关流程所需的时间。
Ø所有关于应用系统的更新或改进都必须基于业务需求，并有业务事件支持。
这里的业务需求不仅仅包括了系统的功能、性能、开发费用、开发周期等内容，应明确系统的安全要求。
应用系统的任何一次改进或更新都应和该业务系统的所有者密切相关。
Ø开发安全需求分析计划应由开发项目经理和公司内部的安全小组共同商议决定。
Ø应确保每一个应用系统的用户都意识到系统的更新或改进都与其自身密切相关，所有的更新或改动建议都必须基于业务需求，而不是基于所谓的“信息技术的要求”。
Ø系统的每一次更新或改进都必须认真对待，必须进行详细的需求定义、需求分析以及测试评估，以保证不会对业务造成任何不良影响。
Ø业务需求是系统更新和改动的基础，因此必须清晰明确地定义业务的需求，禁止在业务需求未经业务部门领导和主要负责人员认可的情况下，盲目地进行开发工作。
系统设计阶段的安全规范
单点访问控制且无后门
任何用户如果希望访问应用系统中的某一部分，则必须通过统一且唯一的认证授权方式及流程。
人员职责和权限的定义
由于不是所有的人员对于某一个应用系统都具有同样的访问或使用权限，因此系统必须具有基于人员职责的用户授权管理，以确保每个用户可以访问到其权限范围内的应用系统部分。
同时应确保每个用户无法访问其权限范围以外的应用系统部分。
确保敏感系统的安全性
将应用系统中敏感的信息保存在服务器端以进行集中的加密的安全管理，确保客户端系统本身并不能存储任何敏感的数据。
确保访问层的安全性
应用系统不仅仅要确保系统模块本身的安全性，同时还应考虑模块与模块之间通讯的安全性。
这种模块与模块之间通讯的安全性不仅仅包括了应用系统内部模块之间通讯的安全，也包括了应用系统内部模块和外部模块之间的通讯安全性，如主机和客户端之间通讯的安全性、服务器和服务器间通讯的安全性，以及本地系统和异地系统之间通讯的安全性。
确保日志管理机制健全
应建立可根据情况自由设置的日志管理机制，也就是说日志记录的范围和详细程度可以根据需求自行定制，且可以实现在应用系统的使用过程中进行日志的定制和记录。
保留所有与系统开发相关的程序库的更新审核记录。
新系统的容量规划
容量规划是指确定系统的总体规模、性能和系统弹性。
容量规划的具体内容可能有所不同，但一般应考虑以下方面：
Ø系统的预期存储容量和在给定的周期中获取生成和存储的数据量。
Ø在线进程的数量和估计可能的占用资料
Ø系统和网络的响应时间和性能，即端对端系统
Ø系统弹性要求和设计使用率（峰值，槽值和平均值等）
Ø安全措施如加密解密数据对系统的影响。
Ø24x7运作要求和可接受的系统宕机次数（维护或者设备更新导致的必须性宕机）
规划容量的时候关于系统使用的信息了解的越多越好。
近来，由于互联网站的使用以指数形式增长，容量规划的变动效果不是非常显著，有时甚至毫无用处。
原因在于很难估计实际的负载。
在容量估计的时候应尽量将情况设想得复杂一些。
系统开发阶段安全规范
系统开发语言
程序员可使用很多指导规范来防止应用程序中的普通安全问题。
其中许多可以应用于任何一种编程语言，但某些是针对特定的语言的。
特定语言的指导规范主要集中在Perl，Java和C/C++语言。
大多数情况下，一般的错误可以避免。
而这些本可以避免的错误常常会导致很多安全漏洞，从而威胁信息的保密性、完整性和可用性。
通用规范
输入验证
在客户机/服务器环境下，进行服务端的验证而不是客户端的验证（例如基于Javascript的验证）。
通过在客户端和服务器之间放置一个代理服务器，可以很容易绕过客户端验证。
有了代理服务器，攻击者可以在数据被客户端“验证”后修改数据（与“man-in-the-middle”攻击类似）。
在实际的校验中，输入校验首先定义一个有效（可接受）的字符集，然后检查每个数据的字符是否在有效范围内。
如果输入中包含无效的字符，应用程序应返回错误页面并说明输入中包含无效字符。
这样进行验证的原因是定义无效的字符集比较困难，并且一些不应有效的字符通常不会被指出。
边界检查（例如字符串的最大长度）应在字符有效性检查以前进行。
边界分析可以防止大多数缓冲区溢出漏洞。
从环境变量获得的数据也需要进行验证。
同时避免在环境变量中存放敏感数据（例如密码）。
某些Unix系统（例如FreeBSD）包含ps命令，可以让用户看到任何当前进程的环境变量，这常常会暴露保密性信息。
SQL语句
如果应用程序需要连接后端数据库，不得在代码中使用SQL语句。
使用程序以外的嵌入在代码中的SQL语句调用特别危险，难以防止攻击者使用输入域或者配置文件（由应用程序载入）来执行嵌入式的SQL攻击。
而输入验证有助于缓解这种风险。
注释代码（commentedcode）
当应用程序在实际环境中开始应用时，应删除所有的注释代码。
注释代码是用来调试或者测试的，它们不是最终应用程序的一部分。
无论如何应在实际的环境中删除它们来避免意外的执行（一般注释标识被删除后就无法激活休眠的代码，但还是存在可能性的，所以应执行这项工作）。
错误消息
所有对用户显示的错误信息都不应暴露任何关于系统、网络或应用程序的敏感信息。
如果可能的话，应使用包含编号的一般的错误信息，这种信息只有开发者和/或支持小组才能理解。
一般的错误信息的例子是“发生了错误（代码1234），请您与系统维护部门联系。
”
统一资源定位（URL）内容
对于web应用，不要在URL上暴露任何重要信息，例如密码、服务器名称、IP地址或者文件系统路径（暴露了web服务器的目录结构）。
这些信息可以在攻击时使用。
例如下面就是一个不安全的URL：
PASSWORD&file=/home/USER/expenses.txt
设置PATH变量
设置PATH为一个已知的值，而不仅仅是使用启动时的缺省值。
攻击者可以在攻击应用程序时使用PATH变量，例如试图执行一个任意的程序。
这些也可以应用于大多数其他的语言。
Perl语言
多年以来，Perl已经成为用于系统管理和WebCGI开发的功能最强的编程语言之一（几乎可以使用Perl实现任何功能）。
但其扩展应用，即作为Internet上CGI的开发工具，使得它经常成为web服务器上的攻击目标。
另外，大多数CGI脚本有着比一般用户更高的权限，导致它更容易受攻击。
下面列举了一些开发者（特别是CGI程序员）可以使用的主动的预防性的措施来增强Perl代码的整体安全性（请注意：
这不是web服务器CGI脚本安全性的指导原则）。
Taint验证
Perl版本5.x包含一个叫做TaintChecking的数据验证措施。
如果起用该功能，它就不允许通过用户输入（任何程序外的输入）来操纵其他的外部程序（例如通过管道将数据导入另一个程序执行））。
一般而言，程序员不能信任输入脚本和程序的数据（叫做Tainted数据），因为无法保证它不会产生危害（有意或者无意的）。
Taint验证可以通过在命令行参数加入“-T”来开启。
例如可以Perl脚本的第一行这样加入“-T”：
#!
usr/bin/perl5-T
Tainted数据包括命令行参数、环境变量和来自文件的数据。
引用tainted数据的变量也成为tainted数据。
如果脚本试图通过不安全的方式来使用tainted数据会产生一个致命错误（对这种情况称为“不安全的依赖”（Insecuredependency）或者其他的说法）。
启用tainted验证在有些情况下会导致脚本停止运行，常常是由于Perl解释器要求所有脚本引用的外部程序的完全路径必须在PATH环境变量中列出，同时PATH中包含的每个目录除了目录的所有者及相应的所有者用户组外无法修改。
Taint验证对于环境比较敏感，这就可能会导致大多数程序员不愿使用它，但是只要可能就应使用taint验证，特别是代码执行其他程序功能时（例如在CGI脚本的情况下）。
安全模块
如果不但输入数据不可信而且实际的代码也不可信会产生什么情况？
例如用户从网站上下载了一个ActiveX控件，而它实际是一个特洛伊木马（Trojanhorse）。
这种情况下taint验证就不起作用。
安全模块让程序员可以在Perl脚本中将不同的代码模块与安全对象相联系。
每个安全对象对于运行的每块代码建立了一个限制的环境。
这与chroot在一个进程中只能在整体目录结构的一个子目录中运行类似。
而saft对象限制perl代码只能在perl包结构的某些特定包中运行。
如何使用安全模式超出了本文的范围，但程序员应在任何时候使用这一功能。
警告参数（-w）
使用-w参数可以在Perl解释脚本时显示所有的警告信息。
警告可以对以下情况产生：
只使用了一次的变量或者完全没有使用过的变量，未定义的文件句柄，未关闭的文件句柄，或将非数值变量传递到数据变量。
该功能不是针对安全处理的，但是有助于调试直接或者间接对安全有危害的错误。
一般推荐总是使用-w参数。
可在taint验证时在第一行这样使用-w参数：
#!
usr/bin/perl5–Tw
Java语言
自从1995年发布以来，Java成为简单或者复杂网络应用的有效编程语言。
它在设计时充分考虑了安全问题，因此它具有的限制特征有：
收集不再使用的内存碎片的垃圾收集器，严格的“sandbox”安全模型，以及在特定主机上限制应用程序的活动的安全管理器。
以下为使用中的相关的规范：
不应在标准输出上打印消息
在实际的Internet系统中避免使用System.out.println（）或者System.err.println（）打印日志和错误消息，原因是当消息打印到标准输出时，无法立即确定消息发生的地点，且有可能将敏感信息透露给攻击者。
封装
ØJava中，如果没有使用访问标识符（accessmodifier（private、protected或public））来声明类、方法和属性，那么它的默认访问范围是包，并且同一包中的所有类都能访问它。
必须记住虽然包有封装功能，但它只有在每部分加载到包的代码都由授权用户控制时才起作用。
恶意的用户可以加入他们自己的类，从而对于包中的所有类、方法和属性都有完全的访问权限。
ØJava的政策文件支持两种控制包访问权限的前缀。
ØaccessClassInPackage
ØdefineClassInPackage
Ø所有标准库中的类都默认是可以公共访问的（除了由“sun”开头的类）。
为了保证一个包的安全性，必须修改${JAVAHOME}/jre/lib/security文件夹中的java.security文件。
该文件中的重要行是：
Øpackage.access=sun.
Ø虽然该方法有作用，但仍存在问题。
例如程序员在java.security文件中定义包的安全时必须十分小心。
在package.access中的值是字符型的，“sun.”将保护“sun.tools”等包，但是不会对“sun”或者“sunshine”等包进行保护。
Ø另一个方法是使用JAR密封（sealing）。
JAR（JavaARchive）文件是一些类的打包压缩格式的文件，与常用的ZIP格式类似。
如果从一个密封（sealing）的JAR文件中加载一个类，随后同一个包的类只能从该JAR文件加载。
为了起用密封（sealing），必须在建立JAR文件时这样设置密封（seal）参数：
ØSealed:
true
Ø使用密封（sealing）的JAR文件比权限（permission）设置更好，因为它不需要安装安全管理器（securitymanager）。
政策文件
Java内建的安全管理器是对应用程序进行限制的一个方便的工具。
很多情况下需要编制一个定制的安全管理器，JDK1.2及以后的版本提供了描述设置的方法而不是实施它们。
这是通过Java政策文件实现的。
可以用政策文件以相对模块化的方式控制文件系统和网络的访问。
例如可以限制应用程序只能修改名字是foo的文件。
宜使用Java政策文件和安全管理器而不是重新创建一个类或者系统来限制对主机和网络的访问。
C/C++语言
C本质上是不安全的编程语言。
例如如果不谨慎使用的话，其大多数标准的字符串库函数有可能被用来进行缓冲区攻击或者格式字符串攻击。
但是，由于其灵活性、快速和相对容易掌握，它是一个广泛使用的编程语言。
下面是针对开发安全的C语言程序的一些规范。
缓冲区溢出
避免使用不执行边界检查的字符串函数，因为它们可能被用来进行缓冲区溢出攻击。
下面是应避免使用的函数。
同时，也列出了每个函数相应的比较安全的替换方式。
Ø不使用strcpy（），使用strncpy（）
Ø不使用strcat（），使用strncat（）
Ø不使用sprintf（），使用snprintf（）
Ø不使用gets（），使用fgets（）
在上面的前三个中函数中，每个替代函数的“n”表示了使用的缓冲区的大小。
最后一个函数的“f”，表示格式，它允许用户指定期望的输入的格式。
这些替换方程强制程序员定义使用的缓冲区的尺寸以及确定输入的类型。
格式化字符串攻击（FormatStringAttack）
该类攻击往往与缓冲区溢出相关，因为它们往往主要利用了某些函数的假设，例如sprintf（）和vsprintf（）假设缓冲区的长度是无限的。
然而即使使用snprintf（）替换sprintf（）也无法完全保护程序不受格式化字符串的攻击。
这些攻击通过直接将格式说明符（formatspecifiers）（%d，%s，%n等）传递到输出函数接收缓冲区来进行。
例如，以下的代码就是不安全的：
snprintf（buffer,sizeof（buffer）,string）
这种情况下，可以在字符串中插入格式说明符来操纵内存的栈，来写入攻击者的数据（这些数据中包含小的程序代码，并可由处理器接着执行）。
更多关于这些攻击的具体内容请见资源章节。
对以上的例子建议使用下面的代码。
snprintf（buffer,sizeof（buffer）,“%s”,string）
进行格式字符串攻击不太容易。
首先攻击者必须能获得内存栈的内容情况（从应用导出或者使用调试器），然后必须知道如何精确访问特定的内存空间来操纵栈中的变量。
执行外部程序
推荐使用exec（）函数而不是system（）函数来执行外部程序。
这是因为system（）接收整个命令行的随机的缓冲区来执行程序。
snprintf（buffer,sizeof（buffer）,"emacs%s",filename）
升级会员 