基于WEB的应用系统安全方案说明.docx
《基于WEB的应用系统安全方案说明.docx》由会员分享，可在线阅读，更多相关《基于WEB的应用系统安全方案说明.docx（27页珍藏版）》请在冰豆网上搜索。
基于WEB的应用系统安全方案说明
第二章系统安全的需求分析
本章从数据安全和业务逻辑安全两个角度对应用系统的安全进行需求分析，主要包括保密性需求、完整性需求、可用性需求三部分；随后对业务逻辑安全需求进行了分析，包括身份认证、访问控制、交易重复提交控制、异步交易处理、交易数据不可否认性、监控与审计等几个方面；最后还分析了系统中一些其它的安全需求。
2.1数据安全需求
2.1.1数据保密性需求
数据保密性要求数据只能由授权实体存取和识别，防止非授权泄露。
从目前国内应用的安全案例统计数据来看，数据保密性是最易受到攻击的一个方面，通常表现为客户端发生的数据泄密，包括用户的基本信息、账户信息、登录信息等的泄露。
在应用系统中，数据保密性需求通常主要体现在以下几个方面：
A•客户端与系统交互时输入的各类密码：
包括系统登录密码、转账密码、凭证查询密码、凭证交易密码等必须加密传输及存放，这些密码在应用系统中只能以密文的方式存在，其明文形式能且只能由其合法主体能够识别。
以网银系统为例，在网银系统中，通常存有四种密码：
系统登录密码、网银
转账密码、柜面交易密码及一次性密码。
系统登录密码用来认证当前登录者为指定登录名的合法用户，网银用户的登录密码和网银转账密码由用户在柜面开户时指定，用户在首次登录网银系统时，系统必须强制用户修改初始密码，通常要求长度不得少于六位数，且不能是类似于111111、1234567、9876543等的简单
数字序列，系统将进行检查。
网银转账密码是指网银系统为巩固用户资金安全，在涉及资金变动的交易中对用户身份进行了再认证，要求用户输入预设的密码，网银交易密码仅针对个人用户使用，企业用户没有网银交易密码。
建立多重密码机制，将登录密码与网银转账密码分开管理，有利于加强密码的安全性。
由于用户在使用网银时每次都必须先提供登录密码，故登录密码暴露的机会较多，安全性相对较弱；但登录网银的用户并不是每次都会操作账户资金的，所以专门设定网银转账密码可加强账户的安全性。
网银转账密码在网银开户时设定，网银用户在系统中作转账支付、理财、代缴费等资金变动类交易时使用。
柜面交易密码是指用户在银行柜面办理储蓄时，针对储蓄凭证（如卡折、存单等）而设的密码。
柜面交易密码常用于POS系统支付时、ATM取款时、凭证柜面取款时，柜面交易密码一个明显的特征是它目前只能是六位的数字，这是由
于目前柜面密码输入设备的限制而造成的。
柜面交易密码与上述的网银转账密码的区别在于：
网银转账密码和系统登录密码都产生于网银系统，储存在网银系统中，仅限网银系统中认证使用；而柜面交易密码产生于银行柜台，可以在外围渠道如ATM、电话银行、自助终端上修改，它保存在银行核心系统中，供外围各个渠道系统共同使用。
另外网银转账密码可以有非数字字符组成，而柜面交易密码只能是六位的数字。
网银中使用到柜面交易密码的交易包括：
网银开户、加挂账户。
一次性密码由用户的智能卡、令牌卡产生，或由动态密码系统产生通过短信方式发送到用户注册的手机上。
一次性密码的作用与网银转账密码相同，适用的场合也相同。
一次性密码在农商行网银系统中是可选的安全服务，用户需到柜面办理开通手续才能使用，没有开通一次性密码服务的用户必须设定网银交易密
码，开通一次性密码服务的用户则无需设定网银交易密码，要求网银系统自动判
断并提示用户在某个交易中是要输入网银交易密码还是提示一次性密码。
B•应用系统与其它系统进行数据交换时在特定安全需求下需进行端对端的
加解密处理。
这里的数据加密主要是为了防止交易数据被银行内部人士截取利
用，具体通讯加密方案参照应用系统的特定需求。
2.1.2数据完整性需求
数据完整性要求防止非授权实体对数据进行非法修改。
用户在跟应用系统进行交互时，其输入设备如键盘、鼠标等有可能被木马程序侦听，输入的数据遭到截取修改后被提交到应用系统中，如原本用户准备向A账户转一笔资金在交易
数据遭到修改后就被转到B账户中了。
同样的威胁还存在于交易数据的传输过程中，如在用户向应用系统提交的网络传输过程中或应用系统跟第三方等其它系统的通讯过程中，另外存储在应用系统数据库中的数据也有可能遭到非法修改，如
SQL注入攻击等。
2.1.3数据可用性需求
数据可用性要求数据对于授权实体是有效、可用的，保证授权实体对数据的合法存取权利。
对数据可用性最典型的攻击就是拒绝式攻击（DoS）和分布式拒绝攻击，两者都是通过大量并发的恶意请求来占用系统资源，致使合法用户无法正常访问目
标系统，如SYNFlood攻击等，将会直接导致其他用户无法登录系统。
另外，应用登录机器人对用户的密码进行穷举攻击也会严重影响系统的可用性。
2.2业务逻辑安全需求
业务逻辑安全主要是为了保护应用系统的业务逻辑按照特定的规则和流程被存取及处理。
2.2.1身份认证需求
身份认证就是确定某个个体身份的过程。
系统通过身份认证过程以识别个体的用户身份，确保个体为所宣称的身份。
应用系统中身份认证可分为单向身份认证和双向身份认证，单向身份认证是指应用系统对用户进行认证，而双向身份认
证则指应用系统和用户进行互相认证，双向身份认证可有效防止“网络钓鱼”等假网站对真正系统的冒充。
应用服务器采用数字证书，向客户端提供身份认证，数字证书要求由权威、独立、公正的第三方机构颁发；系统为客户端提供两种可选身份认证方案，服务器端对客户端进行多重身份认证，要求充分考虑到客户端安全问题。
将客户端用户身份认证与账户身份认证分开进行，在用户登录系统时，采用单点用户身份认证，在用户提交更新类、管理类交易请求时，再次对用户的操作进行认证或对用户身份进行二次认证，以确保用户信息安全。
2.2.2访问控制需求
访问控制规定了主体对客体访问的限制，并在身份识别的基础上，根据身份对提出资源访问的请求加以控制。
访问控制是应用系统中的核心安全策略，它的主要任务是保证应用系统资源不被非法访问。
主体、客体和主体对客体操作的权
限构成访问控制机制的三要素。
访问控制策略可以划分为自主访问控制、强制访问控制和基于角色的访问控制三种。
223交易重复提交控制需求
交易重复提交就是同一个交易被多次提交给应用系统。
查询类的交易被重复提交将会无故占用更多的系统资源，而管理类或金融类的交易被重复提交后，后果则会严重的多，譬如一笔转账交易被提交两次则将导致用户的账户被转出两笔相同额的资金，显然用户只想转出一笔。
交易被重复提交可能是无意的，也有可能是故意的：
A•用户的误操作。
在B/S结构中，从客户端来看，服务器端对客户端的响应总有一定的延迟，这在某些交易处理上体现的更为明显，特别是那些涉及多个系统交互、远程访问、数据库全表扫描、页面数据签名等交易，这种延迟通常都会在5至7秒以上。
这时用户有可能在页面已提交的情况下，再次点击了提交按钮，这时将会造成交易被重复提交。
B.被提交的交易数据有可能被拿来作重放攻击。
应用系统必须对管理类和金融类交易提交的次数进行控制，这种控制即要有效的杜绝用户的误操作，还不能影响用户正常情况下对某个交易的多次提交。
比如说：
当某个用户在10秒内提交了两笔相同的转账业务，则系统必须对此进行控制；另一方面，当用户在第一笔转账业务完成后，再作另一笔数据相同的转账时，则系统不能对此进行误控制。
这里判断的依据就是交易重复提交的控制因子a，当交易提交的间隔小于a时，系统认为这是重复提交，提交间隔大于a的则不作处理，控制因子的大小由应用系统业务人员决定，系统应可对其进行配置化管理。
224异步交易处理需求
所谓异步交易就是指那些录入与提交不是同时完成的交易，这里的同时是指
客户端在录入交易数据与提交交易的过程中，应用系统服务器端并没有对录入的数据进行持久化保存，而异步交易在系统处理过程中，录入与提交时间上发生在两个相分离的阶段，在两阶段之间，应用系统对录入的数据进行了持久化保存。
由于异步交易是被系统分两阶段受理的，这就涉及到以下三个方面的问题：
A.录入与提交的关系管理。
B.如何保证提交的数据就是用户当初录入的数据。
C.如何记录交易在两阶段的日志状态。
录入与提交的关系定义不当将会导致交易录入与提交被同时完成而违反了业务处理流程，录入的数据被系统保存后有可能遭到非法篡改，非异步交易执行后的日志状态不会被更新而异步交易在提交后日志状态将会被更新。
应用系统中需要定义成异步的交易通常有以下两类：
需要授权的交易。
出于业务管理和业务安全方面的考虑，大部分管理类和金融类的交易都需要经过一定的授权流程后方能被提交。
部分定时交易，如预约转账等。
预约一笔在周三转账的预约转账有可能是周一被录入的，用户在录入后，预约转账的数据将被网银系统保存直到周三这笔转账才会真正发生。
应用系统必须定义简单、清晰、易维护的录入与提交关系模型，保证被保存的录入数据不会被非法篡改，同时要求异步交易的日志状态是明确的，不应出现录入与提交相矛盾的日志状态。
225交易数据不可否认性需求
交易数据不可否认性是指应用系统的客户不能否认其所签名的数据，客户对
交易数据的签名是通过应用系统使用客户的数字证书来完成的。
数字证书的应用
为交易数据不可否认性提供了技术支持，而电子签名法的颁布为交易数据不可否认性提供了法律基础。
在应用系统中通常要求对所有管理类与金融类的交易进行数字签名，以防客
户事后对交易或交易数据的抵赖。
应用系统需同时保存客户录入的原始数据和签名后的数据，保存期限依业务部门的具体要求而定。
考虑到系统性能和对用户的响应问题，应用系统可只签与交易有关的关键数据，支付类的交易只对付款人账号、付款金额、收款人姓名、收款人账号、收款人开户行五个字段进行数字签名就可以了。
2.2.6监控与审计需求
安全级别要求高的应用系统应提供对系统进行实时监控的功能，监控的内容
包括系统当前登录的用户、用户类型、用户正在访问的交易、用户登录的IP等。
对金融类、管理类的交易以及应用系统登录交易需要完整地记录用户的访问过程，记录的关键元素包括：
用户登录名、登录IP、交易日期及时间、交易名称、交易相关数据等，对有授权流程的交易要求完整记录授权的经过，授权记录与交
易记录分开存放。
2.3其它安全需求
2.3.1登录控制需求
登录通常是应用系统的关键交易，系统通过登录交易对用户身份进行认证。
针对不同角色的用户指定不同的登录策略：
最小权限集用户，可使用用户登录名+静态登录密码+图形识别码方式登录。
低安全性。
普通权限集用户，可使用用户登录名+动态登录密码+数图形识别码方式登录。
高权限集用户，可使用用户登录名+数字证书+静态密码+数图形识别码方式登录。
所有权限集用户，可使用用户登录名+数字证书+动态密码+数图形识别码方式登录。
应用系统可提供客户端加密控件对用户输入的密码域进行加密处理后再提交。
连续登录多次失败的用户，其IP将被应用系统锁定，24小时后系统将自动对锁定的IP进行解锁。
这里登录失败的次数和IP锁定时长根据业务需求说明应由配置文件进行设定。
对于首次登录系统的用户，系统将强制定位到修改密码的页面，要求用户修改初始密码重新登录方可使用系统。
对于密码类型和长度，系统将规则检查。
对于成功登录的用户，应用系统自动清除其连续登录失败的次数，同时初始化用户的相关数据并同时对登录数据进行记录，以备审计。
232会话控制需求
通过应用服务器自身的会话管理或应用程序的会话管理都可以控制会话的时长设定，设置过久的会话将给客户端带来安全风险，而设置过短则影响用户的正常使用。
该机制使在应用层无状态的HTTP/HTTPS*议，能够支持需要状态记
录的互联网应用，实现用户登录后在新的状态下从事交易、超时断路等功能。
233被访问对象控制需求
应用系统对用户的关键资源或信息，提供操作权限设置支持，权限分为：
查询和更新两类。
权限为查询的资源或信息只能对其进行查询操作，不能进行更新。
资源权限由开户时指定，为加强安全性，权限分配可通过落地处理开通。
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）
C=E（P）
P=D（C）
上述的加密与解密过程没有使用到密钥，通常称之为无密钥密码体
制。
无密钥密码主要依靠加密算法提供保密性，在应用系统中这种密码很少用到，主要使用还是有密钥的密码体制，在有密钥的密码体制中，
密文的保密性依赖于密钥而不依赖于算法，算法可以公开。
其中，只有一个密钥K的密码体制称为单钥体制（One-keySystem），又称对称加密体制（SymmetricalEncryption）;有加密密钥KE和解密密钥K
D两个密钥的密码体制称为双钥体制（Two-keySystem），又称非对称加密体制（DissymmetricalEncryption），有时也叫公开密钥算法
（PublicKeyAlgorithm）。
应用系统中经常使用最广泛的对称加密算
法是DES算法（DataEncryptionStandard），非对称加密算法是R
SA算法（Receive，Shamir，Adelman）。
单钥体制的加密解密过程可以记为：
（3.2）
C=E（P,K）
P=D（C,K）
上式用图示可以表示为:
图5单钥体制加密解密过程图
双钥体制的加密解密过程可以记为：
上式用图示可以表示为:
图6双钥体制加密解密过程图
还有一种应用系统中经常用到的加密技术是数据摘要，数据摘要就
是应用单向散列函数算法，将输入的任意长度明文变换成固定长度的密文，而将此密文再转换成明文在数学上来说是困难的。
应用系统中应用
最广泛的数据摘要算法主要有MD5和SHA两种，MD5输出压缩值为128bits，SHA输出压缩值为160bits。
设Hash表示单向散列函数，则数据摘要的过程可以记为：
（3.4）
C=Hash（P）
上式用图示可以表示为:
图7数据摘要的过程图
B•数字签名。
数字签名是指通过密码算法对原始数据信息进行加密处理后，生成一段原始
数据信息的信息标识，这段信息标识称为原始数据信息的数字签名。
通常数字签
名和原始数据信息是放在一起发送的，这样便于信息的接受者对其进行验证，数字签名是对现实中手写签名和印章的模拟，数字签名只有信息发送方一人能产生，这种唯一性对应了原始数据信息的来源。
数字签名具有验证数据完整性和信息来源不可否认性的功能，这正是PKI体系提供的核心功能。
在应用系统中，较小的数据可以直接签名，而较大的数据或文件通常先对其作数据摘要后再对数据摘要作数字签名。
下式表达了对一段原始数据信息进行签名的过程：
原始数据信息OriginalMsg先是被单向散列函数Hash作数据摘要生成摘要信息DigestMsg，然后应用非对称加密算法DissymmetricalEncrypt及
其私钥Keyprivate对数据摘要进行签名（私钥仅有发送方持有，公钥需散发给接收方），最后将签名结果DigitalSignature与原始数据信息一起发送给接受方：
DigestMsg二Hash（OriginalMsg）
DigitalSignature二DissymmetricalEncrypt（DigestMsg,Keyprivate）
（3.4）
上式用图示可以表示为:
图8数字签名的过程图
信息接受方在接受到原始数据信息OriginalMsg与其数字签名
DigitalSignature后，可以对数字签名进行验证。
首先分离出两者，然后对原始
数据信息应用同样的单向散列函数Hash对其作数据摘要得到Digest2，再对接收到的数字签名应用非对称加密算法DissymmetricalEncrypt及其公钥
Keypublic对其进行解密，得到Digest1。
比较Digest1与Digest2，如果两者一样则证明：
1•信息OriginalMsg及其数字签名DigitalSignature是真实的，确实来自
于私钥Keyprivate的持有方。
2•信息OriginalMsg及其数字签名DigitalSignature在发送过程中是完整
的，未曾遭到篡改。
3•私钥Keyprivate的持有方发送了信息OriginalMsg及其数字签名
DigitalSignature这件事是不可否认的。
上述数字签名的验证过程可以表达为：
DigestMsg2=Hash（OriginalMsg）
DigestMsgl二DissymmetrcalEncrypt（DigitalSignature.Keypublic）
DigestMsg2==DigestMsg1?
（3.5）
用图形表示如下：
OriginalMsg+DigitalSignature
图9数字签名验证的过程图
C•报文识别码
应用系统跟其它系统通讯时大都是通过发送接收报文方式进行的，除比较常
用的ISO8583，sop报文等，还有比较多的就是自定义的报文格式，自定义报文
需要解决报文的保密性和完整性问题，报文的完整性可以通过加密算法生成原始报文的报文标识来识别，这个加密后的报文标识称为原始报文的识别码，也叫报
文校验码MAC（MessageAuthenticationCode）。
而报文的保密性可以通
过对整个报文及其识别码进行加密处理来完成，实际应用中识别码通常可以通过
单向散列函数对原始报文作数据摘要得到，然后对原始报文和数据摘要作对称加密，这样既保证了报文的完整性，同时也保证了报文的保密性，这里对称加密算法的密钥分发是主要问题。
D•数字信封
数字信封DE（DigitalEnvelope）是指信息发送方在通讯双发首次通讯时，使用对方的公钥对双方的通讯密钥SK（SymmentricKey）进行加密，形成一个数字信封，然后发给接收方，接收方收到数字信封后进行拆封操作，用自己的私
钥对信封进行解密得到通讯密钥，然后双方可以用通讯密钥对自己发送的信息进行对称加密［2］。
这样既解决了对称加密的密钥分配问题又提高了双方通讯加密的效率，毕竟非对称加密算法比对称加密算法效率要低下。
3.1.2PKI体系
PKI体系是由政策机构、认证机构和注册机构组成的，通过使用单向散列函数、非对称加密体制等加密解密技术，安全套接字协议SSLLDAP协议
（LightweightDirectoryAccessProtocol），X.509证书标准等技术，实现数据加密、身份认证和数字签名等功能，从而保证数据保密性、完整性、真实性和不可否认性的一种技术体系。
PKI体系很好的解决了网上银行的大部分安全需求，对网上银行的数据安全和业务逻辑安全提供了有力的支持。
CA是PKI体系的主要实体，数字证书是CA的主要产品，CA通过数字证书的应用来实现PKI体系所提供的功能。
1.PKI的组成
PKI由政策批准机构PAA、政策CA机构PCA、认证机构CA和注册机构
RA组成。
PAA创建整个PKI系统的方针、政策，批准本PAA下属的PCA的政策，为下属PCA签发公钥证书，建立整个PKI体系的安全策略，并具有监控个PCA行为的责任［］。
PCA制定自身的具体政策，包括密钥的产生、密钥的长度、证书的有效期规定及CRL的处理等，同时PCA为其下属CA签发公钥证书。
CA按照上级PCA制定的政策，为具体用户签发、生成并发布数字证书，负责
CRL的管理与维护。
RA负责接收用户的证书申请，验证用户的身份，向CA提交证书申请，验证接收CA签发的数字证书，并将证书发放给申请者。
PKI的组成图示如下：
PAA
图10PKI的体系结构图
2.PKI的操作功能
证书的生成及分发。
在用户向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将会为用户签发新的数字证书。
3.PKI的服务功能
PKI提供的服务功能包括：
数据保密性服务、数据完整性服务、数据真实性服务、数据不可否认性服务和身份认证服务。
这些服务都是通过数字证书的应用来实现的，在集成这些服务时，还需要应用系统作部分支持才能真正实现这些服务。
3.1.3一次性口令
升级会员 