WebAC -- Web访问控制方案

WebAC -- Web访问控制方案
WebAC -- Web访问控制方案

WEBAC

&

网站访问控制方案

目录

1 概述 (3)

1.1 前言 (3)

1.2 WEBAC简介 (4)

1.3 WEBAC实现方式 (4)

1.4 WEBAC特点 (5)

2 WEBAC开发与实现 (6)

2.1 基本原理 (6)

2.2 开发前准备 (7)

2.3 模块开发 (9)

发行管理模块 (9)

用户认证模块 (12)

UKEY操作状态 (14)

UKey硬件的状态 (16)

3 常见问题 (17)

3.1 页面基本元素 (17)

3.2 PIN码的问题 (18)

1概述

1.1 前言

许多收费网站都需要一个比传统“账号+密码”更有效的身份认证方式来认证用户的身份。道理很简单:在“账号+密码”的认证方式中,用户很容易将账号和密码与他人分享,即使网站加上同一时间一个账号只允许一人登录的限制也无济于事,因为用户可以与他人分时分享网站提供的各种收费服务。分享用户账号对用户来说是很方便的,但是对于网络公司来说却意味着潜在收入的减少,这无疑是网络公司不愿意看到的。

智能卡或类似USB电子钥匙的硬件认证方式可以满足收费网站的认证需求。这种认证方式要求用户需要同时提供硬件和账号密码才能登录访问网页,有效的

避免了用户共享账号带来的问题。Passbay也提供基于硬件UKey的SecureWeb 解决方案,但是在许多场合这种解决方案也有其不足之处:首先,硬件具有专用性。也就是说,一个硬件只能应用于某个特定的网站登录认证,而不具有其他的功能或用途,这难免让用户觉得其实用价值较低;此外,这种解决方案需要用户在终端安装驱动程序和客户端程序,给用户的使用带来不便,同时也给网络公司增加了额外的与网站运营无关的售后服务。

总的来说,目前普遍采用的基于智能卡或USB电子钥匙的硬件认证方式虽然可以满足收费网站控制用户登录访问的需求,但仍然具有较大的缺陷,不管是对于网络公司还是对于用户来说,这种方案都不能算是一个完美的解决方案。

1.2WEBAC简介

为满足收费网站控制用户登录和访问的需求,Passbay结合自身的优势推出WebAC网站访问控制方案,WebAC网站访问控制方案由硬件UKey、Passbay 安全管理软件和面向网站开发者的开发接口三个部分组成。方案允许网站拥有者在UKey中创建并管理用户登录账户,用户进入指定页面之后必须插入UKey才能完成登录或访问。这一方案保证只有合法持有UKey的用户才能享受到网站提供的服务,避免用户分享账号给网络公司带来的损失。

1.3WEBAC实现方式

Passbay? UKey WebAC网站访问控制方案通过随机数单向认证方式来验证用户身份和对用户账户进行管理。这一方案的实现原理如下:

网站在创建用户账户时,将用户账号和用于认证的一个字符串(SaltValue)写入UKey(由接口写入),并将上述两项值与PSA的序列号(SerialNumber)写入数据库(由开发者写入)。用户进入登录页面后,服务器端生成一随机数据(Random),通过网络传输至客户端。这一数据在客户端通过MD5算法进行计算,计算结果MD5Result = MD5(SerialNumber + AdminPass + Random + SaltValue)(由接口计算),计算完毕后,客户端将计算结果(MD5Result -c)与UKey的序列号(SerialNumber)和之前存入的用户账号通过Form提交给服务器

端。

服务器端通过序列号(SerialNumber)和用户名称在数据库里面查询到该用户记录的认证字符串(SaltValue),然后以与客户端相同的算法计算出MD5Result -s = MD5(SerialNumber + AdminPass + Random + SaltValue),计算完毕后将这一结果与客户端传输过来的MD5Result -c 进行比较,如果两个值相等,则表明终端插入的UKey就是之前创建的用户所使用的UKey,用户身份得到确认,网站可以据此对用户登录和访问实现精确的控制。

1.4WEBAC特点

1、提升用户身份认证的安全性

UKey自带Passbay密码管理功能组件,这一功能组件使用户登录网页的账号密码和网页URL可在创建用户账户时直接保存在UKey中,用户通过PIN 码验证后便可一键登录网页,避免用户记忆账号密码的麻烦,可以设置较为复杂的账号密码而无需担心用户遗忘账号密码,提升账号密码的安全性。此外,Passbay密码管理功能组件在保存账号密码的同时保存网页URL,并采用加密方式处理账号密码信息,有效防止网络钓鱼和盗号木马、病毒等窃取用户的账号密码,保护账号密码的安全。软硬件结合的身份认证方式也可以有效的提高用户身份认证的安全性。

2、加强对用户账号的管理和控制

只有合法持有UKey的用户才能登录网页,享受网络公司提供的各种服务,这便很好的避免了用户共享账号给网络公司带来的损失。这一方案的实现原理使得网站可以准确的确认用户身份,并在这一前提下设定用户用户登录和访问网页的权限,对用户的登录和访问实现精确的控制。

3、脱离ActiveX,易于开发

无需专门开发接口。网站开发者只需按照完全开放的WEBAC HTML接口规范开发网页即可实现这一方案提供的各种功能。WEBAC支持所有WEB开发语言

4、简单易用,易于部署

因为脱离ActiveX开发,所以不需要对IE安全的设置,用户只需将UKey 插入计算机,在通过PIN码认证后便可使用UKey中的信息登录网页,无需安装驱动程序和客户端软件,给用户使用带来极大的方便。

2 WEBAC开发与实现

2.1 基本原理

在网页上要实现基于硬件对用户进行身份认证,就必然需要网页能够访问硬件内所存储的数据。但是网页有基本的安全模型,“沙盒”(SandBox),目的就在限制网页对本地资源的访问能力,这两者实际上是矛盾的。Microsoft推出的ActiveX能够解决开发人员在实际开发中遇到的这个问题,但是ActiveX过于强大,事实上几乎无所不能。IE的做法是使用签名验证,然后提示用户认清控件来源,把选择权交给用户。这样就在用户端需要进行若干安全设置,部署这类系统在用户那里常常造成困扰,用户不知道怎么样去做设置,只能求助于技术支持人员,形成大量的售后支持需求。

WEBAC不使用ActiveX。其要点在于在用户终端运行一个具备本地资源访问权限的可执行程序,该程序负责:

1 与网页进行交互,获取网页对硬件的读写操作要求;

2 与硬件进行交互,执行读写硬件数据的操作;

WEBAC与硬件如何进行交互:

容易理解,就是利用硬件的API进行读写。

WEBAC与网页进行交互:

WEBAC利用预先定义的网页元素,来实现与网页的交互,比如网页里面有个Edit控件元素,其ID为IID_SecureWeb_I_SerialNumber,当硬件插入时WEBAC就会自动读出硬件的ID序列号,并将该控件的value属性赋值为序列号数据,这样网页就获知了当前插入的硬件的ID序列号,这样实现了WEBAC

与网页的交互;再例如,网页里面有个Edit控件元素,其ID为IID_SecureWeb_I_Signin,当终端用户按下此按钮,WEBAC就知道用户选择了登录操作,就执行登录过程所需要的运算并将运算结果传送给网页。

2.2 开发前准备

1 数据库

需要给数据库里面的用户表增加两个域:SerialNumber (建议变长字符串类型,长度32,可以为空),SaltValue(建议变长字符串类型,长度32,可以为空)(这个数据表域名可以自行确定)。当然您还可以增加别的以便更好的管理,比如,绑定UKey的时间(或者说是UKey的发行时间)等等。域名可以自行设定,不一定是按照这里说的做。(约束您开发的实际上只有那些页面元素的ID,其他都不作限定)。

2 页面语言

您可以选择ASP、https://www.360docs.net/doc/057124390.html,、JSP、PHP,这些无关紧要。实际上,如果您完全理解了WEBAC方案的原理,就会明白,任何页面程序开发语言其实都可以使用。只不过上述的几种我们提供了一个基本可以使用的示例代码。您可以在示例代码文件包里面找到相应的目录,然后解压出来即可。下面讲解中我们主要以ASP代码为例。

3 理解基本架构

利用WEBAC方案实现网站用户身份认证,需要实现两个功能模块:UKey 的发行|管理模块(包括发行、修改、删除、回收等等功能),终端用户的认证模块。按照一般的说法,前者面向网站运营维护人员,属于网站后台,后者面向网站用户,始于网站前台。

4 理解基本概念

UKey硬件序列号

每个UKey硬件都有一个唯一的硬件序列号,由16位数字组成。

登录入口

一个登录入口由一个名称和一个URL两项信息组成。登录入口在WEBAC 相关文档里面称为“应用”。登录入口的名称(“应用名”)必须是唯一的,能够与其他登录入口相区别。URL有两个作用,一是在终端插入UKey时,需要弹出登录入口时,会主动弹出的网址;二是URL的域名部分会用于检查,使该应用对应的用户在同一域名下不同的URL也可以进行认证。一个网站可以包含多个登录入口,一个登录入口在同一个网站下(以域名为准)可以有多个登录网址。每个UKey针对一个登录入口只能创建一个账户。如果一个UKey用户需要登录多个网站,就要设置多个登录入口,并在每个用户UKey内为每个登录入口创建一个账户。

用户账户信息

用户账户信息由三部分组成:账户名称、认证种子数据和账户管理密码。账户名称就是UKey所代表的用户的名称,主要用于显示;认证种子数据是用于认证的关键数据;账户管理密码是由网站运维人员掌握,在创建的时候,提供,写入到UKey里面,在对用户的账户信息进行管理包括删除、修改的时候,需要提供账户管理密码才有权进行。账户管理密码的作用在于避免非本网站运维人员变更UKey账户信息。不同的UKey可以有不同的账户管理密码,也可以相同。如果不同,账户管理密码也可以保存在数据库该用户的记录里面,这样一定程度上会更安全。

2.3 模块开发

2.3.1发行管理模块

1 发行UKey

发行UKey的页面,需要包含以下页面元素:

INPUT元素:

IID_SecureWeb_I_SerialNumber:硬件序列号

IID_SecureWeb_I_ApplicationName:应用名

IID_SecureWeb_I_URL:应用URL

IID_SecureWeb_I_UserName:用户账户名称

IID_SecureWeb_I_SaltValue:认证种子数据

IID_SecureWeb_I_AdminPass:账户管理密码

按钮元素

IID_SecureWeb_B_Create:创建账户按钮

创建流程:

1 【页面需要编码完成的流程】应用名、应用URL、账户管理密码可以预先赋值value属性,认证种子数据value属性由服务器端预先生成并赋值,用户账户名称可以由运维人员输入,如果用户已经存在,也可以预先赋值,硬件序列号将由WEBAC程序自动赋值。

2 操作人员点击“创建账户按钮”后,WEBAC程序将将上述所有信息写入UKey;

3 【页面需要编码完成的流程】页面需要做的工作主要就是:创建或者修改用户记录,将硬件序列号和认证种子数据保存进数据库。这里需要注意检查不能让一个硬件序列号的绑定多个用户记录。

请参考示例中create.asp创建流程的服务器端代码片段:

<%

if request.Form("action")="dbcreate" then

set rs=conn.execute("select * from psa_users where SerialNumber='"&request.form("IID_SecureWeb_I_SerialNumber")&"'")

if not rs.eof then

conn.execute("delete from psa_users where SerialNumber='"&request.form("IID_SecureWeb_I_SerialNumber")&"'") end if

rs.close

set rs=nothing

Conn.ExeCute("INSERT INTO psa_users (UserName, SerialNumber, AdminPass, SaltValue) values ('"&request.form("IID_SecureWeb_I_UserName")&"',

'"&request.form("IID_SecureWeb_I_SerialNumber")&"',

'"&request.form("IID_SecureWeb_I_AdminPass")&"',

'"&request.form("IID_SecureWeb_I_SaltValue")&"')")

response.write ""

end if

%>

2 修改UKey

修改和发行基本类似,只不过需要根据检查账户是否存在,以及验证账户管理密码是够正确。

INPUT元素:

IID_SecureWeb_I_SerialNumber:硬件序列号

IID_SecureWeb_I_ApplicationName:应用名

IID_SecureWeb_I_URL:应用URL

IID_SecureWeb_I_UserName:用户账户名称

IID_SecureWeb_I_AdminPass:账户管理密码

IID_SecureWeb_I_AdminPassNew:新的账户管理密码

按钮元素

IID_SecureWeb_B_Update:修改账户按钮

修改流程:

1 【页面需要编码完成的流程】应用名、账户管理密码可以预先赋值value 属性,其他信息:应用URL、新的账户管理密码,用户账户名称等,可以通过设置相应元素的value属性赋值,进行修改。

2 操作人员点击“修改账户按钮”后,WEBAC程序将在验证账户管理密码后,将上述所有信息写入UKey;

3 【页面需要编码完成的流程】页面需要做的工作主要就是:修改用户记录相关域。

3 删除账户

删除指定账户。删除前会检查账户是否存在,以及验证账户管理密码是够正确。

INPUT元素:

IID_SecureWeb_I_ApplicationName:应用名

IID_SecureWeb_I_AdminPass:账户管理密码

按钮元素

IID_SecureWeb_B_Delete:删除账户按钮

删除流程:

1 【页面需要编码完成的流程】应用名、账户管理密码可以预先赋值value 属性。

2 操作人员点击“删除账户按钮”后,WEBAC程序将在验证账户管理密码后,将UKey内保存的指定应用的信息删除;

3 【页面需要编码完成的流程】页面需要做的工作主要就是:修改或者删除用户相关记录。

4 回收UKey

按钮元素

IID_SecureWeb_B_Format:格式化UKey按钮

2.3.2用户认证模块

INPUT元素:

IID_SecureWeb_I_SerialNumber:硬件序列号

IID_SecureWeb_I_SigninType:网站的登陆方式(value属性为1表示自动登录)

IID_SecureWeb_I_Random:临时生成的用于认证的随机数据

IID_SecureWeb_I_MD5Result:用于接收终端计算结果

按钮元素

IID_SecureWeb_B_Signin:登录按钮(用户认证)

认证流程:

1 【页面需要编码完成的流程】网页服务器端生成一串临时的用于认证的随机数据,并保存起来,然后赋值给IID_SecureWeb_I_Random。

2 WEBAC程序根据以下算法计算出一个字符串:

MD5Result_Client = MD5(SerialNumber + AdminPass + Random + SaltValue)

并将值赋予IID_SecureWeb_I_MD5Result。

3 【页面需要编码完成的流程】认证页面在SUBMIT后,在服务器端根据上传的硬件序列号找到UKey所代表的用户的记录,并读出记录里在发行时写入该UKey的种子认证数据,按照同样的算法计算:

MD5Result_Server = MD5(SerialNumber + AdminPass + Random + SaltValue)

并将此数据与终端上传的MD5Result_Client进行比较,如果一致,表明认证通过。

认证使用的算法为MD5,这个算法在不同的语言中,结果都是一致的。

请参考示例中login.asp创建流程的服务器端代码片段:

<%

if request.form("action")="sub" then

set rs=conn.execute("select * from psa_users where UserName='"&request.form("IID_SecureWeb_I_UserName")&"' and

SerialNumber='"&request.form("IID_SecureWeb_I_SerialNumber")&"' ") if not rs.eof then

MD5Result_s=md5(rs("SerialNumber")&rs("AdminPass")&Session("GetC ode")&rs("SaltValue"))

else

MD5Result_s=Session("GetCode") '可以为任意非空值

end if

'rs.close

'set rs=nothing

if

UCase(MD5Result_s)=Left(request.form("IID_SecureWeb_I_MD5Result"),32) then

response.Write("验证通过")

'此处可自行添加验证通过后其他页面动作。例如session赋值,页面转向等

else

response.Write "验证未通过"

response.Write

"
S--"&MD5Result_s&"--"&UCase(MD5Result_s)

response.Write

"
C--"&request.form("IID_SecureWeb_I_MD5Result")&"--"

response.Write

"
S--"&rs("SerialNumber")&"--"&rs("AdminPass")&"--"&Session("GetCode" )&"--"&rs("SaltValue")

response.Write

"
C--"&request.form("IID_SecureWeb_I_SerialNumber")&"--"&request.for m("IID_SecureWeb_I_Random")

end If

rs.close

set rs=nothing

End if

%>

2.3.3UKEY操作状态

在上述所有流程的交互过程中,WEBAC通过以下一个页面元素传递操作执行的状态和结果:

INPUT元素

IID_SecureWeb_I_Status:操作状态

0表示成功,其他数值表示错误代码。错误代码所对应的内容请参考开发手册。

可以通过定义该元素的onpropertychange属性,来等待WEBAC操作结果并触发相应的处理。例如创建发行用户的页面可以使用以下的代码:

2.3.4UKey硬件的状态

页面有时候需要知道UKey的插入状态,这个可以通过元素IID_SecureWeb_I_SerialNumber的value属性来判断,如果为空字符串,则表明未插入,如果是一个长度为16字节的数字字符串,并且是合法的序列号,则表明已插入。例如:

3 常见问题

3.1 页面基本元素

设计好页面后,请注意需要在页面内添加一个id为

IID_SecureWeb_Support的元素,只有这样,WEBAC程序才会处理此页面。例如示例中body元素的id:

3.2 PIN码的问题

UKey 有一个PIN码,验证用户使用UKey的权限时候,避免丢失后被人滥用。PIN码由终端用户自行管理,可以取消,可以修改。如果连续错误输入导致锁定,将需要运维人员重新设置账户信息。运维人员在处理锁定的UKey时,只需要格式化,然后重新发行即可。

WEB安全编程技术规范(V1.0)

1.范围 本规范从应用开发安全管理要求出发,给出了WEB编码安全的具体要求。供浙江公司IT系统内部和厂商使用,适用于省市公司IT系统项目建设WEB工作。 本规范明确定义了JA V A、PHP应用开发中和WEB编码安全相关的技术细节。 与JA V A编码安全相关的内容包括:跨站脚本攻击及解决方法、SQL注入及解决方法、恶意文件执行及解决方法、不安全的直接对象引用及解决方法、跨站请求伪造及解决方法、信息泄露和错误处理不当及解决方法、残缺的认证和会话管理及解决方法、不安全的加密存储及解决方法、不安全的通信及解决方法、限制URL 访问实效解决方法。 与PHP编码安全相关的内容包括:变量滥用及解决方法、文件打开漏洞及解决方法、文件包含漏洞及解决方法、文件上传漏洞及解决方法、命令执行漏洞及解决方法、变量类型缺陷及解决方法、警告及错误信息处理解决方法、PHP与MYSQL 组合的SQL注入解决方法、跨站脚本解决方法。 2.1.规范概述 Web应用程序为结构设计人员、设计人员和开发人员提出一系列复杂的安全问题。最安全、最有能力抵御攻击的Web应用程序是那些应用安全思想构建的应用程序。 在设计初始阶段,应该使用可靠的体系结构和设计方法,同时要结合考虑程序部署以及企业的安全策略。如果不能做到这一点,将导致在现有基础结构上部署应用程序时,要不可避免地危及安全性。 本规范提供一系列安全的体系结构和设计指南,并按照常见的应用程序漏洞类别进行组织。这些指南是Web应用程序安全的重要方面,并且是经常发生错误的领域。

2.实现目标 使用本规范可以实现: 1.确定安全Web应用程序的重要体系结构和设计问题。 2.设计时考虑重要部署问题。 3.制定能增强Web应用程序输入验证的策略。 4.设计安全的身份验证和会话管理机制。 5.选择适当的授权模型。 6.实现有效的帐户管理方法,并保护用户会话。 7.对隐私、认可、防止篡改和身份验证信息进行加密。 8.防止参数操作。 9.设计审核和记录策略。 3.安全编码原则 1.程序只实现你指定的功能 2.永不要信任用户输入,对用户输入数据做有效性检查 3.必须考虑意外情况并进行处理 4.不要试图在发现错误之后继续执行 5.尽可能使用安全函数进行编程 6.小心、认真、细致地编程 4.安全背景知识 本规范主要提供设计应用程序时应该遵循的一些指南和原则。为充分理解本规范内容,请:了解应用程序将会受到的威胁,以确保通过程序设计解决这些问题。解需要考虑的威胁。在程序设计阶段应该考虑到这些威胁。 在应用程序易受攻击的重要环节应用系统的方法。将重点放在程序部署、输入验证、身份验证和授权、加密及数据敏感度、配臵、会话、异常管理以及适当的审核和记录策略上,以确保应用程序具有责任性。

Web安全系统测试要求规范

DKBA DKBA 2355-2009.7 .2cto.红黑联盟收集整理 Web应用安全测试规V1.2 2009年7月5日发布2009年7月5日实施 所有侵权必究 All rights reserved

修订声明Revision declaration 本规拟制与解释部门: 安全解决方案部电信网络与业务安全实验室、软件公司安全TMG、软件公司测试业务管理部 本规的相关系列规或文件: 《Web应用安全开发规》 相关国际规或文件一致性: 《OWASP Testing Guide v3》 《信息安全技术信息安全风险评估指南》 《Information technology Security techniques Management of information and communications technology security》-ISO 13335 替代或作废的其它规或文件: 无 相关规或文件的相互关系: 本规以《Web应用安全开发规》为基础、结合Web应用的特点而制定。

目录Table of Contents 1概述 (7) 1.1背景简介 (7) 1.2适用读者 (7) 1.3适用围 (7) 1.4安全测试在IPD流程中所处的位置 (8) 1.5安全测试与安全风险评估的关系说明 (8) 1.6注意事项 (9) 1.7测试用例级别说明 (9) 2测试过程示意图 (10) 3WEB安全测试规 (11) 3.1自动化W EB漏洞扫描工具测试 (11) 3.1.1AppScan application扫描测试 (12) 3.1.2AppScan Web Service 扫描测试 (13) 3.2服务器信息收集 (13) 3.2.1运行权限测试 (13) 3.2.2Web服务器端口扫描 (14) 3.2.3HTTP方法测试 (14) 3.2.4HTTP PUT方法测试 (15) 3.2.5HTTP DELETE方法测试 (16) 3.2.6HTTP TRACE方法测试 (17) 3.2.7HTTP MOVE方法测试 (17) 3.2.8HTTP COPY方法测试 (18) 3.2.9Web服务器版本信息收集 (18) 3.3文件、目录测试 (20) 3.3.1工具方式的敏感接口遍历 (20) 3.3.2Robots方式的敏感接口查找 (21)

基于WEB的应用系统安全方案

第二章系统安全的需求分析 本章从数据安全和业务逻辑安全两个角度对应用系统的安全进行需求分析,主要包括保密性需求、完整性需求、可用性需求三部分;随后对业务逻辑安全需求进行了分析,包括身份认证、访问控制、交易重复提交控制、异步交易处理、交易数据不可否认性、监控与审计等几个方面;最后还分析了系统中一些其它的安全需求。 2.1 数据安全需求 2.1.1 数据保密性需求 数据保密性要求数据只能由授权实体存取和识别,防止非授权泄露。从目前国内应用的安全案例统计数据来看,数据保密性是最易受到攻击的一个方面,通常表现为客户端发生的数据泄密,包括用户的基本信息、账户信息、登录信息等的泄露。在应用系统中,数据保密性需求通常主要体现在以下几个方面:A.客户端与系统交互时输入的各类密码:包括系统登录密码、转账密码、凭证查询密码、凭证交易密码等必须加密传输及存放,这些密码在应用系统中只能以密文的方式存在,其明文形式能且只能由其合法主体能够识别。 以网银系统为例,在网银系统中,通常存有四种密码:系统登录密码、网银转账密码、柜面交易密码及一次性密码。系统登录密码用来认证当前登录者为指定登录名的合法用户,网银用户的登录密码和网银转账密码由用户在柜面开户时指定,用户在首次登录网银系统时,系统必须强制用户修改初始密码,通常要求长度不得少于六位数,且不能是类似于111111、1234567、9876543等的简单数字序列,系统将进行检查。 网银转账密码是指网银系统为巩固用户资金安全,在涉及资金变动的交易中对用户身份进行了再认证,要求用户输入预设的密码,网银交易密码仅针对个人用户使用,企业用户没有网银交易密码。建立多重密码机制,将登录密码与网银转账密码分开管理,有利于加强密码的安全性。由于用户在使用网银时每次都必须先提供登录密码,故登录密码暴露的机会较多,安全性相对较弱;但登录网银的用户并不是每次都会操作账户资金的,所以专门设定网银转账密码可加强账户

网站WEB应用安全措施要求规范

网站WEB应用安全措施要求规范 1.安全防范措施要求 (1)数据保密性:数据加密主要是防止非授权用户截获并使用该数据,网站中有保密要求的信息只能供经过授权允许的人员,并且以经过允许的方式使用。 (2)数据完整性:使用一种方案来确认同站上的数据在传输过程中没有被篡改,而造成信息完整性破坏的原因可以分为人为的和非人为的两种: 非人为的因素:如通信传输中的干扰噪声,系统硬件或软件的故障等; 人为因素:包括有意的和无意的两种,前者如黑客对计算机的入侵、合法用户越权对网站内数据的处理,后者如操作失误或使用不当。 (3)数据安全性:数据的安全性就是保证数据库不被故意破坏和非法存取:数据的完整性是防止数据库中存在不符合语义的数据,以及防止由于错误信息的输入、输出而造成无效操作和错误结果:并发控制即数据库是一个共享资源,在多个用户程序并行地存取数据库时,就可能会产生多个用户程序通过网站并发地存取同一数据的情况,若不进行并发控制就会使取出和存入的数据不正确,破坏数据库的一致性。 (4)恶意代码防范:通过代码层屏蔽常见恶意攻击行为,防止非法数据提交;如:SQL注入; (5)双因子授权认证:应对同一用户采用两种或两种以上组合的鉴别技术实现用户身份鉴别。 (6)密码复杂度:强制用户首次登录时修改初始口令;口令长度至少为8位,并由数字、大小字母与特殊字符组成。 (7)会话过期与超时:浏览器Cookie过期、无动作过期、强制过期、保持会话等进行限制; (8)安全审计功能:a)审计覆盖到每个用户,对重要的用户行为和重要安全事件进行审计,如:登录、退出、添加、删除、修改或覆盖等;b)审计记录应包括事件的日期和时间、用户、事件类型、事件是否成功及其他与审计相关的信息;

(完整版)web服务器安全标准

Web服务器安全标准 前言和文档控制 此文档是西安石油大学制定发布的有关信息安全政策规定、处理流程、行业标准和指导意见的系列文档之一。该文档应保证至少一年审核一次,以保证其有效性。 在没有得到文档发布者的明确授权下,此文档的全部或部分内容,均不得重制或发布。

目录 1目的 (3) 2范围 (3) 3责任 (3) 4Web服务器安全要求 (3) 4.1总则 (3) 4.2网络安全 (3) 4.3流量过滤 (3) 4.4合规性 (4) 4.5数据保护 (4) 4.6输入和输出管理 (4) 4.7安全代码/应用/插件 (4)

1目的 发布本文档所列标准的目的是为了保护学校网站和相关信息资产。本标准的目标是为了确保: ●按照现有最佳的实践经验,在全校统一部署安全控制措施,以消除或者最低限 度的减少系统漏洞和其他安全隐患。 ●学校能在信息安全的完善方面更方便的有据监管、理解风险和评估改进。 ●所有的院系部门和网站开发人员都能了解相应的安全需求 2范围 所列标准适用于学校所有的web网站服务器,包括:学校内部或第三方建设、采购、部署、修改和维护的。具体为: ●所有仅限内部和面向公共的web服务器 ●所有由外部供应商托管的面向公共的web服务器 ●所有通过学校或者代表学校的web服务器建设、采购、部署、修改和维护的 3责任 以下学校实体具体的信息安全责任 ●学校信息化委员会 ●信息安全部门领导 ●信息安全小组应支撑学校满足信息安全功能和防护的各项要求。 ●学院和部门领导对所在部门的信息安全负有义务和责任。 ●Web服务器用户对其处理的信息负有安全责任。 4Web服务器安全要求 4.1总则 4.1.1基于风险分析的深度信息安全防范手段应被采用,包括: 4.1.1.1安全控件在Web服务器的每一层次上都应部署,以避免过度依赖单一 安全防护手段。 4.1.1.2在所有Web服务器上应部署最基本的安全控制措施,以解决常见风险。 4.1.1.3安全控制措施应该是务实的、易于部署、有效和可以衡量的。 4.1.2在虚拟化环境中,所有能考虑到的安全因素都应当适用于主机系统、虚拟机 管理层和虚拟化管理工具。 4.1.3渗透性测试每年至少执行一次,并且在重要系统架构部署、应用升级或修改 后,都应测试。 4.1.4每季度应执行一次漏洞扫描。 4.2网络安全 4.2.1安全控制措施应涵盖每一个活跃版本的网络协议,包括IPv4和IPv6。 4.2.2Web服务器都应分配相应的静态IP地址,除了需要部署动态域名系统技术以 实现负载均衡的服务器。 4.2.3只使用唯一可信的授权DNS来源,避免受到DNS劫持和攻击。 4.2.4所有的非console口管理员级别的访问应使用高强度加密手段进行加密。 4.3流量过滤 4.3.1只有从Internet到特定的IP地址和授权的公共可用服务、协议和端口的入 站流量是允许的。 4.3.2从Web服务器的非授权出站流量是禁止的。

华为Web应用安全开发规范

DKBA 华为技术有限公司内部技术规范 DKBA 1606-XXXX.X Web应用安全开发规范V1.5 2013年XX月XX日发布2013年XX月XX日实施华为技术有限公司 Huawei Technologies Co., Ltd. 版权所有侵权必究 All rights reserved 修订声明Revision declaration 本规范拟制与解释部门: 网络安全能力中心&电信软件与核心网网络安全工程部 本规范的相关系列规范或文件: 《C&C++语言安全编程规范》《Java语言安全编程规范》相关国际规范或文件一致性: 无 替代或作废的其它规范或文件: 无 相关规范或文件的相互关系:

《产品网络安全红线》和《电信软件与核心网业务部安全能力基线》中的Web安全要求引用了本规范的内容,如果存在冲突,以本规范为准。 规范号主要起草部门专家主要评审部门专家修订情况 DKBA 1606-2007.4 安全解决方案:赵武42873,杨光磊57125,万振华55108 软件公司设计管理部:刘茂征11000,刘高峰63564,何伟祥33428 安全解决方案:刘海军12014,吴宇翔18167,吴海翔57182 接入网:彭东红27279 无线:胡涛46634 核心网:吴桂彬41508,甘嘉栋33229,马进32897,谢秀洪33194,张毅27651,张永锋40582 业软:包宜强56737,丁小龙63583,董鹏越60793,傅鉴杏36918,傅用成30333,龚连阳18753,胡海,胡海华52463,李诚37517,李大锋54630,李战杰21615,刘创文65632,刘飞46266,刘剑51690,栾阳62227,罗仁钧65560,罗湘武06277,马亮,孟咏喜22499,潘海涛27360,孙林46580,王福40317,王锦亮36430,王美玲,王谟磊65558,王玉龙24387,杨娟,张锋43381,张健,张轶57143,邹韬51591 V1.0 何伟祥33428 刘高峰63564,龚连阳00129383,许汝波62966,吴宇翔00120395,王欢00104062,吕晓雨56987 V1.2 增加了Web Service、Ajax和上传和下载相关的安全规范。 何伟祥V1.3 增加了防止会话固定和防止跨站请求伪造的安全规范。 何伟祥V1.4 增加了"规则 3.4.1"的实施指导;删除了"建议 3.4.1";修改了"6 配套CBB介绍"的内容和获取方式。增加了"3.9 DWR" 何伟祥00162822 吴淑荣00197720 魏建雄00222906 谢和坤00197709 李田00042091 孙波00175839 朱双红00051429 王伟00207440 陈伟00141500 V1.5 增加"规则3.3.9、规则 3.6.5、规则 4.7.1、建议 4.7.2、4.8 PHP" 增加"3.8 RESTful Web Service" 修改"规则3.2.2.8、规则 3.2.2.3、规则 3.4.1、规则 4.6.1" 删除"3.2.1口令策略"和"规则3.1.3、规则 3.2.3.8、规则 4.7.1" 附件文档作为对象直接插入主文档 目录Table of Contents 1 概述7 1.1 背景简介7 1.2 技术框架7 1.3 使用对象8

Web应用安全测试规范

Web应用安全测试规范 Web应用安全测试规范V 1、2全文结束》》年7月5日发布全文结束》》年7月5日实施版权所有侵权必究 All rights reserved 修订声明Revision declaration 本规范拟制与解释部门: 安全解决方案部电信网络与业务安全实验室、软件公司安全TMG、软件公司测试业务管理部本规范的相关系列规范或文件: Web应用安全开发规范相关国际规范或文件一致性: OWASP Testing Guide v3 信息安全技术信息安全风险评估指南Information technology Security techniques Management of information and communications technology securityISO13335 替代或作废的其它规范或文件:无相关规范或文件的相互关系: 本规范以Web应用安全开发规范为基础、结合Web应用的特点而制定。 版本号主要起草部门专家主要评审部门专家修订情况 V 1、1 V 1、2 增加 Web Service、上传、下载、控制台等方面的测试规范,更正V 1、1 一些描述不准确的测试项 目录Table of Contents1 概述、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、7 1、 1 背景简介、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、7 1、 2 适用读者、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、

系统安全配置技术规范-Websphere

系统安全配置技术规范—Websphere

文档说明(一)变更信息 (二)文档审核人

目录 1.适用范围4 2.帐号管理与授权4 2.1............................................................................. 【基本】控制台帐号安全 4 2.2............................................................................. 【基本】帐号的口令安全 4 2.3............................................................. 【基本】为应用用户定义合适的角色 5 2.4................................................................................... 【基本】控制台安全 5 2.5............................................................... 【基本】全局安全性与J AVA2安全 6 3.日志配置要求6 3.1.......................................................................... 【基本】开启应用日志记录 6 4.服务配置要求7 4.1.......................................................................... 【基本】禁止列表显示文件 7 4.2................................................................... 【基本】禁止浏览列表显示目录 7 4.3................................................................................ 【基本】删除示例程序 8 4.4............................................................................. 【基本】控制台超时设置 8

WEB安全编程技术规范

1.范围 本规范从WEB应用开发安全管理要求出发,给出了WEB编码安全的具体要求。 本规范明确定义了JAVA应用开发中和WEB编码安全相关的技术细节。 与JAVA编码安全相关的内容包括:跨站脚本攻击及解决方法、SQL注入及解决方法、恶意文件执行及解决方法、不安全的直接对象引用及解决方法、跨站请求伪造及解决方法、信息泄露和错误处理不当及解决方法、残缺的认证和会话管理及解决方法、不安全的加密存储及解决方法、不安全的通信及解决方法、限制URL访问实效解决方法等。 2.1.规范概述 Web应用程序为架构设计人员、开发人员、测试人员和运维运营人员提出一系列复杂的安全问题,最安全、最有能力抵御攻击的Web应用程序是那些应用安全思想构建的应用程序。 在设计初始阶段,应该使用可靠的体系结构和设计方法,同时要结合考虑程序部署以及企业的安全策略。如果不能做到这一点,将导致在现有基础结构上部署应用程序时,要不可避免地危及安全性。 本规范提供一系列安全的体系结构和设计指南,并按照常见的应用程序漏洞类别进行组织。这些指南是Web应用程序安全的重要方面,并且是经常发生错误的领域。 2.实现目标 使用本规范可以实现: 1.确定安全Web应用程序的重要体系结构和设计问题。 2.设计时考虑重要部署问题。 3.制定能增强Web应用程序输入验证的策略。 4.设计安全的身份验证和会话管理机制。 5.选择适当的授权模型。 6.实现有效的帐户管理方法,并保护用户会话。 7.对隐私认可并防止篡改,和对身份验证信息进行加密。

8.防止参数操作。 9.安全漏洞checklist。 10.设计审核和记录策略。 3.安全编码原则 1.程序只实现你指定的功能。 2.永不要信任用户输入,对用户输入数据做有效性检查。 3.必须考虑意外情况并进行处理。 4.不要试图在发现错误之后继续执行。 5.尽可能使用安全函数进行编程。 6.小心、认真、细致地编程。 4.安全背景知识 本规范主要提供设计应用程序时应该遵循的一些指南和原则。为充分理解本规范内容,请: 了解应用程序将会受到的威胁,以确保通过程序设计解决这些问题。了解需要考虑的威胁,在程序设计阶段应该考虑到这些威胁。 在应用程序易受攻击的重要环节应用系统的方法。将重点放在程序部署、输入验证、身份验证和授权、加密及数据敏感度、配臵、会话、异常管理以及适当的审核和记录策略上,以确保应用程序具有健壮性。 5.JAVA安全编程——OWASP TOP10ANDESAPI 5.1OWASP TOP10 与ESAPI OWASP(开放Web应用安全项目-OpenWebApplicationSecurityProject)是一个开放社群、非营利性组织,目前全球有82个分会近万名会员,其主要目是研议协助解决Web 软体安全之准则、工具与技术,长期致力于协助政府或企业并改善网页应用程式与网页服务的安全性。

WEB类应用系统安全防护技术要求

WEB类应用系统安全防护技术要求 Technical Specification of Security for Web Applications 版本号: 1.0.0 中国移动通信有限网络部

目录 前言 (1) 1适用范围 (2) 2引用标准与依据 (2) 3相关术语与缩略语 (2) 3.1术语 (2) 3.1.1注入漏洞 (2) 3.1.2SQL注入攻击 (3) 3.1.3跨站漏洞 (3) 3.1.4跨站攻击 (3) 3.1.5非法上传 (3) 3.1.6缓冲区溢出 (3) 3.1.7非法输入 (3) 3.1.8网站挂马 (3) 3.1.9拒绝服务攻击 (3) 3.1.10跨站请求伪造 (4) 3.1.11目录遍历攻击 (4) 3.2缩略语 (4) 4综述 (4) 5WEB类应用系统基本架构 (5) 5.1业务逻辑结构 (5) 5.2网络结构 (5) 6WEB类应用风险分析 (6) 6.1主要风险分析 (6) 6.2脆弱性分析 (7) 6.2.1物理 (7) 6.2.2网络 (7) 6.2.3设备 (7) 6.2.4应用 (8) 6.2.5内容 (10) 6.2.6管理 (10) 6.3威胁分析 (10) 6.3.1物理 (10) 6.3.2网络 (10) 6.3.3设备 (11) 6.3.4应用 (11) 6.3.5内容 (13) 7WEB类应用系统的安全防护需求 (13) 7.1物理安全需求 (13) 7.2分区防护需求 (13) 7.2.1安全域划分要求 (13) 7.2.2边界整合及域间互联安全要求 (14) 7.3WEB类应用系统自身安全要求 (16) 7.3.1操作系统安全要求 (16) 7.3.2中间件安全要求 (16) 7.3.3数据库安全要求 (17) 7.3.4应用软件自身安全要求 (17) 7.4专用安全设备部署需求 (20)

WEB应用系统安全规范文档

目录 WEB应用系统安全规范................................................. 错误!未定义书签。1概述............................................................ 错误!未定义书签。 目的 .................................................................... 错误!未定义书签。 适用范围 ................................................................ 错误!未定义书签。2范围............................................................ 错误!未定义书签。3名词解释........................................................ 错误!未定义书签。4WEB开发安全规范................................................. 错误!未定义书签。 W EB应用程序体系结构和安全................................................ 错误!未定义书签。 W EB安全编码规范.......................................................... 错误!未定义书签。 区分公共区域和受限区域......................................... 错误!未定义书签。 对身份验证 cookie 的内容进行加密............................... 错误!未定义书签。 限制会话寿命 .................................................. 错误!未定义书签。 使用 SSL 保护会话身份验证 Cookie ............................... 错误!未定义书签。 确保用户没有绕过检查........................................... 错误!未定义书签。 验证从客户端发送的所有数据..................................... 错误!未定义书签。 不要向客户端泄漏信息........................................... 错误!未定义书签。 记录详细的错误信息 ............................................ 错误!未定义书签。 捕捉异常 ...................................................... 错误!未定义书签。 不要信任 HTTP 头信息........................................ 错误!未定义书签。 不要使用 HTTP-GET 协议传递敏感数据 .......................... 错误!未定义书签。 不要在永久性 cookie 中存储敏感数据 .......................... 错误!未定义书签。 对数据进行加密或确保通信通道的安全 .......................... 错误!未定义书签。 SQL 语句的参数应以变量形式传入 .............................. 错误!未定义书签。 页面中的非源代码内容应经过 URI 编码 ......................... 错误!未定义书签。

WEB应用系统安全规范文档

WEB 应用系统安全规范 目录 WEB应用系统安全规范 ............................. 错误!未定义书签。 1 概述................................... 错误! 未定义书签。 目的............................................................................. 错误! 未定义书 签。 适用范围 ......................................................................... 错误! 未定义书 签。 2 范围................................... 错误! 未定义书签。 3 名词解释.................................. 错误! 未定义书签。 4 WEB开发安全规范.............................. 错误!未定义书签。 VEB应用程序体系结构和安全............................ 错误!未定义书签。 VE B安全编码规范 ............................... 错误!未定义书签。 区分公共区域和受限区域. ........................................ 错误!未定义书签。 对身份验证cookie 的内容进行加密. .................................... 错误!未定义书签。 限制会话寿命............................ 错误!未定义书签。 使用SSL 保护会话身份验证Cookie . ................................... 错误!未定义书签。 确保用户没有绕过检查.......................... 错误!未定义书签。 验证从客户端发送的所有数据. ........................................ 错误!未定义书签。 不要向客户端泄漏信息.......................... 错误! 未定义书签。 记录详细的错误信息......................... 错误! 未定义书签。 捕捉异常.............................. 错误!未定义书签。 不要信任HTTP 头信息...................... 错误! 未定义书签。 不要使用HTTP-GET 协议传递敏感数据 ............... 错误! 未定义书签。 不要在永久性cookie 中存储敏感数据.................. 错误! 未定义书签。 对数据进行加密或确保通信通道的安全................. 错误!未定义书签。 SQL 语句的参数应以变量形式传入 .................. 错误!未定义书签。 页面中的非源代码内容应经过URI 编码................ 错误! 未定义书签。 页面中拼装的脚本应校验元素来源的合法性............... 错误! 未定义书签。 页面请求处理应校验参数的最大长度................. 错误! 未定义书签。 登录失败信息错误提示应一致.................... 错误! 未定义书签。 避免页面上传任意扩展名的文件.................... 错误! 未定义书签。 避免接受页面中的主机磁盘路径信息................. 错误! 未定义书签。 第三方产品的合法性......................... 错误! 未定义书签。 5 系统部署安全规范.............................. 错误! 未定义书签。 部署架构和安全 .................................................................. 错误!未定义书签。 网络基础结构组件........................... 错误!未定义书签。

Java Web安全开发规范

Java Web安全开发规范

1.目的 保障WEB应用平台的安全性,保证WEB应用系统的可用性、完整性和保密性从安全角度规范WEB应用系统开发人员,能够让WEB应用开发者树立很强的安全意识,在开发过程中编写安全代码,进行安全编程。 2.范围 本规范从应用安全开发角度出发,给出WEB应用系统安全开发的规范。供软通动力内部使用,适用各个WEB应用系统项目开发的工作。 本规范定义了WEB应用系统安全开发和WEB编码安全相关的技术要求。 3.规范概述 WEB应用系统为架构设计人员、开发人员提出了一系列复杂的安全问题。最安全、最有能力抵御攻击的Web应用程序是那些应用安全思想构建的应用程序。 在设计初始阶段,应该使用可靠的安全体系结构和设计方法,同时要结合考虑应用程序的部署以及企业的安全策略。如果不能做到这一点,将导致在现有基础结构上部署应用程序时,要不可避免地危及网站系统的安全性。 本规范提供初步的安全体系结构和设计指南,并按照常见的应用程序漏洞类别进行组织。这些指南是WEB应用程序安全的重要方面,并且是经常发生错误的领域。 4.安全编码原则 ◆程序只实现你指定的功能 ◆永不要信任用户输入,对用户输入数据有效性检查 ◆必须考虑意外情况并进行处理 ◆不要试图在发现错误之后继续执行 ◆尽可能使用安全函数进行编程 ◆小心、认真、细致地编程 5.软件编码安全 5.1.输入校验 WEB应用程序从各个方面获取输入,例如所有用户发送的,或者Web应用程序与用户

交互往返的数据(用户提交的数据,cookie信息,查询字符串参数),以及后台数据(数据库、配置文件、其他数据来源)。所有输入的数据都会在某种情况下影响请求的处理。 正确的输入验证是防御目前应用程序攻击的最有效方法之一。正确的输入验证是防止XSS、SQL注入、缓冲区溢出和其他输入攻击的有效对策。 以下做法可以增强Web应用程序的输入验证: 假定所有输入都是恶意的 开始输入校验时,首先假定所有输入都是恶意的,除非有证据表明它们并无恶意,无论输入是来自服务、共享文件、用户还是数据库,只有其来源不在 可信任的范围之内,就应对输入进行验证。 集中方法 将输入验证策略作为应用程序的核心元素。考虑集中式验证方法,例如通过使用共享库中的公共验证和筛选代码。这确保验证规则应用的一致性。此外 还能减少开发工作量,并且有助于以后的维护工作。 不要依赖客户端验证 应使用服务器端代码执行其自身的验证,如果攻击者绕过客户端或者禁用客户端JavaScript脚本,后果如何?使用客户端验证可以减少客户端到服务器 端的往返次数,但是不要依赖这种方法进行安全验证。 注意标准化问题 数据的标准形式是最标准、最简单的形式。标准化是指将数据转化为标准形式的过程。文件路径和URL尤其倾向于标准化问题。 例如/www/public/testfile.jsp /www/public/../public/testfile.jsp /www/public///testfile.jsp %2fwww%2fpublic%2f%2f%2ftestfile.jsp 都表示同一个文件。 通常,应设法避免让应用程序接受用户输入的文件名,以防止标准化问题。 可以考虑其他方式,例如由应用程序为用户确定文件名。如果确实需要用户输 入文件名,在作出安全决策(如授予或拒绝特定文件的访问权限)之前应确保 这些文件名具有严格定义的形式。 限制输入 定义应用程序字段可以接受的数据输入,并强制应用该定义,拒绝一切有害数据。 验证数据的类型、长度、格式和范围 在适当的地方对输入数据使用强类型检查,可以使用参数化的存储过程来访问数据。 应该检查字符串字段的长度,在许多情况下还应检查字符串的格式是否正确,例如邮政编码、手机号码、身份证号码等都具有明确定义的格式,可以使 用常规表达式进行验证。长度检查会加大攻击者实施其所喜欢的攻击方式的难 度。 拒绝已知的有害输入 例如查询条件中禁止输入or 1=1等。 净化输入 净化包括从删除用户输入字符串后面的空格到去除值等一切行为。常见的净化输入示例是使用URL编码或者HTML编码来包装数据,并将其作为文本而

WEB应用系统安全规范

W E B应用系统安全规范 Document number:BGCG-0857-BTDO-0089-2022

WEB应用系统安全规范 目录

1概述 1.1目的 为规范我司Java Web应用编码和部署的安全控制和管理,特制定本规范,并作为安全检查及考核的参考依据。

1.2适用范围 本规范适用于我司所有在线Java业务系统、测试系统的WEB应用。 本规范可作为其他非WEB应用的编码和部署安全办法参考。 2范围 本规范中列出的是常见安全措施和高风险的漏洞,在系统开发与系统部署的过程中,对本规范未能尽述的必要安全措施,仍应予以采用。 本规范每年复审一次,其它时候也可以根据需要进行修订并发布。本规范的解释权和修改权归属信息技术部。 3名词解释 验证:通讯实体(例如,客户端和服务器)彼此验证,以经过访问授权的特定标识为依据。 资源的访问控制:资源的交互仅限于某些用户或程序的集合,其目的是对完整性,保密性或可用性实施强制约束。 数据完整性:检验信息是否被第三方(非信息源的其它实体)修改。例如,处于开放网络环境中的数据接收方必须能够检测并丢弃那些在传递过程中被修改过的消息。 机密性或数据隐私:确保信息仅对经过访问授权的用户可用。 不可否认:对用户进行检验,让他无法否认自己进行过的活动。

审核:捕获一个安全相关事件的防篡改记录,目的是评估安全策略和机制的有效性。 4Web开发安全规范 4.1Web应用程序体系结构和安全 HTTP 是无国界的,这意味着跟踪每位用户的会话状态将成为应用程序的责任。应用程序必须能够通过某种形式的身份验证来识别用户。由于所有后续授权决策都要基于用户的标识,因此,身份验证过程必须是安全的,同样必须很好地保护用于跟踪已验证用户的会话处理机制。设计安全的身份验证和会话管理机制仅仅是Web 应用程序设计人员和开发人员所面临的众多问题中的两个方面。由于输入和输出数据要在公共网络上进行传输,因此还会存在其他挑战。防止参数操作和敏感数据泄漏也是另外一些重要问题。

系统安全配置技术规范-Websphere

系统安全配置技术规范—Websphere 版本V0.9 日期2013-06-03 文档编号 文档发布

文档说明 (一)变更信息 版本号变更日期变更者变更理由/变更内容备注 (二)文档审核人 姓名职位签名日期

目录 1.适用范围 (4) 2.帐号管理与授权 (4) 2.1【基本】控制台帐号安全 (4) 2.2【基本】帐号的口令安全 (4) 2.3【基本】为应用用户定义合适的角色 (5) 2.4【基本】控制台安全 (5) 2.5【基本】全局安全性与J AVA 2 安全 (6) 3.日志配置要求 (6) 3.1【基本】开启应用日志记录 (6) 4.服务配置要求 (7) 4.1【基本】禁止列表显示文件 (7) 4.2【基本】禁止浏览列表显示目录 (7) 4.3【基本】删除示例程序 (8) 4.4【基本】控制台超时设置 (8) 4.5【基本】更新 W EB S PHERE补丁 (8) 4.6【基本】备份容错 (9) 4.7设置错误页面 (9) 4.8配置 SSL 访问 (9) 4.9控制目录权限 (11) 5.操作系统配置要求 (11)

1.适用范围 如无特殊说明,本规范所有配置项适用于IBM WebSphere Application Server (WAS) 6.x,7.x ,8.x 版本。其中标示为“基本”字样的配置项,均为本公司对此类系统的基本安全配置 要求;未标示“基本”字样的配置项,请各系统管理员视实际需求酌情遵从。 2.帐号管理与授权 2.1 【基本】控制台帐号安全 配置 WebSphere 控制台帐号安全,要求按权利需要分配不同用户角色,同时 配置项描述 保证权限最小化 以管理员身份打开管理控制台,执行: 检查方法 1.点击“系统管理”-->”控制台设置”-->“控制台用户” 2.点击要查看的用户名 3.查看用户所属组 要求不得出现共用特权管理帐号,管理帐号必须按角色分配用户角色为 操作步骤monitor(监控员)、Configurator( 配置员 )、Operator(操作员) Administrator( 管理员 )之 回退操作回退到原有的配置设置 操作风险低风险 2.2 【基本】帐号的口令安全 配置项描述配置 WebSphere 口令安全,要求用户口令至少 6 位,包括大小写,数字和符号中的至少两种 检查方法 询问管理员是否存在如下类似的简单用户密码配置,比如: Test、 netscreen、 admin、 root1234 操作步骤检查用户口令的设置情况,检查是否存在简单密码。要求密码长度最少为6位,包含大小写字母、数字和特殊符号,密码变更周期。 回退操作回退到原有的配置设置

WEB应用系统安全规范

WEB应用系统安全规范 目录 WEB应用系统安全规范 (1) 1概述 (2) 1.1目的 (2) 1.2适用范围 (3) 2范围 (3) 3名词解释 (3) 4WEB开发安全规范 (4) 4.1W EB应用程序体系结构和安全 (4) 4.2W EB安全编码规范 (6) 4.2.1区分公共区域和受限区域 (6) 4.2.2对身份验证cookie 的内容进行加密 (6) 4.2.3限制会话寿命 (6) 4.2.4使用SSL 保护会话身份验证Cookie (6) 4.2.5确保用户没有绕过检查 (6) 4.2.6验证从客户端发送的所有数据 (7) 4.2.7不要向客户端泄漏信息 (7) 4.2.8记录详细的错误信息 (7) 4.2.9捕捉异常 (7) 4.2.10不要信任HTTP 头信息 (7) 4.2.11不要使用HTTP-GET 协议传递敏感数据 (7) 4.2.12不要在永久性cookie 中存储敏感数据 (7) 4.2.13对数据进行加密或确保通信通道的安全 (8) 4.2.14SQL 语句的参数应以变量形式传入 (8) 4.2.15页面中的非源代码内容应经过URI 编码 (8) 4.2.16页面中拼装的脚本应校验元素来源的合法性 (8) 4.2.17页面请求处理应校验参数的最大长度 (8) 4.2.18登录失败信息错误提示应一致 (9) 4.2.19避免页面上传任意扩展名的文件 (9) 4.2.20避免接受页面中的主机磁盘路径信息 (9) 4.2.21第三方产品的合法性 (9) 5系统部署安全规范 (9) 5.1部署架构和安全 (9) 5.1.1网络基础结构组件 (10)

相关文档
最新文档