WEB网站系统安全解决方案.doc

WEB网站系统安全解决方案382020年4月19日资料内容仅供参考，如有不当或者侵权，请联系本人改正或者删除。 网站系统安全的需求分析本文从数据安全和业务逻辑安全两个角度对应用系统的安全进行需求分析, 主要包括保密性需求、 完整性需求、 可用性需求三部分; 随后对业务逻辑安全需求进行了分析, 包括身份认证、 访问控制、 交易重复提交控制、 异步交易处理、 交易数据不可否认性、 监控与审计等几个方面; 最后还分析了系统中一些其它的安全需求。2.1 数据安全需求2.1.1数据保密性需求数据保密性要求数据只能由授权实体存取和识别, 防止非授权泄露。从当前国内应用的安全案例统计数据来看, 数据保密性是最易受到攻击的一个方面, 一般表现为客户端发生的数据泄密, 包括用户的基本信息、 账户信息、 登录信息等的泄露。在应用系统中, 数据保密性需求一般主要体现在以下几个方面: A客户端与系统交互时输入的各类密码: 包括系统登录密码、 转账密码、 凭证查询密码、 凭证交易密码等必须加密传输及存放, 这些密码在应用系统中只能以密文的方式存在, 其明文形式能且只能由其合法主体能够识别。以网银系统为例, 在网银系统中, 一般存有四种密码: 系统登录密码、 网银转账密码、 柜面交易密码及一次性密码。系统登录密码用来认证当前登录者为指定登录名的合法用户, 网银用户的登录密码和网银转账密码由用户在柜面开户时指定, 用户在首次登录网银系统时, 系统必须强制用户修改初始密码, 一般要求长度不得少于六位数, 且不能是类似于111111、 1234567、 9876543等的简单数字序列, 系统将进行检查。网银转账密码是指网银系统为巩固用户资金安全, 在涉及资金变动的交易中对用户身份进行了再认证, 要求用户输入预设的密码, 网银交易密码仅针对个人用户使用, 企业用户没有网银交易密码。建立多重密码机制, 将登录密码与网银转账密码分开管理, 有利于加强密码的安全性。由于用户在使用网银时每次都必须先提供登录密码, 故登录密码暴露的机会较多, 安全性相对较弱; 但登录网银的用户并不是每次都会操作账户资金的, 因此专门设定网银转账密码可加强账户的安全性。网银转账密码在网银开户时设定, 网银用户在系统中作转账支付、 理财、 代缴费等资金变动类交易时使用。柜面交易密码是指用户在银行柜面办理储蓄时, 针对储蓄凭证( 如卡折、 存单等) 而设的密码。柜面交易密码常见于POS系统支付时、 ATM取款时、 凭证柜面取款时, 柜面交易密码一个明显的特征是它当前只能是六位的数字, 这是由于当前柜面密码输入设备的限制而造成的。柜面交易密码与上述的网银转账密码的区别在于: 网银转账密码和系统登录密码都产生于网银系统, 储存在网银系统中, 仅限网银系统中认证使用; 而柜面交易密码产生于银行柜台, 能够在外围渠道如ATM、 电话银行、 自助终端上修改, 它保存在银行核心系统中, 供外围各个渠道系统共同使用。另外网银转账密码能够有非数字字符组成, 而柜面交易密码只能是六位的数字。网银中使用到柜面交易密码的交易包括: 网银开户、 加挂账户。一次性密码由用户的智能卡、 令牌卡产生, 或由动态密码系统产生经过短信方式发送到用户注册的手机上。一次性密码的作用与网银转账密码相同, 适用的场合也相同。一次性密码在农商行网银系统中是可选的安全服务, 用户需到柜面办理开通手续才能使用, 没有开通一次性密码服务的用户必须设定网银交易密码, 开通一次性密码服务的用户则无需设定网银交易密码, 要求网银系统自动判断并提示用户在某个交易中是要输入网银交易密码还是提示一次性密码。B应用系统与其它系统进行数据交换时在特定安全需求下需进行端对端的加解密处理。这里的数据加密主要是为了防止交易数据被银行内部人士截取利用, 具体通讯加密方案参照应用系统的特定需求。 2.1.2数据完整性需求数据完整性要求防止非授权实体对数据进行非法修改。用户在跟应用系统进行交互时, 其输入设备如键盘、 鼠标等有可能被木马程序侦听, 输入的数据遭到截取修改后被提交到应用系统中, 如原本用户准备向A账户转一笔资金在交易数据遭到修改后就被转到B账户中了。同样的威胁还存在于交易数据的传输过程中, 如在用户向应用系统提交的网络传输过程中或应用系统跟第三方等其它系统的通讯过程中, 另外存储在应用系统数据库中的数据也有可能遭到非法修改, 如SQL注入攻击等。2.1.3数据可用性需求数据可用性要求数据对于授权实体是有效、 可用的, 保证授权实体对数据的合法存取权利。对数据可用性最典型的攻击就是拒绝式攻击( DoS) 和分布式拒绝攻击, 两者都是经过大量并发的恶意请求来占用系统资源, 致使合法用户无法正常访问目标系统, 如SYN Flood攻击等, 将会直接导致其它用户无法登录系统。另外, 应用登录机器人对用户的密码进行穷举攻击也会严重影响系统的可用性。2.2 业务逻辑安全需求业务逻辑安全主要是为了保护应用系统的业务逻辑按照特定的规则和流程被存取及处理。2.2.1身份认证需求身份认证就是确定某个个体身份的过程。系统经过身份认证过程以识别个体的用户身份, 确保个体为所宣称的身份。应用系统中身份认证可分为单向身份认证和双向身份认证, 单向身份认证是指应用系统对用户进行认证, 而双向身份认证则指应用系统和用户进行互相认证, 双向身份认证可有效防止”网络钓鱼”等假网站对真正系统的冒充。应用服务器采用数字证书, 向客户端提供身份认证, 数字证书要求由权威、 独立、 公正的第三方机构颁发; 系统为客户端提供两种可选身份认证方案, 服务器端对客户端进行多重身份认证, 要求充分考虑到客户端安全问题。将客户端用户身份认证与账户身份认证分开进行, 在用户登录系统时, 采用单点用户身份认证, 在用户提交更新类、 管理类交易请求时, 再次对用户的操作进行认证或对用户身份进行二次认证, 以确保用户信息安全。2.2.2访问控制需求访问控制规定了主体对客体访问的限制, 并在身份识别的基础上, 根据身份对提出资源访问的请求加以控制。访问控制是应用系统中的核心安全策略, 它的主要任务是保证应用系统资源不被非法访问。主体、 客体和主体对客体操作的权限构成访问控制机制的三要素。访问控制策略能够划分为自主访问控制、 强制访问控制和基于角色的访问控制三种。2.2.3 交易重复提交控制需求交易重复提交就是同一个交易被多次提交给应用系统。查询类的交易被重复提交将会无故占用更多的系统资源, 而管理类或金融类的交易被重复提交后, 后果则会严重的多, 譬如一笔转账交易被提交两次则将导致用户的账户被转出两笔相同额的资金, 显然用户只想转出一笔。交易被重复提交可能是无意的, 也有可能是故意的: A用户的误操作。在B/S结构中, 从客户端来看, 服务器端对客户端的响应总有一定的延迟, 这在某些交易处理上体现的更为明显, 特别是那些涉及多个系统交互、 远程访问、 数据库全表扫描、 页面数据签名等交易, 这种延迟一般都会在5至7秒以上。这时用户有可能在页面已提交的情况下, 再次点击了提交按钮, 这时将会造成交易被重复提交。B被提交的交易数据有可能被拿来作重放攻击。应用系统必须对管理类和金融类交易提交的次数进行控制, 这种控制即要有效的杜绝用户的误操作, 还不能影响用户正常情况下对某个交易的多次提交。比如说: 当某个用户在10秒内提交了两笔相同的转账业务, 则系统必须对此进行控制; 另一方面, 当用户在第一笔转账业务完成后, 再作另一笔数据相同的转账时, 则系统不能对此进行误控制。这里判断的依据就是交易重复提交的控制因子a, 当交易提交的间隔小于a时, 系统认为这是重复提交, 提交间隔大于a的则不作处理, 控制因子的大小由应用系统业务人员决定, 系统应可对其进行配置化管理。2.2.4异步交易处理需求所谓异步交易就是指那些录入与提交不是同时完成的交易, 这里的同时是指客户端在录入交易数据与提交交易的过程中, 应用系统服务器端并没有对录入的数据进行持久化保存, 而异步交易在系统处理过程中, 录入与提交时间上发生在两个相分离的阶段, 在两阶段之间, 应用系统对录入的数据进行了持久化保存。由于异步交易是被系统分两阶段受理的, 这就涉及到以下三个方面的问题: A 录入与提交的关系管理。B 如何保证提交的数据就是用户当初录入的数据。C 如何记录交易在两阶段的日志状态。录入与提交的关系定义不当将会导致交易录入与提交被同时完成而违反了业务处理流程, 录入的数据被系统保存后有可能遭到非法篡改, 非异步交易执行后的日志状态不会被更新而异步交易在提交后日志状态将会被更新。应用系统中需要定义成异步的交易一般有以下两类: 需要授权的交易。出于业务管理和业务安全方面的考虑, 大部分管理类和金融类的交易都需要经过一定的授权流程后方能被提交。 部分定时交易, 如预约转账等。预约一笔在周三转账的预约转账有可能是周一被录入的, 用户在录入后, 预约转账的数据将被网银系统保存直到周三这笔转账才会真正发生。应用系统必须定义简单、 清晰、 易维护的录入与提交关系模型, 保证被保存的录入数据不会被非法篡改, 同时要求异步交易的日志状态是明确的, 不应出现录入与提交相矛盾的日志状态。2.2.5交易数据不可否认性需求交易数据不可否认性是指应用系统的客户不能否认其所签名的数据, 客户对交易数据的签名是经过应用系统使用客户的数字证书来完成的。数字证书的应用为交易数据不可否认性提供了技术支持, 而电子签名法的颁布为交易数据不可否认性提供了法律基础。在应用系统中一般要求对所有管理类与金融类的交易进行数字签名, 以防客户事后对交易或交易数据的抵赖。应用系统需同时保存客户录入的原始数据和签名后的数据, 保存期限依业务部门的具体要求而定。考虑到系统性能和对用户的响应问题, 应用系统可只签与交易有关的关键数据, 支付类的交易只对付款人账号、 付款金额、 收款人姓名、 收款人账号、 收款人开户行五个字段进行数字签名就能够了。2.2.6监控与审计需求安全级别要求高的应用系统应提供对系统进行实时监控的功能, 监控的内容包括系统当前登录的用户、 用户类型、 用户正在访问的交易、 用户登录的IP等。对金融类、 管理类的交易以及应用系统登录交易需要完整地记录用户的访问过程, 记录的关键元素包括: 用户登录名、 登录IP、 交易日期及时间、 交易名称、 交易相关数据等, 对有授权流程的交易要求完整记录授权的经过, 授权记录与交易记录分开存放。 2.3 其它安全需求2.3.1 登录控制需求登录一般是应用系统的关键交易, 系统经过登录交易对用户身份进行认证。针对不同角色的用户指定不同的登录策略: 最小权限集用户, 可使用用户登录名+静态登录密码+图形识别码方式登录。低安全性。 普通权限集用户, 可使用用户登录名+动态登录密码+数图形识别码方式登录。 高权限集用户, 可使用用户登录名+数字证书+静态密码+数图形识别码方式登录。 所有权限集用户, 可使用用户登录名+数字证书+动态密码+数图形识别码方式登录。应用系统可提供客户端加密控件对用户输入的密码域进行加密处理后再提交。连续登录多次失败的用户, 其IP将被应用系统锁定, 24小时后系统将自动对锁定的IP进行解锁。这里登录失败的次数和IP锁定时长根据业务需求说明应由配置文件进行设定。对于首次登录系统的用户, 系统将强制定位到修改密码的页面, 要求用户修改初始密码重新登录方可使用系统。对于密码类型和长度, 系统将规则检查。对于成功登录的用户, 应用系统自动清除其连续登录失败的次数, 同时初始化用户的相关数据并同时对登录数据进行记录, 以备审计。2.3.2 会话控制需求经过应用服务器自身的会话管理或应用程序的会话管理都能够控制会话的时长设定, 设置过久的会话将给客户端带来安全风险, 而设置过短则影响用户的正常使用。该机制使在应用层无状态的HTTP/HTTPS协议, 能够支持需要状态记录的互联网应用, 实现用户登录后在新的状态下从事交易、 超时断路等功能。2.3.3 被访问对象控制需求应用系统对用户的关键资源或信息, 提供操作权限设置支持, 权限分为: 查询和更新两类。权限为查询的资源或信息只能对其进行查询操作, 不能进行更新。资源权限由开户时指定, 为加强安全性, 权限分配可经过落地处理开通。2.3.4 交易提醒需求交易提醒是指将客户的账号与客户手机号、 电子邮件等关联起来, 当客户信息发生变动时, 向客户的手机发送一条短信或电话通知或发送一封电子邮件, 及时准确的告知客户。另经过通知提醒功能, 系统应定期向用户发送统计、 明细、 确认等信息。第三章 应用系统安全的总体解决方案3.1 安全技术安全技术是安全子系统的理论基础, 安全子系统中主要涉及的安全技术包括: 密码技术、 PKI技术体系、 一次性口令技术等, 另外考虑到当前实际应用中, 大部分WEB应用系统是基于J2EE平台的, J2EE平台本身也对系统安全提供了较多内置的支持, 如JAAS技术等, 因此本章中对于J2EE平台的安全技术特性也有少量的讨论。3.1.1 密码技术密码技术是保护信息系统安全的基础技术之一, 密码技术能够保证数据的保密性和完整性, 同时它还具有身份认证和数字签名的功能。从密码体制方面来说, 密码技术可分为对称密钥密码技术和非对称密钥密码技术两大类。在应用系统中常见的密码技术主要有以下几种: A加密解密技术加密( Encryption) 就是指经过特定的加密算法对数据进行变换, 将明文( Plaintext) 转换成密文( Cryptograph) ; 解密( Decryption) 是加密的逆过程, 解密的过程就是将密文还原为明文。设明文为P, 密文为C, E为加密算法, D为解密算法, 则加密解密的过程能够记为: (3.1)上述的加密与解密过程没有使用到密钥, 一般称之为无密钥密码体制。无密钥密码主要依靠加密算法提供保密性, 在应用系统中这种密码很少用到, 主要使用还是有密钥的密码体制, 在有密钥的密码体制中, 密文的保密性依赖于密钥而不依赖于算法, 算法能够公开。其中, 只有一个密钥K的密码体制称为单钥体制( One-key System) , 又称对称加密体制( Symmetrical Encryption) ; 有加密密钥KE和解密密钥KD两个密钥的密码体制称为双钥体制( Two-key System) , 又称非对称加密体制( Dissymmetrical Encryption) , 有时也叫公开密钥算法( Public Key Algorithm)。应用系统中经常使用最广泛的对称加密算法是DES算法 (Data Encryption Standard), 非对称加密算法是RSA算法( Receive, Shamir, Adelman) 。单钥体制的加密解密过程能够记为: (3.2)上式用图示能够表示为: 明文密文明文加密密钥K解密密钥K图5 单钥体制加密解密过程图双钥体制的加密解密过程能够记为: (3.3)上式用图示能够表示为: 明文密文明文加密密钥KE解密密钥KD图6 双钥体制加密解密过程图还有一种应用系统中经常见到的加密技术是数据摘要, 数据摘要就是应用单向散列函数算法, 将输入的任意长度明文变换成固定长度的密文, 而将此密文再转换成明文在数学上来说是困难的。应用系统中应用最广泛的数据摘要算法主要有MD5和SHA两种, MD5输出压缩值为128bits, SHA输出压缩值为160bits。设Hash表示单向散列函数, 则数据摘要的过程能够记为: (3.4)上式用图示能够表示为: 明文密文明文加密密钥K解密密钥K密文明文Hash图7 数据摘要的过程图B数字签名。数字签名是指经过密码算法对原始数据信息进行加密处理后, 生成一段原始数据信息的信息标识, 这段信息标识称为原始数据信息的数字签名。一般数字签名和原始数据信息是放在一起发送的, 这样便于信息的接受者对其进行验证, 数字签名是对现实中手写签名和印章的模拟, 数字签名只有信息发送方一人能产生, 这种唯一性对应了原始数据信息的来源。数字签名具有验证数据完整性和信息来源不可否认性的功能, 这正是PKI体系提供的核心功能。在应用系统中, 较小的数据能够直接签名, 而较大的数据或文件一般先对其作数据摘要后再对数据摘要作数字签名。下式表示了对一段原始数据信息进行签名的过程: 原始数据信息OriginalMsg先是被单向散列函数Hash作数据摘要生成摘要信息DigestMsg, 然后应用非对称加密算法DissymmetricalEncrypt及其私钥Keyprivate对数据摘要进行签名( 私钥仅有发送方持有, 公钥需散发给接收方) , 最后将签名结果DigitalSignature与原始数据信息一起发送给接受方: (3.4)上式用图示能够表示为: OriginalMsgKeyprivavteDigitalSignatureHashDissymmetricalEncrytDigestOriginalMsg + DigitalSignature图8 数字签名的过程图信息接受方在接受到原始数据信息OriginalMsg与其数字签名DigitalSignature后, 能够对数字签名进行验证。首先分离出两者, 然后对原始数据信息应用同样的单向散列函数Hash对其作数据摘要得到Digest2, 再对接收到的数字签名应用非对称加密算法DissymmetricalEncrypt及其公钥Keypublic对其进行解密, 得到Digest1。比较Digest1与Digest2, 如果两者一样则证明: 1信息OriginalMsg及其数字签名DigitalSignature是真实的, 确实来自于私钥Keyprivate的持有方。2信息OriginalMsg及其数字签名DigitalSignature在发送过程中是完整的, 未曾遭到篡改。3私钥Keyprivate的持有方发送了信息OriginalMsg及其数字签名DigitalSignature这件事是不可否认的。上述数字签名的验证过程能够表示为: (3.5)用图形表示如下: KeypublicOriginalMsgDigitalSignatureHashDissymmetricalEncrytDigest2OriginalMsg + DigitalSignatureDigest2两者相同? 图9 数字签名验证的过程图C报文识别码应用系统跟其它系统通讯时大都是经过发送接收报文方式进行的, 除比较常见的ISO8583, sop报文等, 还有比较多的就是自定义的报文格式, 自定义报文需要解决报文的保密性和完整性问题, 报文的完整性能够经过加密算法生成原始报文的报文标识来识别, 这个加密后的报文标识称为原始报文的识别码, 也叫报文校验码MAC( Message Authentication Code) 。而报文的保密性能够经过对整个报文及其识别码进行加密处理来完成, 实际应用中识别码一般能够经过单向散列函数对原始报文作数据摘要得到, 然后对原始报文和数据摘要作对称加密, 这样既保证了报文的完整性, 同时也保证了报文的保密性, 这里对称加密算法的密钥分发是主要问题。D数字信封数字信封DE( Digital Envelope) 是指信息发送方在通讯双发首次通讯时, 使用对方的公钥对双方的通讯密钥SK( Symmentric Key) 进行加密, 形成一个数字信封, 然后发给接收方, 接收方收到数字信封后进行拆封操作, 用自己的私钥对信封进行解密得到通讯密钥, 然后双方能够用通讯密钥对自己发送的信息进行对称加密2。这样既解决了对称加密的密钥分配问题又提高了双方通讯加密的效率, 毕竟非对称加密算法比对称加密算法效率要低下。3.1.2 PKI体系PKI体系是由政策机构、 认证机构和注册机构组成的, 经过使用单向散列函数、 非对称加密体制等加密解密技术, 安全套接字协议SSL, LDAP协议( Lightweight Directory Access Protocol) , X.509证书标准等技术, 实现数据加密、 身份认证和数字签名等功能, 从而保证数据保密性、 完整性、 真实性和不可否认性的一种技术体系。PKI体系很好的解决了网上银行的大部分安全需求, 对网上银行的数据安全和业务逻辑安全提供了有力的支持。CA是PKI体系的主要实体, 数字证书是CA的主要产品, CA经过数字证书的应用来实现PKI体系所提供的功能。1PKI的组成PKI由政策批准机构PAA、 政策CA机构PCA、 认证机构CA和注册机构RA组成。PAA创立整个PKI系统的方针、 政策, 批准本PAA下属的PCA的政策, 为下属PCA签发公钥证书, 建立整个PKI体系的安全策略, 并具有监控个PCA行为的责任。PCA制定自身的具体政策, 包括密钥的产生、 密钥的长度、 证书的有效期规定及CRL的处理等, 同时PCA为其下属CA签发公钥证书。CA按照上级PCA制定的政策, 为具体用户签发、 生成并发布数字证书, 负责CRL的管理与维护。RA负责接收用户的证书申请, 验证用户的身份, 向CA提交证书申请, 验证接收CA签发的数字证书, 并将证书发放给申请者。PKI的组成图示如下: PCA1RA1PAAPCAnRAnCAnRAnRA1CAnCA1CA1图10 PKI的体系结构图2PKI的操作功能证书的生成及分发。在用户向RA提交数字证书申请后, RA负责对申请者的身份进行认证, 认证经过后RA将向CA转发证书申请。CA负责生成用户的数字证书, 数字证书的公私密钥对能够由用户产生, 也能够由CA产生。用户自己产生的公钥需提交给CA, CA对公钥强度验证后将根据用户提交的公钥产生用户的数字证书; 如果是CA产生用户的公私密钥对, 则CA不保存用户的私钥, 私钥需经过安全的方式发放给用户。CA生成证书后将其发布到相应的目录服务器上。证书的获取。在PKI体系中, 要获取某个用户的数字证书, 能够RA处获得, 也能够查询CA的证书目录服务器, 另外用户也能够将自己的证书发送给别人。证书的废止。数字证书的持证人如果发生证书丢失、 密钥泄漏时, 持证人能够向CA或RA提交证书废止请求, CA将会把用户的证书加入到废止列表中。废止列表CRL的获取与查询。由于CRL一般都比较大, 在线查询效率比较低下, 因此现在一般在RA端建立一个CRL的镜像, 定期将CA端的CRL同步到本地, 同步又分全部CRL同步和增量同步两种, 全部CRL同步的好处能保证CRL数据一致, 缺点是同步的数据量庞大, 一般也没有必要进行全局同步。增量同步就是每次只同步CA端新增的CRL部分, 增量同步的数据量较小, 比较符合现实。CRL的查询能够经过LDAP等访问。证书恢复。证书恢复功能为客户在证书存储介质损坏或遗忘口令等情况下, 提供原证书的恢复, 申请者向RA或CA提出证书恢复请求, CA将会为用户生成新的数字证书, 原来的证书将作废, 同时还会将其加入CRL中。证书更新。证书更新用于解决客户证书到期后的续费问题, 也有可能是客户的证书并未到达有效期而是CA或RA的本身的数字证书到达了有效期。这时用户需更新证书, CA将会为用户签发新的数字证书。3PKI的服务功能PKI提供的服务功能包括: 数据保密性服务、 数据完整性服务、 数据真实性服务、 数据不可否认性服务和身份认证服务。这些服务都是经过数字证书的应用来实现的, 在集成这些服务时, 还需要应用系统作部分支持才能真正实现这些服务。3.1.3 一次性口令技术所谓一次性口令( OTP, One Time Password) 是指针对传统可重复使用的口令而言的。一次性口令只能使用一次, 不可重复使用。可重用的口令易受种种攻击: 截取攻击: 当口令以明文方式在网络上传递时, 容易被攻击者截取获得, 一旦口令泄漏则可能被未授权者非法使用。重放攻击: 当口令以密文方式在网络上传递时, 虽然攻击者无法获取口令的明文, 但攻击者能够截取口令密文后对系统实施重放攻击。穷举攻击: 攻击者还有可能针对用户的登录名, 根据系统对口令的限定规则, 尝试规则范围内各个可能的口令, 对用户口令实施穷举攻击。窥探: 用户在输入可重复使用的口令时必然要借助某种输入设备, 如键盘、 鼠标、 手写笔等, 这时容易被她人或其它录影设备窥探到输入内容, 也有可能被木马程序等记录了击键事件而分析出口令。社交工程: 攻击者经过利用人们心理弱点、 本能反应、 好奇心、 信任、 贪婪等心理陷阱经过电子邮件、 电话访谈、 钓鱼网站等骗取用户的口令。垃圾搜索: 攻击者伪装成垃圾工人收集用户的垃圾文档用以分析用户的口令等。一次口令由于每次使用各不相同的口令, 因此并不存在上述的问题。一次口令并不要求用户记住多个口令, 因此也不会增加用户和系统的负担。一次性口令的原理: 在客户端和服务器端各存在一个相同的算法、 一个与用户有关的种子、 一个不确定的因子, 每次系统对用户进行认证时, 用户将不确定的因子追加到种子后, 然后用算法对其加密算出一个结果, 这个结果作为一个一次性口令提交给服务器, 服务器端用相同的算法对相同种子和不确定因子进行运算, 将得出的结果与用户提交的结果进行比较, 相同则说明用户输入的口令是正确的。一次性口令技术要求服务器端具有与用户端相同的算法、 种子及不确定因子。这里关键是如何保证客户端、 服务器端具有相同的不确定因子。两端不确定因子的选择方式主要有以下三种: 1挑战应答方式。每次用户请求登录系统时, 服务器端将不确定因子发送给用户, 称为一次挑战, 而用户提交的口令是根据发送来的不确定因子, 和用户端保存的种子, 由用户端保存的算法计算出来的, 因此每次计算出的口令不相同。这里的算法能够采用单向散列函数算法, 也能够采用对称加密算法。不确定因子采用挑战应答方式的原理能够图示如下: 返回登录结果运用算法对种子和因子进行运算得出登录口令并提交发送不确定因子请求登录, 输入用户名用 户系 统图11 一次性口令应用的原理图2时间同步方式。客户端和服务器端以时间作为不确定因子, 这里要求双方的时间是严格同步的, 精确度能够控制在约定的范围内, 比如说双方的时间差不超过一分钟。3事件同步方式。客户端和服务器端以单向序列的迭代值作为不确定因子, 这里要求双方每次迭代值的大小相同。这种方式的实现代价比时间同步方式的小得多, 而且也不用向挑战应答方式那样多出个挑战的交互, 这种方式客户端以单向迭代作为挑战, 迭代作为规则能够在客户端实现。3.1.3 基于J2EE平台的相关安全技术1语言内置的安全技术Java语言具有强类型检查, 在编译时就能对变量类型进行检查; 自动内存管理, 在C、 C+中内存的分配和回收都需要程序员负责完成, 在大型应用中内存泄漏是个颇为棘手的问题, 而Java内置垃圾回收机制, 由系统负责内存的管理; 字节码检查, JVM( Java Virtual Machine) 对源代码编译生成的字节码进行检查, 防止恶意代码对运行环境的破坏; 安全的类装载机制, 确保不信任的代码不会影响其它Java程序的运行。2密码技术支持JCA( Java Cryptography Architecture) 和JCE( Java Cryptographic Extension) 为加密、 解密、 数字证书、 数据摘要提供完整的支持; 提供对各种密码算法的支持, 包括RSA、 DSA、 DES、 SHA等; 提供对PKCS#11的支持。3认证和访问控制支持JAAS( Java Authentication and Authorization Service) 和Policy的实现及语法等提供了细粒度的访问控制, 抽象的认证APIs能够插件方式灵活地集成到其它登录控制系统中。4安全通讯Java Secure Socket Extension (JSSE), Java GSS-API (JGSS), Java Simple Authentication and Security Layer API( SASL) 等提供对Transport Layer Security (TLS)、 SSL、 Kerberos、 SASL等协议的实现, 提供对基于SSL/TLS的HTTPS完全支持, 为的数据完整性、 保密性提供支持确保通讯安全。5为PKI提供支持J2EE提供管理密钥和证书的工具, 广泛抽象的APIs对X.509证书、 废止列表、 证书路径、 OCSP (On-Line Certificate Status Protocol)、 PKCS#11、 PKCS#12、 LDAP等提供支持, 大大简化了PKI应用开发和部署的难度3。3.2 网络总体结构应用系统的总体拓扑图参考如下示: 图12 应用系统的总体拓扑图参考用户经过Internet网络向应用系统发起请求, 请求在到达Web服务器之前将经过NSAE( 使用两台带SSL加速卡的SSL安全网关服务器, 并配置为热备部署模式) 建立128位SSL加密通信通道。系统应用服务器经过有NSAE经由Web服务器传过来的Request对象获取客户端证书( 如果客户端采用数字证书认证的话) 。在登录环节, 系统应用服务器经过身份认证及签名验证服务器( NetSign Server) 所提供的API验证用户证书有效性并完成登录。在交易过程中需要对交易签名时, 经过客户端签名控件对页面信息进行签名, 签名结果信息及原始信息传递至应用服务器后, 经过签名验证服务器( NetSign Server) 提供的API将签名结果和原始信息以及客户端证书传至签名验证服务器进行验证。一次性口令的验证由系统应用程序调用动态密码系统的服务适配器, 由动态密码服务器完成验证并返回结果。短信密码的发送, 由动态密码服务器向的短信网关SMS Gateway发送请求实现。3.3 网络层方案选择3.3.1 安全连接协议系统客户端至服务器端的安全连接常见的协议有SSL、 SPKM可供选择4。SPKM( Simple Public Key Mechanism) 协议, 用于建立点对点之间的安全通道, 结合数字证书主要适用于内联网环境, 在运用于互联网时有如下问题5: 1因客户端在跟服务器端建立连接时需要访问CRL, 而SPKM协议固有的原因会造成客户端对废止列表访问的时间过长。2SPKM协议在客户端对整个页面进行数字签名也是没有必要的, 并不是用户提交的所有页面都需要数字签名的, 而且就算某个页面需要数字签名一般也不是页面中所有的元素都是需要数字签名的。比如对于行外转账交易而言, 收款人姓名、 收款人账号、 收款人开户行、 转账金额、 付款人账号是其五要素, 客户在提交转账交易时只需对这五要素进行数字签名就能够了, 而页面上还有一些诸如是否发送Email通知等要素就没必再被签名了。超出需求的要素被签名, 一方面将会增加网络流量, 同时还会导致服务器相应的迟滞。3由于SPKM协议并非普遍采用的安全通讯协议, 因此在通用的浏览器如IE、 Navigator等中没有支持, 需要下载安装客户端软件, 这就增加了系统安装、 维护、 使用的难度。SSL( Security Socket Layer) 协议已得到各主流浏览器内置的支持。由于标准的SSL协议, 在采用客户端证书时, 并未对用户的交易数据进行显式签名, 造成应用系统无法记录交易数据的数字签名, 给在技术层面维护交易的不可否认性带来了一定的困难6。在应用系统中我们采用SSL协议来建立安全连接。SSL协议签名的问题可经过在客户浏览器端安装签名控件来完成, 签名控件一方面能够完成数字签名, 另一方面, 经过自定义签名格式, 只对需要的页面要素进行签名, 去除不必要的数据被签名。3.3.2 安全区域的划分经过三台防火墙将网络划分为四个逻辑区域, 按由外到内的顺序部署。第一道防火墙之外是Internet区( 非授信区) ; 第一道防火墙和第二道防火墙之间是Web区, 在此区域中部署SSL服务器以及应用系统和网站系统的Web服务器等其它第三方应用系统; 第二道防火墙和第三道防火墙之间是系统及网站的应用/DB区, 在此区域中部署应用服务器和数据库服务器; 第三道防火墙之后为其它的核心系统、 中间业务平台等第三方业务系统。3.3.2 网络层安全组件应用系统的最外端部署了绿盟黑洞抗DoS攻击系统COLLAPSAR600D-5-B, 以控制拒绝式攻击和分布式拒绝攻击; 防火墙采用的是天融信防火墙产品NGFW4000-G, 入侵检测则采用的是启明入侵检测NS500系统, 漏洞扫描软件采用的是冠群金辰承影网络漏洞扫描器, 原有系统被两道防火墙分隔成三个区。系统部署时要求在停火区中再增加一道防火墙, 一方面隔离Web服务器与应用服务器; 另一方面隔离应用服务器和其它核心系统。增加的防火墙依然采用的是天融信NGFW4000-G防火墙, 另外还增加了两台IBM TotalStorage SAN 16M-2的交换机, 一套启明NS500系统。3.4 系统层方案选择系统Web服务器的操作系统采用SUSE Linux 9 Enterprise, 应用服务器和数据库服务器的操作系统采用AIX5L, V5.3, 数据库管理系统采用Oracle 10.0.2 FOR AIX。由于软件系统一般都存在漏洞, 操作系统也不例外, 无论是Unix、 Linux还是Windows系统。操作系统要求定期安装系统的最新补丁, 并定期对审计日志进行检查和备份。另外, UNIX、 Linux、 NT系统一般包含许多网络服务应用程序, 如FTP、 Telnet等, 有些不必要的网络服务程序必须禁用并关闭对应的端口。3.5 应用层方案选择3.5.1 数字证书国外比较著名的数字证书有: Verisign、 Etrust、 Baltimore等; 国内应用比较广泛的数字证书主要有中国金融认证中心CFCA的数字证书、 上海数字证书认证中心SHECA的证书等; 另外有些实体建设了自己的CA, 向本实体内的系统及其客户发放数字证书。对比分析上述的几家认证中心的数字证书的优缺点将有助于安全子系统的数字证书的选择。下表是比较结果: 表8 认证中心比较的表格方案优点缺点CFCA良好的公信力, 是金融领域CA的权威高级证书费用较高, 但可采用普通证书。Ver