通用安全编码规范 (1).docx

通用安全编码规范 (1).docx

《通用安全编码规范 (1).docx》由会员分享，可在线阅读，更多相关《通用安全编码规范 (1).docx（49页珍藏版）》请在冰豆网上搜索。

通用安全编码规范

天翼电子商务有限公司

信息技术部

【】通用安全编码规范

<文档编号：

BESTPAY-DMAQ-05>

保密申明

本文档版权由天翼电子商务有限公司信息技术部所有。

未经天翼电子商务有限公司信息技术部书面许可，任何单位和个人不得以任何形式摘抄、复制本文档的部分或全部，并以任何形式传播

目录

1 目的 4

2 范围 4

3 规范概述 4

4 安全编码的原则 5

5 WEB应用程序常见安全问题 5

5.1 跨站脚本攻击 6

5.1.1 定义 6

5.1.2 危害 6

5.1.3 解决方法 7

5.2 SQL注入 9

5.2.1 定义 9

5.2.2 危害 10

5.2.3 解决方法 10

5.3 恶意脚本执行 11

5.3.1 定义 11

5.3.2 危害 12

5.3.3 解决方法 12

5.4 文件上传漏洞 12

5.4.1 定义 12

5.4.2 危害 12

5.4.3 解决方案 12

5.5 传输敏感信息未使用安全通道 13

5.5.1 定义 13

5.5.2 危害 13

5.5.3 解决方案 13

5.6 信息泄漏和错误处理不当 13

5.6.1 定义 13

5.6.2 危害 14

5.6.3 解决方案 14

5.7 跨站请求伪造 15

5.7.1 定义 15

5.7.2 危害 15

5.7.3 代码示例 15

5.7.4 解决方案 16

5.8 访问控制缺陷 17

5.8.1 权限提升 17

5.8.2 不安全的直接对象引用 18

5.9 不安全的加密 20

5.9.1 定义 20

5.9.2 弱加密示例 21

5.9.3 解决方案 21

5.10 限制URL访问失效 21

5.10.1 定义 21

5.10.2 解决方案 22

5.11 Session管理 22

5.11.1 Cookiehttponlyflag 22

5.11.2 CookieSecureflag 23

5.11.3 SessionExpires 25

5.12 日志和监测 26

6 WEB应用程序安全编码要点 26

6.1 SOCKET网络安全编程要求 26

6.2 安全认证要求 27

6.2.1 图片验证码 27

6.2.2 短信验证码 28

6.3 加密方法及强度要求 29

6.4 输入验证 31

6.4.1 什么是输入 31

6.4.2 如何处理输入 37

6.5 输出编码 42

6.5.1 输出编码的种类 42

6.5.2 输出编码的必要性 42

6.5.3 安全输出编码方式 42

7 翼支付常用WEB框架安全 44

7.1 Struts2：

Action字段没有验证器（ActionFiledWithoutValidator） 44

7.1.1 定义 44

7.1.2 危害 44

7.2 Struts2：

有重复的Action字段验证器（DuplicateActionFieldValidators） 45

7.2.1 定义 45

7.2.2 危害 45

7.2.3 示例 45

7.3 Struts2：

重复的验证文件（DuplicateValidationFiles） 45

7.3.1 定义 45

7.3.2 危害 46

7.4 Struts2：

重复的验证器（DuplicateValidators） 46

7.4.1 定义 46

7.4.2 危害 46

7.5 Struts2：

未声明验证器（UndeclaredValidator） 46

7.5.1 定义 46

7.5.2 危害 47

7.5.3 示例 47

7.6 Struts2：

未经验证的Action（UnvalidateAction） 47

7.6.1 定义 47

7.6.2 危害 47

7.7 Struts2：

验证文件无对应的Action（ValidationFileWithoutAction） 47

7.7.1 定义 47

7.8 Struts2：

验证器无Action域（ValidatorWithoutActionField） 48

7.8.1 定义 48

7.9 SpringMVC的不良做法：

请求参数绑定持久对象（SpringMVCPractices：

RequestParametersBoundintoPersistedObjects） 48

7.9.1 定义 48

7.9.2 危害 48

7.9.3 示例：

48

8 附录 49

8.1 安全性测试_checklist 49

8.2 代码安全审计checklist 49

1目的

为保障天翼电子商务有限公司（以下简称“翼支付”）支付平台的安全性，构建安全健壮的程序，结合翼支付Web安全遇到的问题以及启明星辰安全研究实验室在Web攻防及代码安全的理论和实践积累，特制定本规范，旨在为翼支付开发团队提供设计及编写应用程序时普遍应该遵循的原则。

为充分理解本规范内容，请：

Ø了解应用程序将会受到的威胁；

Ø理解必须考虑的威胁；

Ø在程序设计阶段考虑到这些威胁。

2范围

本规范从应用安全开发的角度出发，结合翼支付平台系统的特点和常见的安全问题，给出支付平台应用系统安全开发的规范。

供翼支付平台应用系统开发部门内部使用，适用翼支付平台应用系统项目开发的工作。

本规范定义了翼支付平台应用系统安全开发和编码安全相关的技术要求。

本规范主要提供设计应用程序时应该遵循的一些指南和原则。

在应用程序易受攻击的重要环节应采用系统的方法。

将重点放在程序部署、输入验证、身份验证和授权、加密及数据敏感度、配置、会话、异常管理以及适当的审核和记录策略上，以确保应用程序的安全可靠性。

3规范概述

当今电子商务时代，应用系统为架构设计人员、开发人员提出一系列复杂的安全问题。

为应对这些安全问题，须要应用安全思想来构建应用程序。

在初始阶段，应该使用可靠的安全体系结构和设计方法，同时要结合考虑应用程序的部署以及企业的安全策略。

如果不能做到这一点，将导致在现有基础结构上部署应用程序时，导致危及应用系统的安全性。

本规范提供初步的安全体系结构和设计指南，并按照翼支付平台常见的应用程序漏洞类别进行组织。

这些指南是应用系统程序安全的重要方面，并且是经常发生错误的领域。

4安全编码的原则

Ø程序只实现你指定的功能

Ø永远不要信任用户的输入，对用户输入数据做有效性检查

Ø必须考虑意外情况并进行处理

Ø不要试图在发现错误之后继续执行

Ø尽可能使用安全函数进行编程

Ø小心、认真、细致地编程

5Web应用程序常见安全问题

下面的安全问题是根据应用程序漏洞类别描述的。

实际经验表明，如果这些领域的设计存在薄弱环节，将会导致安全漏洞。

下表列出了漏洞的类别，每个类别都突出显示了由于设计不当可能会导致的潜在问题。

漏洞类别

由于设计不当而引起的潜在问题

输入验证

嵌入到查询字符串、表单字段、cookie和HTTP头中的恶意字符串的攻击。

这些攻击包括命令执行、跨站点脚本（XSS）、SQL输入和缓冲区溢出攻击。

身份验证

标识欺骗、密码破解、特权提升和未经授权的访问。

授权

访问保密数据或受限数据、篡改数据以及执行未经授权的操作。

配置管理

对管理界面进行未经授权的访问、具有更新配置数据的能力以及对用户账户和账户配置文件进行未经授权的访问。

敏感数据

泄漏保密信息以及篡改数据。

会话管理

捕捉会话标识符，从而导致会话劫持及标识欺骗。

加密

访问保密数据或者账户凭据，或者二者均能访问。

参数操作

路径遍历攻击、命令执行以及绕过访问控制机制，从而导致信息泄漏、特权提升和拒绝服务。

异常管理

拒绝服务和敏感的系统级详细信息的泄漏。

审核和记录

不能发现入侵迹象、不能验证用户操作，以及在诊断问题时出现困难。

5.1跨站脚本攻击

5.1.1定义

什么是跨站脚本攻击：

跨站脚本攻击（通常简写为XSS）是最普通的web应用安全漏洞，当应用程序在发送给浏览器的页面中包含用户提供的数据，没有经过严格验证或转义，那么攻击者就有可能利用网站程序对用户输入过滤不严，输入可以显示在页面上对其他用户造成影响的HTML代码，从而盗取用户资料、利用用户身份进行某种动作或者对访问者进行病毒侵害的一种攻击方式。

5.1.2危害

Ø敏感数据被获取（cookie盗取）

Ø网络钓鱼

Ø获取web用户的网页内容

ØSessionRiding（CSRF攻击）

Ø获取用户的键盘击键数据

ØWeb僵尸

ØXSS蠕虫

攻击者能在受害者浏览器中执行脚本以劫持用户会话、迫害网站、插入恶意内容、重定向用户、使用恶意软件劫持用户浏览器等等。

入侵者便通过技术手段在某个页面里插入一个恶意HTML代码，例如记录论坛保存的用户信息（Cookie），由于Cookie保存了完整的用户名和密码资料，用户就会遭受安全损失。

如这句简单的javascript脚本就能轻易获取用户信息：

alert（document.cookie），它会弹出一个包含用户信息的消息框。

入侵者运用脚本就能把用户信息发送到他们自己的记录页面中，稍作分析便获取了用户的敏感信息。

跨站脚本攻击的危险，在如今WEB安全越来越得到重视，他的危险性也越来越大。

有效防止跨站脚本攻击，是WEB程序是否安全的一个重要标准。

5.1.3解决方法

主要防御方式

5.1.3.1验证输入

验证输入很简单，检查每个输入的有效性。

这可能意味着很多东西，但在典型的和简单的情况下，这意味着检查输入类型和数据的长度。

例如，如果你是从一个文本框接受一个标准的邮政编码，你会知道，唯一有效的类型是一个数字（0-9），而长度应该是6，不能多也不能少。

并非所有的案例都如此简答，但很多是相似的。

下图显示验证输入的架构。

这里的关键是，一切都进行验证，所有的输入，这并不来自于应用程序（包括用户输入，请求头，Cookie，数据库数据……）。

5.1.3.2编码输出

对于不支持HTML代码的地方，可用编码输出。

如：

Server.UrlEncode等方法编码输出。

优点：

安全可靠。

缺点：

不支持HTML代码。

对于验证输入的另一面就是编码输出。

编码输出，是用来确保字符被视为数据，而不是作为HTML元字符被浏览器解析。

这些技术定义一些特殊的“转义”字符。

没有正确转义的数据它仍然会在浏览器中正确解析。

编码输出只是让浏览器知道数据是不是要被解析，达到攻击无法实现的目的。

需要编码的部分：

HTML实体

HTML属性

Javascript

CSS

URL

5.1.3.3辅助防御方式

防御手段一：

iframesecurity=“restricted”

保护级别：

★★★★

描述：

通过设置iframesecurity=“restricted”，能有效防止iframe类的攻击（对IE有效）。

优点：

有效防止iframe的攻击。

防御手段二：

HttpOnly

保护级别：

★★★★

描述：

设置Cookie的HttpOnly属性，有效地防止Cookie通过脚本泄密（IE6SP1以上、Firefox3）。

优点：

有效保护了用户的Cookie信息。

应用举例：

系统中，所有登录验证的地方，验证成功后设置authCookie.HttpOnly=true,设置Cookie的HttpOnly属性，这些都应用于用户登录成功的地方。

防御手段三：

字符过滤

保护级别：

★★★★

描述：

通过函数进行过滤，能有效防止常见跨站脚本的跨站攻击。

主要过滤常见恶意脚本代码，如：