第15章应用安全

上传人:鲁** 文档编号:592299339 上传时间:2024-09-20 格式:PPT 页数:23 大小:59.50KB
返回 下载 相关 举报
第15章应用安全_第1页
第1页 / 共23页
第15章应用安全_第2页
第2页 / 共23页
第15章应用安全_第3页
第3页 / 共23页
第15章应用安全_第4页
第4页 / 共23页
第15章应用安全_第5页
第5页 / 共23页
点击查看更多>>
资源描述

《第15章应用安全》由会员分享,可在线阅读,更多相关《第15章应用安全(23页珍藏版)》请在金锄头文库上搜索。

1、信息安全概论躺茄凉钾帖琉泛晒氨衔揖舌扇般肠纺六袖阮备膏丧厦光隋糕糜涨绪尧官棉第15章应用安全第15章应用安全1一、Web安全1、web安全的主要目标 (1)服务器安全 保护服务器不被非授权者访问、不被篡改或阻塞; 保护服务软件不访问系统文件,从而避免引起系统混乱; 只允许授权用户访问Web发布的信息; 确保用户上载的数据安全可靠。 (2)传输安全 确保重要的Web服务信息在传输中不被窃听和篡改。 (3)客户机安全 确保浏览器不被恶意代码侵袭,尤其是不受到病毒和木马的侵袭倪纵及嫉郴豁征筛梳拭藩宝丁磐滩萎先临围则嘿鸦选脊瑶烤或涨萨募娠敏第15章应用安全第15章应用安全22、Web安全措施 (1)定

2、期扫描加固; (2)安装Web服务器保护系统 (3)采用完善的认证和加密措施 (4)设立代理服务器 (5)谨慎设置浏览器安全选项漠耙氓秘坞池鸿拱撕慑鲜吟盲组栖故带吾阻想庙莆狭雕塘让烽川哗笔侧杯第15章应用安全第15章应用安全31、Email系统组成 Email系统主要由邮件分发代理、邮件传输代理、邮件用户代理及邮件工作站组成。n (1)邮件分发代理MDA:负责将邮件数据库中的邮件分发到用户的邮箱中。在分发邮件时,MDA还承担邮件自动过滤、邮件自动回复和邮件自动触发等任务。常见的MDA开放原代码程序有hinmail和promail等。n (2)邮件传输代理MTA:负责邮件的接收和发送,通常采用S

3、MTP协议传输邮件。常见的MTA程序有sendmail、qmail和Postfix等。一、Email安全妻美籽扼灭过幽淡迎创绑估燕栗瘟晚先窄异野峰勇努孵挣器骑脆蜡目岛喘第15章应用安全第15章应用安全4n (3)邮件用户代理MUA:MUA并不接收邮件,而是负责将邮箱中的邮件显示给用户。MUA常用的协议有POP3和IMAP,常见的程序有pine、kmai1等。n (4)邮件工作站:是邮件用户直接操作的计算机,负责显示、撰写邮件等。慈竿隆酣基被罪秀眯竹享国桓蹄加宾辱韩凿六赏邵叙艘诫眼脊郊豆反恢乡第15章应用安全第15章应用安全5nEmail安全目标n 根据邮件系统的组成,可以将邮件安全的目标总结如

4、下:n (1)邮件分发安全:邮件分发时,可能遇到垃圾邮件、邮件病毒、开放转发等威胁,所以邮件分发安全应能阻止垃圾邮件和开放转发,并查杀己知病毒。n (2)邮件传输安全:邮件在传输过程中可能被窃听、篡改,因此必须保障邮件传输的n机密性和完整性。同时,邮件在传输中采用SMTP协议,该协议允许远程查询邮件账户,n因此,如何在高安全要求的系统中保护邮件账户的状态(如存在、可用等)也是安全的目标。垣识赦翔并箍盾邓瞥狙饲锹利者欧师缩提匪赞拽萍雹丛村嫂腹毙慕羞苇疙第15章应用安全第15章应用安全6n (3)邮件用户安全:邮件用户通过工作站,采用PoP3或IMAP等协议浏览邮件这个过程中需要确认用户的身份,否

5、则将导致邮件被非授权访问。同时,邮件在用户工作站上显示时,可能需要在本地执行显示软件,因而容易使病毒或其他有害代码发作。所以在工作站端,也要能支持病毒查杀功能。毒蔑粕打瞧还哦垃邱著粒稠萨绒榔召眷反觉接歧玩焊在役娥地券灌篙刑脸第15章应用安全第15章应用安全7nEmail安全措施n 针对以上安全目标,常用的支全措施如下:n (1)身份认证:包括邮件转发认证、邮件收发认证等、即在要求转发邮件时,必须经过认证,而不是开放转发。而在用户要求接收或发送邮件时,必须经过身份认证,以避免邮件在邮箱中被窃取。要特别强调的是,认证的口令要有足够强度,以防在线口令被破解。n (2)加密、签名:在传输中,必须采用加

6、密和签名措施来保障重要邮件的机密性和完整性。目前,电子邮件己渐渐成为商务信函的重要形式,因此,必要时还要进行发送和接收签n名,以防止否认。在这方面,己有成熟的安全协议PGP和S/MIME等,将在后面详细介绍。n (3)协议过滤:为了防止邮件账号远程查询,要对SMTP的协议应答进行处理,如对VERY、EXPN等命令不予应答,或无信息应答。满术扭慷袭映阔察岭整乡措孵直睡酵走辟峡巳丽媳迎佣粹苞应豌羊梯渤呸第15章应用安全第15章应用安全8n (4)设立防火墙:经常设立内、外邮件服设立防火墙:经常设立内、外邮件服务器,在内、外服务器问设立防火墙。外服务器,在内、外服务器问设立防火墙。外服务器负责对外邮

7、件的传输收发,而内服务器务器负责对外邮件的传输收发,而内服务器才是真正的用户邮件服务器。所有来自公网才是真正的用户邮件服务器。所有来自公网上的邮件操作均止于外服务器,再由外服务上的邮件操作均止于外服务器,再由外服务器转发。这样可以将真正的邮箱和公网隔离。器转发。这样可以将真正的邮箱和公网隔离。n (5)安装邮件病毒过滤系统;在邮件服务安装邮件病毒过滤系统;在邮件服务器上安装邮件病毒过滤软件,使大部分邮件器上安装邮件病毒过滤软件,使大部分邮件病毒在邮件分发时被分捡过滤。同时在邮件病毒在邮件分发时被分捡过滤。同时在邮件客户端也安装防病毒软件,在邮件打开显示客户端也安装防病毒软件,在邮件打开显示前查

8、杀病毒。前查杀病毒。颈珊运华汇嫩呀角哑彭日疑页厄煞域溢振筐冗劣闲腿实制忻乔胳汲厘磺楼第15章应用安全第15章应用安全9三、电子商务安全三、电子商务安全n SET协议是一种基于信用卡网上电子商务交易的安全标准,主要是为了解决用户、商家和银行之间通过信用卡支付的交易安全而设计的,用以保证支付信息的机密、支付过程的完整、商户及持卡人的合法身份以及互操作性。SET协议的核心技术包括电子安全证书、电子数字签名、电子信封等。n SET协议得到许多著名IT公司的支持,如IBM,MicROSOFT,RSA,Netscape等。猩镐餐艾匆膨柱鹰版昌的区拙西去蕉经咎瞻缔唆衣鸟王粥瓤嫡纳押顽泰摩第15章应用安全第1

9、5章应用安全10n1、SET的安全目标n在一次完整的电子商务交易中,SET涉及到消费者(卡用户)、商家、收单银行、发卡银行和公证书中心(CA)等实体。暇井耪观揪辫馒弗只中复雅摄砚百听旗辫禾汇肾蚁尚剧嗜色吉弥曼酿淘辱第15章应用安全第15章应用安全11n 卡用户:持有信用卡的消费者;n 商家:提供网络购物的电子商店与提供电子交易服务的企业组织;n 收单银行:使用支付网关为电子商家提供处理卡的授权及支付服务的金融机构;n 发卡银行:负责信用卡的发放、账目管理、付款清算等业务的银行;n 证书中心(CA):通常由一些发卡机构共同委派,负责向卡用户、电子商家发行X.509v3n公开密钥证书的机构。豺拘莹

10、赦懦涯伺吻呆疵鲜幼至川獭乎迄弧房戮子杯钩浙蜒宪圾僳诅圃滓仔第15章应用安全第15章应用安全12n SET的安全目标就是保障信息流在各实体间安全流动。具体如下:n (1)保护信息的机密性;卡用户的账号以及支付信息必须通过安全的途径在Internet上n传输。值得注意的是,卡用户的某些信息对于商家而言应该是不可见的;n (2)保护数据的完整性:在Internet上传输的过程中,卡用户对商家的支付信息不能被n篡改;n (3)身份鉴别:卡用户与商家相互认证,确定被此身份的合法性。争戌撮鸽离糠犁界榔钩杠熔恨捌西缴切附坎迁虎赶扑付蚂底茧浇匠乃皖靶第15章应用安全第15章应用安全13nSET的工作流程n S

11、ET的工作流程分为以下几个步骤:n (1)卡用户向商家发送订购和支付信息,其中支付信息被加密,商家无从得知;n (2)商家将支付信息发送到收单银行,收单币银行解密信用卡号,并通过认证验证签名n(3)收单银行向发卡银行查问,确认用户信用卡是否属实;修惟疚啊昔晶温松批痈劣凰怒懦栗郡虫栓首严快氢碑丙宁房拇群靠欧疹求第15章应用安全第15章应用安全14n(4)发卡银行认可并签证该笔交易:n(5)收单银行认可商家并签证此交易;n(6)商家向用户传送货物和收据;n(7)交易成功后,商家向收单银行请求支付;n(8)收单银行按合同将货款划给商家;n(9)发卡银行定期向用户寄去信用卡消费账单。圈皋邮闲赘医玖苇姜

12、辟仲怂纪患炙癌缉又讳训涩触钩斧该内宁息胯缴迪庞第15章应用安全第15章应用安全15n1SET主要交易类型nSET的主要交易类型包括:n(1)卡用户注册:卡用户向商家发送SET报文前,必须在认证中心注册;n(2)商家许册:商家与卡用户和收单银行交换SET报文前,必须在认证中心注册:n(3)购买请求:卡用户发送商家的报文,包含给商家的订购信息和给银行的支付信息:n(4)支付兑现:在商家与收单银行间传送的报文,用来验证卡用户信用卡账户的合法性;宏追鲁掩鬼诛密斧翰迟掌凭或芬咳伯亲纤氟散孽俱丙喷哦尔砾锐羔重熬诡第15章应用安全第15章应用安全16n(5)支付获取:商家向收单银行请求支付:n(6)证书调查

13、和状态:认证中心无法立刻完成证书请求时,指示请求者以后再查看;n(7)购买调查:卡用户检查订购处理的状态;n(8)认可撤销:商家可以更正以前的认可请求;n(9)获取撤销:商家可以更正获取请求中的误差;n(10)信用;商家向卡用户的账号发送一个信用;铱婪库憨红柑焉奴初荔卤昆佩寓揣族笺孩签来豫蠢咒让入丁哎编月剔隙撞第15章应用安全第15章应用安全17n(11)信用撤销:商家可以更正以前的请求信用;n(12)收单银行证书请求;商家可以请求收单银行证书:n(13)批管理:商家可以成批的与收单银行通信;n(14)差错信息:指出响应者报文在格式或内容检测中失败,并因此拒绝该报文。目祝授销雌役兆榔持巳胎膨慈

14、汤辟圃搞蜂怠减阜釜健届辕的蛋匪檄苑允孕第15章应用安全第15章应用安全18n 2SET支付处理n 在介绍支付处理前,有必要先介绍SET中的双签名。在SET协议中,卡用户要将订购信息(OI)与支付信息(PI)分别发送给商家与银行,为了避免因为OI与PI分离而产生OI与PI的错误匹配,必须将OI与PI以某种方式连接起来。在SET协议中,卡用户分别取得OI与PI的散列数据,将其连接起来,然后取得连接结果的散列数据,再用卡用户的私有签名密钥对最终的散列数据进行加密,最终创建双签名。n 如果商家获得双签名(DS)、OI和PI的报文摘要(PIMD)以及卡用户的公开密钥KU,就可以计算H(PIMD|H(OI

15、)和DKU(DS),如果两者相等,则商家验证了该签名。如果银行n获得了DS、PI和OI的报文摘要(OIMD)以及卡用户的公开密钥,则同样可以计算H(H(PI)|OIMD)和DKU(DS),如果二者相等,则通过签名验证。这样既避免了商家获得卡用户支付信息中的有关私有信息,又保证了OI与PI的匹配。猩淡缎宁么灼钵稠凑谰札秃首捶胯吝谗乓莆藩函彭槽蕊呼诺朽侯蓑沦炕蠕第15章应用安全第15章应用安全19n 支付处理主要涉及购买请求、支付授权和支付兑现3个阶段,介绍如下:n (1)购买请求(Purchase Request)n 购买请求交易主要可以分为4步。n 第一步,卡用户向商家发送请求报文,请求商家和

16、收单银行证书。n 第二步,商家生成响应报文,包括商家的签名证书和收单银行的密钥交换证书,并用私钥加密。n 第三步,卡用户验证有关证书,创建OI和PI,生成一次性对称加密密钥Ks,并且生成购买请求报文。购买请求报文包括以下信息:n a)与支付有关的信息:PI、双签名、OI报文摘要(OIMD)以及数字信封通过对Ks和收单银行的公开密钥交换的密钥进行加密而成)。商家无法读取这一部分的信息。n b)与订购有关的信息:OI、双签名、PI报文摘要PIMD)。n c)卡用户的证书。皖乎谚越脓长瘪焕绞桩韩蛙著寡抓按室殖誊躁简懒艺崖扣褐建芹驰睁那嘉第15章应用安全第15章应用安全20n第四步,商家验证卡用户证书

17、以及双签名,然后处理订购信息并将支付信息转送收单银行,最后向卡用户发送购买响应。n (2)支付授权(Payment Authorization)n 在处理卡用户的订购时,商家向收单银行请求授权该项交易,主要可以分为以下两步。n 第一步,商家向收单银行发送认可请求报文。该报文主要包含以下内容:n a)与支付有关的信息: PI、双签名、OI报文摘要(OIMD)、数字信封等。n b)与认可有关的信息:一个认可数据块(使用商家生成的一次性对称密钥进行了加密的交易ID,并用商家私有密钥签名)、一个数字信封(使用收单银行的公开密钥交换的密钥对一次性密钥进行加密而形成的)等。n c)证书: 卡用户的签名密钥

18、证书、商家的签名密钥证书和商家的密钥交换证书等。n 第二步,收单银行先验证所有证书,接着解密并验证认可数据块以及支付数据块的双签名,然后向发卡银行请求和接收个认可,最后向商家发送认可响应报文。该报文包括认可数据块、数字信封、获取权标信息以及收单银行的证书。骡渝背吾徘距涣颇雹想躬麻筏邹酸酞加徽静七彝间国殷达褥瘦致宫泞抚嘴第15章应用安全第15章应用安全21n 商家获得授权后,即可向卡用户提供相应的服务。n (3)支付兑现(Payment Capture)n 首先,商家发送兑现请求报文给收单银行。该报文主要包括兑现请求数据块、兑现权标以及商家的签名密钥和密钥交换密钥的证书。n 收单银行收到兑现请求报文后,解密并验证兑现请求数据块以及兑现权标,验证兑现请求和兑现权标是否一致,接着通过专用网络向发卡银行发送清算请求,请求发卡银行将资金划入商家账号,然后发送兑现响应报文给商家,通知有关支付情况。而商家将保留该报文并与从发卡银行所得到的支付相匹配。撕剧猖梆连砧湘哦丢起缠拎趋蕉烧蚂锰丙仟蝎虚驹坛俏蔷勋卯舞厌动赎隔第15章应用安全第15章应用安全22尸豢套骚惶苯企峙金删塘祭撕歹辙沥铺迂怨晓碎校赐符烷蓄吊犊轩缮骆递第15章应用安全第15章应用安全23

展开阅读全文
相关资源
正为您匹配相似的精品文档
相关搜索

最新文档


当前位置:首页 > 资格认证/考试 > 自考

电脑版 |金锄头文库版权所有
经营许可证:蜀ICP备13022795号 | 川公网安备 51140202000112号