应用系统安全开发技术规范V1.3.docx
《应用系统安全开发技术规范V1.3.docx》由会员分享，可在线阅读，更多相关《应用系统安全开发技术规范V1.3.docx（60页珍藏版）》请在冰点文库上搜索。
应用系统安全开发技术规范
（版本号V1.3）
朗新科技股份有限公司
二〇一五年十二月
更改履历
版本号
修改编号
更改时间
更改的
图表和章节号
更改简要描述
更改人
批准人
0.5
2013-11-24
初稿
施伟
施伟
1.0
2015-11-19
修改
宋月欣
陈志明
1.1
2015-11-30
修改
宋月欣
陈志明
1.2
2015-12-3
修改
宋月欣
施伟
1.3
2015-12-3
修改
施伟
注：
更改人除形成初稿，以后每次修改在未批准确认前均需采用修订的方式进行修改。
目录
1 背景与目标 1
2 安全编程概念 1
2.1 安全编程 1
2.2 结构化编程 2
2.3 脆弱性 2
2.4 可信计算 2
2.5 安全可信模块 3
2.6 不可信任模块 3
2.7 敏感信息 3
2.8 特权 3
2.9 信息隐藏 3
2.10 中间件 3
2.11 死锁 4
2.12 可信边界 4
2.13 元字符 4
2.14 参数化查询 4
2.15 UNIXJAIL环境 4
2.16 临时文件 4
2.17 信息熵 5
2.18 SSL 5
2.19 TLS 5
2.20 HTTPS 5
2.21 Http会话 5
2.22 Cookie 6
2.23 HttpOnlyCookie 6
3 安全编程原则 6
3.1 统一的安全规范 6
3.2 模块划分 6
3.3 最小化功能 7
3.4 最小化特权 7
3.5 对多任务、多进程加以关注 7
3.6 界面输出最小化 7
3.7 使代码简单、最小化和易于修改 8
3.8 避免高危的服务、协议 8
3.9 数据和代码分离 8
3.10 关键数据传输保护 8
3.11 禁止赋予用户进程特权 8
3.12 使用适当的数据类型 9
3.13 使用经过验证的安全代码 9
3.14 使用应用中间件 9
3.15 设计错误、异常处理机制 9
3.16 提供备份机制 9
3.17 检查传递变量的合法性 9
3.18 检查所有函数返回代码 9
3.19 修改面向用户的操作的反馈缺省描述 9
3.20 文件操作的要求 10
3.21 其他编码原则 10
4 应用安全分析 11
4.1 安全需求 11
4.2 安全威胁 11
4.2.1 Web安全漏洞 11
4.2.2 拒绝服务攻击 12
4.2.3 嗅探攻击 12
4.2.4 中间人攻击 12
4.3 安全约束 13
5 安全编程要求 13
5.1 输入处理 13
5.1.1 建立可信边界 13
5.1.2 验证各种来源的输入 14
5.1.3 保证所有的输入信息是被验证过的 14
5.1.4 对输入内容进行规范化处理后再进行验证 15
5.1.5 选择合适的数据验证方式 15
5.1.6 防范元字符攻击 15
5.1.7 拒绝验证失败的数据 15
5.1.8 在服务端进行验证 15
5.1.9 建立统一的输入验证接口 16
5.1.10 控制写入日志的信息 16
5.1.11 从服务器端提取关键参数 16
5.2 输出处理 16
5.2.1 限制返回给客户的信息 16
5.2.2 建立错误信息保护机制 16
5.3 数据库访问 16
5.3.1 合理分配数据库访问权限 16
5.3.2 合理存放数据库连接帐号和密码信息 17
5.3.3 使用参数化请求方式 17
5.3.4 对SQL语句中来自于不可信区域的输入参数进行验证 18
5.3.5 对数据库操作的返回数据进行验证 18
5.3.6 分次提取数据 18
5.3.7 通过row（行）级别的访问控制来使用数据库 18
5.3.8 确保数据库资源被释放 18
5.4 文件操作 19
5.4.1 对上传文件进行限制 19
5.4.2 把文件名以及文件内容作为不可信的输入对待 19
5.4.3 安全的使用文件名 19
5.4.4 使用文件系统访问控制 19
5.4.5 注意文件访问竞争条件 19
5.4.6 安全使用临时文件 20
5.4.7 确保文件系统资源被释放 20
6 安全特征 20
6.1 关注应用的对象重用 20
6.2 用户访问控制信息的机密性 20
6.3 不要在客户端存放敏感数据 20
6.4 避免内存溢出 21
6.5 可配置数据保护 21
6.6 禁止在源代码中写入口令 21
6.7 随机数 21
6.8 使用可信的密码算法 22
6.9 异常管理 22
7 应用安全设计规范 23
7.1 应用安全规划 23
7.2 数据安全等级划分 23
7.3 数据库规划 23
7.3.1 用户权限 23
7.3.2 数据源设计 23
7.3.3 外部系统访问 23
7.4 角色划分 24
7.5 URL规划 24
7.6 程序文件目录规划 24
7.6.1 数据及程序分离 24
7.6.2 静态程序资源 24
7.6.3 程序文件分类 24
7.7 Cookie 24
7.8 文件安全 25
7.8.1 文件存储 25
7.8.2 文件操作 25
7.8.3 文件类型 25
7.9 第三方组件安全 25
7.9.1 组件兼容性 25
7.9.2 组件安全及成熟度 25
7.9.3 组件配置 25
7.10 WebService 25
7.11 RESTfulWebService 26
7.12 应用安全关注点 27
7.13 应用安全限制应对方案 29
7.13.1 外网隔离 29
7.13.2 外网文件操作 29
7.13.3 正向和反向隔离装置（国网系统） 29
8 应用安全开发规范 30
8.1 Java及Web安全编程规范 30
8.1.1 不信任未知 30
8.1.2 数据层开发 30
8.1.3 会话管理 32
8.1.4 Cookie 33
8.1.5 输入验证 33
8.1.6 输入文件名的验证 34
8.1.7 输出处理 34
8.1.8 敏感信息处理 36
8.1.9 异常信息处理 37
8.1.10 特殊页面跳转 37
8.1.11 文件操作 37
8.1.12 资源释放 38
8.1.13 内存控制 38
8.1.14 外部程序调用漏洞 38
8.1.15 整数溢出 39
8.2 C++安全编程规范 39
8.2.1 不信任未知 39
8.2.2 免缓存区溢出 40
8.2.3 免缓整数溢出 42
8.2.4 域名合法性检查 45
8.2.5 检查返回值 46
8.2.6 产生随机数 47
8.2.7 验证输入文件名 48
8.2.8 类设计注意事项 48
8.2.9 外部程序调用漏洞 50
8.2.10 临时文件处理 50
应用系统安全开发技术规范
1背景与目标
在Internet大众化及Web技术飞速演变的今天，Web安全所面临的挑战日益严峻。
黑客攻击技术越来越成熟和大众化，针对Web的攻击和破坏不断增长，Web安全风险达到了前所未有的高度。
许多程序员不知道如何开发安全的应用程序，开发出来的Web应用存在较多的安全漏洞，这些安全漏洞一旦被黑客利用将导致严重甚至是灾难性的后果。
这并非危言耸听，类似的网上事故举不胜举，公司的Web产品也曾多次遭黑客攻击，甚至有黑客利用公司Web产品的漏洞敲诈运营商，造成极其恶劣的影响。
本规范为解决Web应用系统安全问题，对主要的应用安全问题进行分析，并有针对性的从设计及开发规范、开发管理、安全组件框架、安全测试方面提供整体的安全解决方案。
使本组织能以标准的、规范的方式设计和编码。
通过建立编码规范，以使每个开发人员养成良好的编码风格和习惯；并以此形成开发小组编码约定，提高程序的可靠性、可读性、可修改性、可维护性和一致性等，增进团队间的交流，并保证软件产品的质量。
2安全编程概念
2.1安全编程
安全编程是指开发人员首先需要具备一定的安全知识，然后识别数据在流转（输入、处理和输出）过程中可能面对的威胁，对这些威胁进行分析得出其利用的漏洞，通过合理地编写代码消除这些漏洞，降低软件面临的风险。
本规范对开发人员的编码提出统一的安全要求，主要涉及输入处理、输出处理、数据库访问、文件操作、异常管理等方面，如下图：
输入处理部分能指导开发者避免用户的不良输入；输出处理能指导开发者对输出内容进行过滤；数据库访问、文件操作部分则能指导开发者进行数据库查询，写入文件等操作时进行防护；而异常管理、敏感数据保护、对象重用等技术则指导开发者改进软件的自身缺陷。
WEB开发规范部分则指导用户在WEB系统（B/S架构应用）的研发方面时如何增加对应用软件的保护。
2.2结构化编程
结构化编程，一种编程典范。
它采用子程序、程式码区块、for循环以及while循环等结构，来取代传统的goto。
希望借此来改善计算机程序的明晰性、品质以及开发时间，并且避免写出面条式代码。
2.3脆弱性
脆弱性指计算机系统安全方面的缺陷，使得系统或其应用数据的保密性、完整性、可用性、访问控制、监测机制等面临威胁。
2.4可信计算
可信计算的行为会更全面地遵循设计，而执行设计者和软件编写者所禁止的行为的概率很低。
2.5安全可信模块
审计和访问控制模块是唯一的安全可信模块。
2.6不可信任模块
除审计和访问控制模块外其它所有模块均为不可信模块。
2.7敏感信息
系统的敏感信息包括用户身份信息、认证信息、授权信息、交易过程中的私密或隐私信息、其它的敏感信息。
2.8特权
特权只是允许去做并不是每个人都可以做的事情。
2.9信息隐藏
信息隐藏指在设计和确定模块时，使得一个模块内包含的特定信息（过程或数据），对于不需要这些信息的其他模块来说，是不可访问的。
信息隐藏基本原理框图：
2.10中间件
中间件是提供系统软件和应用软件之间连接的软件，以便于软件各部件之间的沟通.中间件技术创建在对应用软件部分常用功能的抽象上，将常用且重要的过程调用、分布式组件、消息队列、事务、安全、连结器、商业流程、网络并发、HTTP服务器、WebService等功能集于一身或者分别在不同品牌的不同产品中分别完成。
2.11死锁
死锁是操作系统或软件运行的一种状态：
在多任务系统下，当一个或多个进程等待系统资源，而资源又被进程本身或其它进程占用时，就形成了死锁。
2.12可信边界
可信边界可以被认为是在程序中划定的一条分隔线，一边的数据是不可信的而另一边则是可信的。
当数据要从不可信的一侧到可信一侧的时候，需要使用验证逻辑进行判断。
2.13元字符
元字符就是在编程语言中具有特定含义的字符或者字符串。
例如在SQL查询中，单引号（‘）是危险的字符；在文件系统路径中两个点号（..）是危险的字符；在命令shell中，分号（；）和双&（&&）符号同样是危险的字符，而换行符（\n）对日志文件很关键。
2.14参数化查询
参数化查询（ParameterizedQuery或ParameterizedStatement）是指在设计与数据库链接并访问数据时，在需要填入数值或数据的地方，使用参数（Parameter）来给值，这个方法目前已被视为最有效可预防SQL注入攻击（SQLInjection）的攻击手法的防御方式。
2.15UNIXJAIL环境
一个被改变根目录的程序不可以访问和命名在被改变根目录外的文件，那个根目录叫做“chroot监狱（chrootjail,chrootprison）”。
2.16临时文件
创建临时文件的程序会在完成时将其删除。
2.17信息熵
信息熵指信息的不确定性,一则高信息度的信息熵是很低的,低信息度的熵则高。
2.18SSL
安全套接层（SecureSocketsLayer，SSL），一种安全协议，是网景公司（Netscape）在推出Web浏览器首版的同时提出的，目的是为网络通信提供安全及数据完整性。
SSL在传输层对网络连接进行加密。
SSL采用公开密钥技术，保证两个应用间通信的保密性和可靠性，使客户与服务器应用之间的通信不被攻击者窃听。
它在服务器和客户机两端可同时被支持，目前已成为互联网上保密通讯的工业标准。
现行Web浏览器亦普遍将HTTP和SSL相结合，从而实现安全通信。
此协议和其继任者是TLS。
2.19TLS
SSL（SecureSocketsLayer）是网景公司（Netscape）设计的主要用于Web的安全传输协议。
这种协议在Web上获得了广泛的应用。
IETF（www.ietf.org）将SSL作了标准化，即RFC2246，并将其称为TLS（TransportLayerSecurity），其最新版本是RFC5246,版本1.2。
从技术上讲，TLS1.0与SSL3.0的差异非常微小。
2.20HTTPS
超文本传输安全协议（缩写：
HTTPS，英语：
HypertextTransferProtocolSecure）是超文本传输协议和SSL/TLS的组合，用以提供加密通讯及对网络服务器身份的鉴定。
HTTPS连接经常被用于万维网上的交易支付和企业信息系统中敏感信息的传输。
HTTPS不应与在RFC2660中定义的安全超文本传输协议（S-HTTP）相混。
2.21Http会话
在计算机科学领域来说，尤其是在网络领域，会话（session）是一种持久网络协议，在用户（或用户代理）端和服务器端之间创建关联，从而起到交换数据包的作用机制，session在网络协议（例如telnet或FTP）中是非常重要的部分。
在不包含会话层（例如UDP）或者是无法长时间驻留会话层（例如HTTP）的传输协议中，会话的维持需要依靠在传输数据中的高级别程序。
例如，在浏览器和远程主机之间的HTTP传输中，HTTPcookie就会被用来包含一些相关的信息，例如sessionID，参数和权限信息等。
当客户端在多个服务器调取数据时，保持会话状态的一致性是需要注意的，客户端需用同时保持和某一个主机的连接，或者多个服务器端需要共享一个储存会话信息的文件系统或者数据库。
否则，当用户在一个新的而不是一开始保存会话信息的主机上提交访问请求的时候，主机会因为无法获知原来主机的会话的访问状态而产生问题。
2.22Cookie
Cookie（复数形态Cookies），中文名称为小型文本文件或小甜饼，指某些网站为了辨别用户身份而储存在用户本地终端（ClientSide）上的数据（通常经过加密）。
定义于RFC2109。
为网景公司的前雇员LouMontulli在1993年3月所发明。
2.23HttpOnlyCookie
HttpOnly是包含在Http响应头信息Set-Cookie中的一个额外标志，如果浏览器支持HttpOnly标志的话，在生成Cookie时使用HttpOnly标志可帮助减轻客户端脚本访问受保护的Cookie时带来的风险（客户端脚本不能访问HttpOnlyCookie）。
3安全编程原则
3.1统一的安全规范
每个软件项目在设计阶段都应明确在项目实施过程中项目组应遵循的统一规范，具体包括：
1.命名规则、组件使用规范、异常处理规范、日志处理规范、工具使用要求、代码集成规范。
2.针对本规范提出的主要代码脆弱性应进行相应的防范设计，具体内容应在软件概要设计中体现或有单独的文档体现。
3.2模块划分
1.软件应该按照安全性划分模块，审计和访问控制模块为安全可信模块，其它模块为不可信任模块。
只有安全可信模块才可以执行安全控制功能，其它的模块不能访问安全可信模块的安全信息、功能或者权限。
安全可信模块应该与其它模块分离，由经授权的内部专人进行管理。
2.只有安全可信模块，才能以高安全等级访问系统的敏感信息，对于其他模块限制其访问敏感信息。
3.3最小化功能
根据“没有明确允许的就默认禁止”的原则，软件应只包含那些为达到某个目标而确实需要的功能，不应包含只是在将来某个时间需要但需求说明书中没有的功能。
软件在最小化功能建设方面应遵循如下原则：
1.只运行明确定义的功能。
2.系统调用只在确实需要的时候。
3.一次只执行一个任务。
4.只有在上一个任务完成后才开始下一个任务。
5.只在确实需要的时候访问数据。
3.4最小化特权
1.只为程序中需要特权的部分授与特权。
2.只授与部分绝对需要的具体特权。
3.将特权的有效时间或者可以有效的时间限制到绝对最小。
3.5对多任务、多进程加以关注
软件开发应尽量使用单任务的程序。
如果软件需要使用多任务和多进程，应该认真分析研究多任务和多进程会不会发生冲突，同步所有的进程和任务以避免冲突。
同时作为结构化的编程，每个原子化组件都要保证一个入口和一个出口。
如果进程之间需要交互，则这些交互操作应同步。
对于每一种可能的交互情况都要考虑相关的安全策略。
3.6界面输出最小化
软件应保持用户界面只提供必须的功能，没有多余的、不必要的功能，确保用户不能通过用户界面直接访问数据或者直接访问被保护对象。
3.7使代码简单、最小化和易于修改
开发时应尽量使代码简单、最小化和易于修改。
使用结构化的编程语言，尽量避免使用递归和Goto声明。
使用简单的代码，清除不必要的功能，防止采用信息隐藏方式进行数据保护。
3.8避免高危的服务、协议
软件应尽量避免使用不加保护的及已被证明存在安全漏洞的服务和通信协议传输文件，如FTP、SMTP。
3.9数据和代码分离
软件应该把数据与程序放置在不同的目录中，这里的数据包括远程下载文件等。
3.10关键数据传输保护
1.软件在传输关键数据时，使用加密算法保证数据在通信过程不被破译，使用数字签名保证数据在传输过程中的一致性和不可否认性。
相关的加密算法和签名技术等应符合国家相关法律法规要求。
2.信息隐藏是不可靠、效率低的做法，软件应该使用正确的安全保护措施，不要依赖隐藏进行数据保护。
3.11禁止赋予用户进程特权
用户进程的授权应采用最小授权法，对于软件的普通用户进程，禁止赋予该类进程特权用户权限。
特权用户类型包括：
1.超级用户。
2.直接操作数据库用户。
3.安全管理用户。
3.12使用适当的数据类型
应该小心使用数据类型，尽量使用占用内存较小的数据类型，如可用整型数据的不用实型，特别是在程序接口部分。
例如，在一些编程语言中signed和unsigned的数据类型是视为不同的（如C或者C++语言）。
3.13使用经过验证的安全代码
使用经过验证的安全代码模块和外部源程序，防止潜在的安全风险。
3.14使用应用中间件
中间件作为一种应用层架构，软件设计应尽可能使用中间件，中间件选型时应选择成熟的、业界主流的中间件产品。
3.15设计错误、异常处理机制
软件设计开发时应建立防止系统死锁的机制，异常情况的处理和恢复机制，具体包括错误和异常检测、数据回滚、安全错误通知、错误和异常记录、断点保护等。
3.16提供备份机制
为保证运行数据的完整性和可用性，软件开发应设计有效的备份策略，根据业务和系统维护需要提供定期或不定期、自动或手动方式的备份机制。
3.17检查传递变量的合法性
应检查所有传递给系统函数调用（SystemCalls）或本地调用（NativeCalls）的变量的合法性。
3.18检查所有函数返回代码
应检查所有函数调用返回代码（错误代码），对每个期望的返回值设置相应的处理程序。
3.19修改面向用户的操作的反馈缺省描述
应对面向用户的操作的反馈缺省描述进行必要的封装，删除有关后台系统或其它敏感信息。
3.20文件操作的要求
在需要进行文件操作时，应预先设定目前工作路径（全路径名），使用全路径名表示文件的位置。
3.21其他编码原则
1.当一个进程对敏感对象（包含秘密信息或包含不可更改信息）使用完后，应立即擦除对象的敏感信息，然后再删除对象。
任何不需要使用的资源应及时释放。
2.确保所有用来指示数组下标的数据（或指针）都指向了一个有效的数组元素。
如果某个函数不能保证下标所指向元素的有效性，或者根本不去检查边界时，不要使用该函数，应该寻找一个安全的函数，或者自己重新编写一个或者封装一个不安全的函数，加上必要的判断条件，使它安全。
3.当输入不可信任数据时，要在该数据的内容和格式上同时加以检查。
对于整数，应该检查数据大小是否超出了能够表示的范围；对于输入的字符串，要确保长度没有溢出，保证每一个字符都是有效的。
4.对经常使用的类似的SQL语句应使用绑定变量的方法，避免数据库执行类似SQL语句时重复解析、重复访问数据文件的行为。
5.程序编码结束后，应对代码进行优化，提高应用处理SQL的性能。
6.禁止使用通配符的方式进行数据的插入操作。
7.采用数据库作为系统间接口方式时，应建立独立的接口表，并按最小化特权原则进行授权。
4应用安全分析
4.1安全需求
系统安全本质上属于信任问题，要保证应用安全，就必须将解决各种操作过程中不可信问题。
安全的几个基本要素为机密性、完整性、可用性、可审计性、不可抵赖性等方面的安全要求。
机密性要求保护数据内容不能泄露，加密是实现机密性的要求的常见手段。
完整性要求保护数据内容是完整、没有被篡改的。
可用性要求保护资源是可被按照需要访问。
可审计性对出现的安全问题提供调查的依据和手段。
不可抵赖性建立有效的责任机制，防止用户否认其行为。
4.2安全威胁
4.2.1Web安全漏洞
根据结合国网系统安全检测项目常见安全问题及OWASP组织发布的安全漏洞，系统中存在的需要解决的安全风险如下：
序号
安全威胁
产生环节
1
SQL注入
编码
2
失效的身份认证及会话管理
设计、编码
3
跨站脚本（XSS）
编码
4
点击劫持（ClickJacking）
编码
4
不安全的直接对象引用
编码
5
安全配置错误
配置实施
6
敏感信息泄露
设计、编码
7
功能级访问控制缺失（失败的URL访问权限限制）
设计
8
跨站请求伪造（CSRF）
编码
9
使用含有已知漏洞的组件
管理、设计
10
未验证的重定向和转发
编码
11
传输层保护不足
设计、编码
12
文件上传漏洞
编码
13
不安全的加密存储
设计、编码
4.2.2拒绝服务
升级会员 