通用安全编码规范 (1)Word格式文档下载.docx
《通用安全编码规范 (1)Word格式文档下载.docx》由会员分享，可在线阅读，更多相关《通用安全编码规范 (1)Word格式文档下载.docx（49页珍藏版）》请在冰点文库上搜索。
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属性，这些都应用于用户登录成功的地方。
防御手段三：
字符过滤
通过函数进行过滤，能有效防止常见跨站脚本的跨站攻击。
主要过滤常见恶意脚本代码，如：
applet|meta|xml|blink|link|style|script|embed|object|iframe|frame
|frameset|ilayer|layer|bgsound|title|base>
OnX事件代码、Javascript、Vbscript和Style中的expression、behaviour、script、position等。
但过滤可能存在不完全的情况。
建立自己的XSS攻击库，方便测试和收集新的攻击方式，使过滤函数更加完善。
支持HTML，有效防止大部分攻击代码。
可能存在过滤不全的情况。
5.2SQL注入
5.2.1定义
什么是SQL注入
所谓SQL注入，就是通过把SQL命令插入到Web表单递交或输入域名或页面请求的查询字符串，最终达到欺骗服务器执行恶意的SQL命令。
通过递交参数构造巧妙的SQL语句，从而成功获取想要的数据。
简单来说，注入往往是应用程序缺少对输入进行安全性检查所引起的，攻击者把一些包含指令的数据发送给解释器，解释器会把收到的数据转换成指令执行，注入漏洞十分普遍，通常能在SQL查询、程序参数等中出现。
下图为SQL攻击原理图：
5.2.2危害
注入能导致数据丢失或数据破坏、缺乏可审计性或是拒绝服务。
注入漏洞有时甚至能导致完全接管主机，主要危害有以下几点：
绕过防火墙进行攻击
绕过web应用程序的验证过程
非法越权操作数据库内容
随意篡改网页内容
添加系统账户或数据库账户
上传和下载非法文件
本地溢出并获取系统最高权限
安装木马后门/僵尸网络
5.2.3解决方法
SQL注入实例：
StringsqlString=“SELECT*FROMusersWHEREfullname=”’+form.getFullName（）+’”ANDpassword=”’’’’‘+form.getPassword（）+’“”;
正常：
username=tony，password=123456
SELECT*FROMusersWHEREusername=tony’ANDpassword=’123456’
攻击：
username=tony，password=’OR‘1’=’1
SELECT*FROMusersWHEREusername=tony’ANDpassword=‘’OR‘1’=’1’
参数化查询预处理
对于JDBC而言，SQL注入攻击只对Statement有效，对PreparedStatement是无效的，这是因为PrepareStatement不允许在不同的插入时间改变查询的逻辑结构。
如验证用户是否存在的SQL语句为：
selectcount（*）fromusertablewherename=’用户名’andpswd=’密码’
如果在用户名字段中输入’or‘1=1’or‘1’=’1
或是在密码字段中输入1’or‘1’=’1
将绕过验证，但这种手段只对Statement有效，对PreparedStatement无效，PreparedStatement相对Statement有以下优点：
防注入攻击
多次运行速度快
防止数据库缓冲区溢出
代码的可读性可维护性好
5.3恶意脚本执行
5.3.1定义
恶意文件执行是一种能够威胁任何网站形式的漏洞，只要攻击者在具有引入（include）功能程式的参数中修改参数内容，WEB服务器便会引入恶意程序内容从而收到恶意文件执行漏洞攻击。
5.3.2危害
攻击者可利用恶意文件执行漏洞进行攻击取得WEB服务器控制权，进行不法利益或获取经济利益。
5.3.3解决方法
验证输入，验证上传文件名
检查上传文件的大小
5.4文件上传漏洞
5.4.1定义
Web应用程序在处理用户上传的文件时，没有判断文件的扩展名是否在允许的范围内，就把文件保存在服务器上，导致恶意用户可以上传任意文件，甚至上传脚本木马到web服务器上，直接控制web服务器。
5.4.2危害
攻击者可利用文件上传功能，上传Webshell从而控制整个主机系统。
5.4.3解决方案
检查上传文件扩展名白名单，不属于白名单内，不允许上传。
上传文件的目录必须是http请求无法直接访问到的。
如果需要访问的，必须上传到其他（和web服务器不同的）域名下，并设置该目录为不解析jsp等脚本语言的目录。
上传文件要保存的文件名和目录名由系统根据时间生成，不允许用户自定义。
图片上传，要通过处理（缩略图、水印等），无异常后才能保存到服务器。
上传文件需要做日志记录，请参照“ErrorHandingandLogging章节”。
5.5传输敏感信息未使用安全通道
5.5.1定义
对于未加密的敏感数据在网络上传输时，需要使用安全的通道。
否则应用程序将暴露身份验证或会话令牌。
5.5.2危害
攻击者能够取得或者篡改机密的或是私有的信息；
攻击者通过这些私密信息的窃取从而进行进一步的攻击；
造成企业形象破损，用户满意度下降，甚至会有法律诉讼等。
5.5.3解决方案
提供合理的保护机制；
对于敏感数据的传输，对所有连接都要使用TLS；
在传输前对单个数据都要进行加密；
（如XML-Encryption）
在传输前对信息进行签名；
（如XML-Signature）
正确的使用这些机制；
使用标准的强加密算法；
合理管理密钥和证书；
在使用前验证SSL证书；
5.6信息泄漏和错误处理不当
5.6.1定义
应用程序没有统一的异常处理页面，导致敏感信息泄漏，常常产生错误信息并显示给使用者。
很多时候，这些错误信息是非常有利于攻击者发起攻击，因为他们揭示实施细节或者对利用漏洞有用的开发信息。
示例：
看到此信息，攻击者可以做以下判断：
a）数据库是oracle
b）查询语句的列数不正确
根据这个判断，攻击者调整get请求的内容，最终达到获取数据库所有数据的目的。
5.6.2危害
泄漏太多细节（如错误堆栈跟踪信息、SQL语句等等）；
登录失败后，通知用户是否用户ID或密码出错-登录失败可能是由于ID或密码错误造成的。
这为一个对关键资产发动暴力破解的攻击者提供重要信息。
5.6.3解决方案
通过web.xml配置文件实现，产生异常或者错误时跳转到统一的错误处理页面，避免泄漏过多敏感信息。
n<
error-page>
exception-type>
java.lang.Throwable<
/exception-type>
location>
/error.jsp<
/location>
/error-page>
针对登录尝试的攻击，如果输入用户名或者是口令错误，可以使用相同的报错信息，比如都提示“输入用户名或密码错误！
”。
5.7跨站请求伪造
5.7.1定义
Cross-SiteRequestForgery（CSRF），跨站请求伪造攻击。
攻击者在用户浏览网页时，利用页面元素（例如img的src），强迫受害者的浏览器向Web应用程序发送一个改变用户信息的请求。
5.7.2危害
由于发生CSRF攻击后，攻击者是强迫用户向服务器发送请求，所以会造成用户信息被迫修改，更严重者引发蠕虫攻击。
CSRF攻击可以从站外和站内发起。
从站内发起CSRF攻击，需要利用网站本身的业务，比如“自定义头像”功能，恶意用户指定自己的头像URL是一个修改用户信息的链接，当其他已登录用户浏览恶意用户头像时，会自动向这个链接发送修改信息请求。
从站外发送请求，则需要恶意用户在自己的服务器上，放一个自动提交修改个人信息的html页面，并把页面地址发给受害者用户，受害者用户打开时，会发起一个请求。
如果恶意用户能够知道网站管理后台某项功能的URL，就可以直接攻击管理员，强迫管理员执行恶意用户定义的操作。
5.7.3代码示例
一个没有CSRF安全防御的代码如下：
代码中接收用户提交的参数“email,tel,realname”，之后修改了该用户的数据，一旦接收到一个用户发来的请求，就执行修改操作。
提交表单代码：
当用户点提交时，就会触发修改操作。
5.7.4解决方案
要防御CSRF攻击，必须遵循一下三步：
1、 在用户登陆时，设置一个CSRF的随机TOKEN，同时种植在用户的cookie中，当用户浏览器关闭、或用户再次登录、或退出时，清除token。
2、 在表单中，生成一个隐藏域，它的值就是COOKIE中随机TOKEN。
3、 表单被提交后，就可以在接收用户请求的web应用中，判断表单中的TOKEN值是否和用户COOKIE中的TOKEN值一致，如果不一致或没有这个值，就判断为CSRF攻击，同时记录攻击日志（日志内容见“ErrorHandingandLogging”章节）。
由于攻击者无法预测每一个用户登录时生成的那个随机TOKEN值，所以无法伪造这个参数。
代码中$csrfToken.hiddenField将会生成一个隐藏域，用于生成验证token，它将会作为表单的其中一个参数一起提交。
5.8访问控制缺陷
5.8.1权限提升
5.8.1.1定义
访问控制过程中身份验证有缺陷，导致用户越权访问信息。
5.8.1.2危害
由于web应用程序没有做权限控制，或仅仅在菜单上做了权限控制，导致的恶意用户只要猜测其他管理页面的URL，就可以访问或控制其他角色拥有的数据或页面，达到权限提升目的。
这个威胁可能导致普通用户变成管理员权限。
5.8.1.3代码示例
一个仅仅做了菜单控制的代码：
恶意用户，可以直接猜测“管理所有用户”的页面，通过URL访问，看到管理员页面。
5.8.1.4解决方案
在打开管理页面URL时，首先判断当前用户是否拥有该页面的权限，如果没有权限，就判定为“权限提升”攻击，同时记录安全日志。
建议使用成熟的权限框架处理权限问题，比如springsecurity。
5.8.2不安全的直接对象引用
5.8.2.1定义
所谓“不安全的直接对象引用”，指的是一个已经授权的用户，通过更改访问时的一个参数，从而访问到原本并没有得到授权的对象。
Web应用往往在生成Web页面时会用它的真实名字，且并不会对所有的对象访问时来检查用户权限，所以这就造成不安全的对象直接引用漏洞。
我们看如下的一个示例，也许这样就更容易理解什么是不安全的对象直接引用。
攻击者发现他自己的参数是6065，即?
acct=6065;
他可以直接更改参数为6066，即?
acct=6066;
这样他就可以直接看到6066用户的账户信息。
5.8.2.2危害
这种漏洞损害参数所引用的所有数据。
除非名字空间很稀疏，否则攻击者很容易访问该类型的所有数据。
或者恶意用户可以删除或修改其他人数据。
5.8.2.3代码示例
以下代码存在这个漏洞，web应用在修改用户个人信息时，从从用户提交的request参数（用户可控数据）中，获取了userid，执行修改操作。
修改用户个人信息页面：
表单中，将用户的userid作为隐藏字段，提交给处理修改个人信息的应用。
下面代码是修改个人信息的应用：
这段代码是从request的参数列表中，获取userid，也就是表单提交上来的userid，之后修改userid对应的用户数据。
而表单中的userid是可以让用户随意修改的。
5.8.2.4解决方案
从用户的加密认证cookie中，获取当前用户的id，并且需要在执行的S
升级会员 